Prometheus告警消息美化核心是结构化与信息分层:只保留3–4个业务强相关标签,用{{if}}过滤空值;时间统一转为带时区的北京时间;标题前置[告警]/[恢复]标识并区分颜色;description作为操作指引,关键指标附Grafana链接。
美化 Prometheus 告警消息,核心不是加颜色或换行,而是让每条消息都“一眼看懂问题、立刻知道该做什么”。关键在结构清晰、信息分层、时间可读、状态明确——这些比花哨排版更重要。
Alertmanager 传来的原始数据里常有十几二十个 label(如 job、instance、namespace、pod、service…),但真正需要出现在飞书/钉钉里的往往只有 3–4 个。硬全写进去只会稀释重点。
KubePodCrashLooping,重点留 pod、namespace、container,去掉 prometheus、endpoint 这类监控链路字段{{if .labels.instance}} 判断是否存在再渲染,避免空值占行severity)统一前置到标题或首行,不混在中间段落里原始 .startsAt 是 UTC 时间(如 2026-06-09T03:25:18.123Z),国内值班人员第一反应是“这几点?”,容易误判响应优先级。
{{GetCSTtime $v.startsAt}}(PrometheusAlert 支持)直接转为 2026-06-09 11:25:18
触发时间(北京时间 CST):2026-06-09 11:25:18
同一种模板渲染告警和恢复,会导致消息流里混入“已解决”通知,值班人可能误以为是新故障。
[告警] / [恢复],字体加粗或用飞书支持的 emoji(⚠️ / ✅)color 字段控制整体背景色(如告警红底白字、恢复绿底黑字)✅ 该问题已自动恢复,如仍有异常请人工核查
很多人只渲染 .annotations.summary,但真正定位问题常需 .annotations.description 或动态计算值。
description 当作操作指引来写,例如:请登录 {{ .labels.instance }} 查看 /var/log/app/error.log 最近 10 行
{{ $value | humanize }} 把原始数值转为易读格式(如 987654321 → 987.6M)? 查看详情:<a href="https://www.php.cn/link/77e02887fc8719ae5d273c6ceb196d0a">实时图表</a>