# 一切从巡检开始——Prometheus 的告警迭代小窍门

Prometheus 是 CNCF 的二号项目，大致相当于各种基于 K8s 的平台的标配监控方案了，其原始产品在高可用、性能等方面都有一些不足，好在几年来社区以及终端用户的持续贡献后，在大规模大流量的场景方面已经有了长足的进步。

Prometheus 具备 CNCF 中顶级项目的普遍优势：架构优雅、社区活跃、扩展方便、生态健康。它提供了大量的 Exporter，常见软件多数都会有对应的 Exporter 用于产生监控数据，另外借助 Prometheus API，能够很方便的编写自己的 Exporter。在查询方面，虽说 PromQL 的古怪语法经常遭人诟病，但的确能够编写非常灵活的查询和告警。

在实际落地过程中，监控和告警是非常重要的一个功能特性，但是不同项目、不同的运维团队、不同的工作负载，都有可能会有不同的告警关注点。告警信息是通常有成本的，在部分项目中可能还要走正式的上线/变更流程，因此通常来说都需要有一个平衡的过程，对告警项目以及告警阈值进行开发、测试、上线、反馈、调整等一系列迭代过程。

在项目过程中，我们可以采用一种巡检+告警的模式来完成这一迭代过程。简单来说分为这样几个大步骤：

1. 写代码，从配置文件中读取 PromQL 查询语句，使用 Rest API 从 Prometheus 中获取指标。
2. 将预备使用的告警指标写入配置文件。
3. 在巡检过程中执行这些查询，并生成报表。

在每次巡检过程中生成的报告里，着重关注这些新的监控数据，并把新数据和系统中对应的监控对象的实际情况进行对比，用多次巡检过程进行磨合之后，就可以上线到告警系统中，正式投入使用了。这种糙快猛的做法，一方面使用同样的语法规则，很方便的能在告警和巡检之间进行指标定义的迁移；另一方面，巡检的指标可以采用较为敏感的阈值设置，用于发现趋势性的或者重要但是紧急度不高的指标进行处理。

相对于告警来说，巡检的自由度稍大，并且没有外发成本，更能够方便的进行调整迭代，避免无用告警和过量告警。

另外推荐一个网站：[Awesome Prometheus Alerts](https://awesome-prometheus-alerts.grep.to/)，这里汇集了很多的告警规则代码，非常适合用在监控系统的初期建设上。