目录
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等开源社区获取。
9639
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
