《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 写的。



《Prometheus Up & Running》阅读”已经有4条评论

Leave a comment

您的电子邮箱地址不会被公开。 必填项已用 * 标注