Day 7：Prometheus

讲到监控，Prometheus 应该算是最常被提及的其中一个工具，它是一套开源的监控与警报系统，最早由 SoundCloud 开发，并在 2016 年进入 CNCF 孵化器，後来於 2018 年毕业。

架构

那麽，Prometheus 究竟是做什麽用的呢？让我们来看看这张来自官方文件的架构图：

本体

Prometheus 的本体主要包含三个部分：

• Retrieval 代表的是它蒐集资料的元件，我们在架设 Prometheus 的时候需要设定他要从那些地方，如何去蒐集指标。
• TSDB 是 time series database 的缩写，里面存放的就是 Prometheus 收集来的各项数据，并且包含了时间戳的资讯，以方便我们根据时间查询。
• HTTP server 让我们可以透过 HTTP 请求，使用 PromQL （类似 SQL，查询 Prometheus 的资料用的）去查询它收集到的指标。并且它本身也有提供一个简易的 UI 介面可以视觉化目前收集的资料，可是在这部分，比较常见的做法应该还是使用 Grafana 来建立仪表板，预计後面会提到。

资料来源

Prometheus 采用 pull-based 的设计，也就是说并非由我们主动提供数据给 Prometheus server，而是我们在服务上面提供取得指标的方法（通常是透过对 /metrics 发 GET 请求），然後再由 Prometheus 采集指标。在官方文件可以看到已经有许多现成的 exporter，像是昨天提到的需要收集硬碟的使用率，就可以透过官方的 node exporter 做到。

然而在某些情况下，我们可能没办法提供一个可以拉取的介面给 Prometheus，这时候就需要主动推送指标给 Pushgateway，让他暂存这些指标，然後再由 server 去采集这些指标收进 TSDB 里面。具体的应用场景可以参考官方文件的分析。

Alertmanager

警报也是监控系统里面很重要的一环，Prometheus 里面就有提供一个专门做警报的元件，称为 Alertmanager，它可以收集从 Prometheus server 送过来的警报，再依据我们设立的规则分配至像是 email 或是 slack 等地方。

指标

在 Prometheus 里面，所有的资料都会被储存为 time series，也就是说每一笔资料都会配上一个时间戳。而指标除了储存单个数字以外，还可以在上面加上标签 (label) 以帮助我们替指标分类，举昨天谈到的黄金讯号之一的延迟来说好了，今天我们纪录了 HTTP 请求的处理时间，我们来可以替它加上像是 status code、URL 等等的标签，就可以帮助我们分离成功跟失败的请求，更好地反应出服务现在的状态。

小结

今天打的内容比我想像中的还要少不少...本来还希望可以把 Prometheus 跟一些其他常用的工具做一些比较的，像是跟 InfluxDB (TICK stack)，或是 Thanos、Cortex 之类的解决方案；也有打算来谈谈有关 OpenTelemetry 与监控生态圈的关系，或者说规范这件事对於软件开发的影响。

无奈於自身实务经验实在是不足，我就先将一些我看到的参考资料列在下方，希望有朝一日有机会可以补足这份遗憾吧。

参考资料

• OpenTelemetry 正式释出第一版规范
• Time Series Database Comparison
• Prometheus vs. InfluxDB: A Monitoring Comparison
• How the Cortex and Thanos projects collaborate to make scaling Prometheus better for all
• Introduction to InfluxData’s InfluxDB and TICK Stack