《Prometheus Up & Running》阅读

最近读完了这本讲监控的书：Prometheus Up & Running，学到很多东西，在博客上推荐一下。

可以将这本书的读者分成三种角色：

1. 应用程序的开发者，需要使用 Prometheus 来监控自己的应用；
2. SRE，需要监控应用以及服务器的运行状态；
3. 监控系统的维护者，可能也是 SRE，需要维护和部署 Prometheus。

全书分成了 6 个部分：

1. 介绍配 Prometheus 的一些概念，工作的模式，核心的思想。比如数据不是“完全准确的”，“拉取的模型”，存储，监控面板等等；
2. 介绍了应用的 Metrics 如何暴露，Metrics 的类型，一些 Prometheus 的概念（更详细）等等；
3. Prometheus 现在的周边生态已经比较完善了，这一部分介绍如何使用已有的 Exporter 以及如何自己写 Exporter；
4. 介绍如何使用 PromQL 做查询，PromQL 是一个完整并且强大（图灵完备的）查询语言；
5. 介绍如何配置告警，一些核心思想，工作原理，需要避免的误区等等；
6. Prometheus 的部署，如何扩大存储的规模，如何解决性能问题，如何提高查询速度等；

那么回到上面的三种角色，对于工作于监控领域的 SRE 来说，推荐阅读 1-6 章，每一章都会有所启发。对于普通的 SRE 来说，推荐阅读 1-6 章，因为监控可以说是 SRE 工作的中心，如果不会用监控就和瞎子一样，如果精通监控可以让很多事情事半功倍。对于应用开发者来说，推荐阅读 1-6 章。开发者需要熟悉 Prometheus 里面的一些概念，才能正确的 Expose metrics，所以 1-3 章是开发者必读的；同时开发者又是最了解自己的系统的人，所以监控面板的主要编辑者应该是开发者，写 PromQL 就变得重要了，所以第 4-5 章也是必读的。第 6 章就有一些微妙了，Prometheus 其实本质上是一个很简单的架构，但是要在大规模下运行，就需要其他的一些方案。比如我们公司用的是 Thanos，其实它的背后是一个个独立的 Prometheus，Grafana 的查询直接去查 Thanos，Thanos 就表现的是一个无限大的 Prometheus 一样。我刚接触这个架构经常犯的一个错误是在 alerting rule 里面写聚合的查询，导致很多 alerts 没发出来。因为 alerts 在本质上还是在每一个 Prometheus 上做聚合（evaluation）的，那个时候每个 Prometheus 计算自己本身的数据，认为都没有达到 firing 的状态，但是实际将每一个 Prometheus 聚合起来已经达到了。所以，要正确地使用这一套系统，其实还是要了解背后的部署状态比较好。

要是说读完这本书我学到最重要的一点的话，就是：SRE 的效率和正确性同等重要。

去监控现象而不是监控原因，花很多努力让 labels 变得有意义，在工作被 page 的次数和问题发现时间做平衡而不是一味追求快速发现问题，等等。表面上看这些都是在提高 SRE 的幸福感，但是本质上也是提高软件质量和用户体验的正确道路。

要说这本书的缺点的话，就是感觉很多例子都举得不是很好，好的例子应该从现实中找，但是书中的有些例子太刻意了。大部分的例子也有点难运行（和监控这个话题也有关，这本书没有处处将例子的完整配置写出来，可能也太占篇幅了，就导致不是所有的例子都可以复现的），以至于有些话题有些抽象，不太好理解。但是以后遇到问题可以找到相关的章节，再找一下灵感。

现在的监控系统感觉正确性已经做得很好了，需要提高的是体验上的问题，比如部署上的扩展性，UI 上的配置，如何可维护等等。虽然从 Grafana 到 Prometheus 到 Alert 都可以用过 yaml 来配置，做到 gitops，但是在一个很大的团队下，配合起来太痛苦了。最后都会走向 UI 的配置吧，UI 如果没有专业的人来设计，又会做的很难用。难用的话就不会做到 Easy to change, 最后又会做的难以维护。听起来很像是一个悖论呢……

最后推荐一下 My Philosophy on Alerting 这篇文章，Google 的 SRE 写的。

---