Prometheus 监控实战（三）：Prometheus 架构

很久以前，加利福尼亚州山景城有一家名为 Google 的公司。该公司推出了大量产品，其中最著名的是广告系统和搜索引擎平台。为了运行这些不同的产品，该公司建立了一个名为 Borg 的平台。Borg 系统是：“一个集群管理器，可以运行来自成千上万个不同应用程序的成千上万个作业，它跨越多个集群，每个集群都有数万台服务器。”开源容器管理平台 Kubernetes 的很多部分都是对 Borg 平台的传承。在 Borg 部署到 Google 后不久，该公司意识到这种复杂性需要一个同等水平的监控系统。Google 建立了这个系统并命名为 Borgmon。Borgmon 是一个实时的时间序列监控系统，它使用时间序列数据来识别问题并发出警报。

Prometheus 的灵感来自谷歌的 Borgmon。它最初由前谷歌 SRE Matt T. Proud 开发，并转为一个研究项目。在 Proud 加入 SoundCloud 之后，他与另一位工程师 Julius Volz 合作开发了 Prometheus。后来其他开发人员陆续加入了这个项目，并在 SoundCloud 内部继续开发，最终于 2015 年 1 月将其发布。

与 Borgmon 一样，Prometheus 主要用于提供近实时的、基于动态云环境和容器的微服务、服务和应用程序的内省监控。SoundCloud 是这些架构模式的早期采用者，而 Prometheus 的建立也是为了满足这些需求。如今，Prometheus 被更多的公司广泛使用，通常用来满足类似的监控需求，但也用来监控传统架构的资源。

Prometheus 专注于现在正在发生的事情，而不是追踪数周或数月前的数据。它基于这样一个前提，即大多数监控查询和警报都是从最近的（通常是一天内的）数据中生成的。Facebook 在其内部时间序列数据库 Gorilla 的论文中验证了这一观点。Facebook 发现 85％的查询是针对 26 小时内的数据。Prometheus 假定你尝试修复的问题可能是最近出现的，因此最有价值的是最近时间的数据，这反映在强大的查询语言和通常有限的监控数据保留期上。

Prometheus 由开源编程语言 Go 编写，并且是在 Apache 2.0 许可证下授权的。它孵化于云原生计算基金会（Cloud Native Computing Foundation）。

Prometheus 通过抓取或拉取应用程序中暴露的时间序列数据来工作。时间序列数据通常由应用程序本身通过客户端库或称为 exporter（导出器）的代理来作为 HTTP 端点暴露。目前已经存在很多 exporter 和客户端库，支持多种编程语言、框架和开源应用程序，如 Apache Web 服务器和 MySQL 数据库等。

Prometheus 还有一个推送网关（push gateway），可用于接收少量数据—例如，来自无法拉取的目标数据（如临时作业或者防火墙后面的目标）。

关于 Prometheus 的具体架构如图所示。

Prometheus 架构

指标收集

Prometheus 称其可以抓取的指标来源为端点（endpoint）。端点通常对应单个进程、主机、服务或应用程序。为了抓取端点数据，Prometheus 定义了名为目标（target）的配置。这是执行抓取所需的信息—例如，如何进行连接，要应用哪些元数据，连接需要哪些身份验证，或者定义抓取将如何执行的其他信息。一组目标被称为作业（job）。作业通常是具有相同角色的目标组—例如，负载均衡器后面的 Apache 服务器集群，它们实际上是一组相似的进程。

生成的时间序列数据将被收集并存储在 Prometheus 服务器本地，也可以设置从服务器发送数据到外部存储器或其他时间序列数据库。

服务发现

可以通过多种方式来处理要监控的资源的发现，包括：

• 用户提供的静态资源列表。

• 基于文件的发现。例如，使用配置管理工具生成在 Prometheus 中可以自动更新的资源列表。

• 自动发现。例如，查询 Consul 等数据存储，在 Amazon 或 Google 中运行实例，或使用 DNS SRV 记录来生成资源列表。

聚合和警报

服务器还可以查询和聚合时间序列数据，并创建规则来记录常用的查询和聚合。这允许你从现有时间序列中创建新的时间序列，例如，计算变化率和比率，或者产生类似求和等聚合。这样就不必重新创建常用的聚合，例如用于调试，并且预计算可能比每次需要时运行查询性能更好。

Prometheus 还可以定义警报规则。这些是为系统配置的在满足条件时触发警报的标准，例如，资源时间序列开始显示异常的 CPU 使用率。Prometheus 服务器没有内置警报工具，而是将警报从 Prometheus 服务器推送到名为 Alertmanager（警报管理器）的单独服务器。

Alertmanager 可以管理、整合和分发各种警报到不同目的地—例如，它可以在发出警报时发送电子邮件，并能够防止重复发送。

查询数据

Prometheus 服务器还提供了一套内置查询语言 PromQL、一个表达式浏览器（如图 2-2 所示）以及一个用于浏览服务器上数据的图形界面。

Prometheus 表达式浏览器

自治

每个 Prometheus 服务器都设计为尽可能自治，旨在支持扩展到数千台主机的数百万个时间序列的规模。数据存储格式被设计为尽可能降低磁盘的使用率，并在查询和聚合期间快速检索时间序列。

为了速度和可靠性，建议 Prometheus 服务器充分使用内存（Prometheus 在内存中做很多事）和 SSD 磁盘。

冗余和高可用性

冗余和高可用性侧重弹性而非数据持久性。Prometheus 团队建议将 Prometheus 服务器部署到特定环境和团队，而不是仅部署一个单体 Prometheus 服务器。如果你确实要部署高可用 HA 模式，则可以使用两个或多个配置相同的 Prometheus 服务器来收集时间序列数据，并且所有生成的警报都由可消除重复警报的高可用 Alertmanager 集群来处理。Prometheus 冗余架构如图 2-3 所示。

Prometheus 冗余架构

可视化

可视化通过内置表达式浏览器提供，并与开源仪表板 Grafana 集成。此外，Prometheus 也支持其他仪表板。

作者介绍：

詹姆斯·特恩布尔（James Turnbull）是一位作家和工程师。他最近出版的书包括《The Packer Book》《The Terraform Book》和《The Art of Monitoring》，以及关于开源容器虚拟化技术的《The Docker Book》，还有关于开源日志工具的《The Logstash Book》。詹姆斯还撰写了两本关于 Puppet 的书：《Pro Puppet》和《Pulling Strings with Puppet》。同时他还是另外三本书的作者：《Pro Linux System Administration》《Pro Nagios 2.0》和《Hardening Linux》。

他目前是 Empatico 公司的首席技术官，并且曾担任过 Kickstarter 公司的首席技术官、Docker 公司服务和支持副总裁、Venmo 公司工程副总裁以及 Puppet 公司技术运营副总裁。他喜欢品尝美食、喝酒、读书、摄影和养猫。

本文节选自《Prometheus 监控实战》，更多内容请点击此处查看。

相关阅读：

Prometheus 监控实战（二）：监控方法论与报警通知

Prometheus 监控实战（一）：监控机制