目录

1. 起源

2. Prometheus 架构

 2.1 指标收集

2.2 服务发现

2.3 聚合和警报

2.4 查询数据

2.5 服务自治

2.6 冗余和高可用性

2.7 可视化

3. Prometheus数据模型

3.1 指标名称

3.2 标签

3.3 采样数据

3.4 符号表示

3.5 保留时间

4. 安全模型

5. Prometheus生态系统

6. 附录

---

1. 起源

Prometheus最初由前谷歌SRE Matt T. Proud开发，并转化成一个研究项目，最终于2015年1月发布。

Prometheus提供近实时的、基于动态云环境和容器的微服务的内省监控。它专注于现在正在发生的事情，而不是追踪数周/月前的数据。

Prometheus由Golang语言编写，Apache 2.0许可证下授权，孵化于云原生计算基金会。

2. Prometheus 架构

Prometheus通过抓取/拉取服务中暴露的时间序列数据来工作。时间序列数据通常由应用程序本身通过客户端库或者exporter(导出器)的代理来作为HTTP端点暴露。

当前已有很多exporter和客户端库，支持多种编程语言、框架和开源应用程序，如Apache Web服务器和Mysql数据库等。

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

 2.1 指标收集

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

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

2.2 服务发现

可以通过多种方式来处理主要监控的资源的发现，有如下方式：

• 用户提供的静态资源列表
• 基于文件的发现。如使用配置管理工具生成在Prometheus中可以自动更新的资源列表。
• 自动发现。如查询Consul等数据存储，在Amazon或Google中运行实例，或使用DNS SRV记录来生成资源列表。

2.3 聚合和警报

服务器还可以查询和聚合时间序列数据，并创建规则来记录常用的查询和聚合。允许基于现有的数据创建出新的时间序列数据，如根据请求数和失败数计算失败率，或者产生类似求和等聚合。

Prometheus还可以定义警报规则，这些都是系统配置的在满足条件时触发警报的标准。Prometheus服务器没有内置警报工具，而是将警报从Prometheus服务器推送到名为Alertmanager（警报管理器）的单独服务器。Alertmanager可以管理、整合和分发各种警报到不同的目的地。当然在发出电子邮件报警时，能防止重复发送。

2.4 查询数据

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

2.5 服务自治

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

2.6 冗余和高可用性

冗余和高可用性侧重弹性而非数据持久性。Prometheus可以单节点部署，也可以高可用（HA模式）部署，使用两个或者多个配置相同的Prometheus服务器来收集时间序列数据，并且所有生成的警报都由可消除重复警报的高可用Alertmanager集群来处理。相关的冗余架构如下：

 

2.7 可视化

可视化通过内置表达式浏览器提供，并且与开源仪表板Grafana集群（笔者当前所在公司使用该组件），当然也支持其他仪表盘。

3. Prometheus数据模型

在处理Prometheus收集的时间序列数据时，可以使用一个多维时间序列数据模型。这个时间序列数据模型结合了时间序列名称和称为标签（Label）的键值对，这些标签提供了维度。每个时间序列由时间序列名称和标签的组合唯一标识。下面会详细说这些概念。

3.1 指标名称

在一段时间内，收集到有关于业务相关的指标，如website_visits_total为网站访问数，http_response_error_total为Http错误结果数量。

Prometheus指标的名称可以包含ASCII字符、数字、下划线和冒号。

3.2 标签

标签为Prometheus数据模型提供了维度，为特定时间序列添加上下文。比如查询指标http_response_error_total时，可以根据服务区域标签得到各区域的结果。标签可以在指标统计的过程中进一步细分。如http_response_error_total是总的指标，通过服务所在Region作为标签可以查询到亚太、美东、欧洲等区域的http_response_error_total指标。

标签共分为两大类：插桩标签（instrumentation label）和目标标签（target label）。

插桩标签来自被监控的资源，如在客户端或者exporter抓取前制定的标签，也就是上报指标数据到

Prometheus前就会制定这些标签。目标标签更多地与架构相关，可能会识别时间序列所在的数据中心，它是由Prometheus在抓取期间和之后添加的。

标签名称可以包含ASCII字符、数字和下划线。但带有_前缀的标签名称保留给Prometheus内部使用。

3.3 采样数据

时间序列的真实值是采样（sample）的结果，包含两部分：

• 一个float64类型的数值
• 一个毫秒精度的时间戳

3.4 符号表示

Prometheus会将时间序列表示为符号（notation），如下。

<time series name>{<label name> = <label value>, ...}

例如，带有标签的total_error_response_http时间序列可能如下所示。

total_error_response_http{site="MegaApp",location="NJ",instance="HttpWebServer",job="HttpWeb"}

以上表达式，首先是时间序列名称，后面跟着一组键值对标签。通常所有时间序列都有一个instance标签（标识源主机、NODE或者服务）以及一个job标签。

3.5 保留时间

Prometheus为短期监控和警报需求而设计。默认情况下，在其数据库保留15天的时间序列数据。如需保留更长时间的数据，建议将所需数据发送到远程的第三方平台。当然Prometheus提供了写入外部的存储能力。

4. 安全模型

Prometheus可以通过多种方式进行配置和部署，于安全方面有以下两个假设：

• 不受信任的用户将能够访问Prometheus服务器的HTTP API，从而访问数据库中的所有数据。
• 只有受信任的用户才能访问Prometheus命令行、配置文件、规则文件和运行时配置。

从Prometheus 2.0开始，默认情况下某些HTTP API的管理功能被禁用。

Prometheus及其组件不提供任何服务器端的身份验证、授权或加密，如有需要，则需自己实施安全控制。

5. Prometheus生态系统

Prometheus生态系统有Prometheus项目本身提供的组件以及丰富的开源工具和套件组成，其核心仍然是Prometheus服务器，当然也包括Alertmanager。

Prometheus项目还包括一系列exporter，用于监控应用程序和服务，并在端点上公开相关指标进行抓取。核心exporter支持常见工具，如Http web服务器、数据库等。当然也有其他开源的exporter，可以去Prometheus社区查看。

Prometheus也发布了一系列客户端库，支持Java、Golang、Ruby、Python等主流语言接入。其他客户端库可以从github等开源社区获取。

6. 附录

• prometheus官网
• Prometheus文档
• prometheus github源码
• grafana 官网