很久以前，加利福尼亚州山景城有一家名为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 监控实战（一）：监控机制

创作场景

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