我在使用Prometheus时都踩过哪些坑？(2)

这个其实不是问题，碰到时将趋势图的采样间隔拉到最小，仔细比对一下，就能验证警报的准确性。而对于聚合很复杂的警报，可以先写一条 Recording Rule, 再针对 Recording Rule 产生的新指标来建警报。这种范式也能帮助我们更高效地去建分级警报(超过不同阈值对应不同的紧急程度)

group_interval 会影响 resolved 通知

Alertmanager 里有一个叫 group_interval 的配置，用于控制同一个 group 内的警报最快多久通知一次。这里有一个问题是 firing(激活) 和 resolved(已消除) 的警报通知是共享同一个 group 的。也就是说，假设我们的 group_interval 是默认的 5 分钟，那么一条警报激活十几秒后立马就消除了，它的消除通知会在报警通知的 5 分钟之后才到，因为在发完报警通知之后，这个 Group 需要等待 5 分钟的 group_interval 才能进行下一次通知。

这个设计让”警报消除就立马发送消除通知”变得几乎不可能，因为假如把 group_interval 变得很小的话，警报通知就会过于频繁，而调大的话，就会拖累到消除通知。

这个问题修改一点源码即可解决，不过无伤大雅，不修也完全没问题。

最后一条：不要忘记因何而来

最后一条撒点鸡汤：监控的核心目标还是护航业务稳定，保障业务的快速迭代，永远不要忘记因何而来。

曾经有一端时间，我们追求”监控的覆盖率”，所有系统所有层面，一定要有指标，而且具体信息 label 分得越细越好，最后搞出几千个监控项，不仅搞得眼花缭乱还让 Prometheus 变慢了。

还有一段时间，我们追求”警报的覆盖率”，事无巨细必有要有警报，人人有责全体收警报(有些警报会发送给几十个人)。最后当然你也能预想到了，告警风暴让大家都对警报疲劳了。

这些事情乍看起来都是在努力工作，但其实一开始的方向就错了，监控的目标绝对不是为了达到 xxx 个指标，xxx 条警报规则，这些东西有什么意义?

依我看，负责监控的开发就算不是 SRE 也要有 SRE 的心态和视野，不要为监控系统的功能或覆盖面负责(这样很可让导致开发在监控里堆砌功能和内容，变得越来越臃肿越来越不可靠)，而要为整个业务的稳定性负责，同时站在稳定性的投入产出比角度去考虑每件事情的性质和意义，不要忘记我们因何而来。

【编辑推荐】

1. 微软开源的可视化工具，未免太酷炫了吧
2. 接私活必备的 10 个开源项目！
3. 各种NLP操作难实现？谷歌开源序列建模框架Lingvo
4. 自由开源 Linux 手机 Librem 5 第二批将延期发货
5. 开源 Community 对我来说意味着什么

（编辑：ASP站长网）