Prometheus 文档（非官方）

Graphite 致力于成为具有查询语言和图形特性的被动的（passtive）时间序列数据库。其它的任何问题都可以通过外部组件解决。

Prometheus 是一个完整的监控和趋势分析系统，包括内置的主动抓取，存储，查询，查询，绘图的基于时间序列数据库的告警。 它有自己的世界观（哪些 endpoints 应该存在，什么时间序列模式意味着有问题等等），并且尝试积极的寻找错误。

Graphite 存储具名的时间序列的数值样本，跟 Prometheus 很像。然而，Prometheus 的元数据模型更加的丰富： Graphite 的指标名称由点分隔的部分组成，隐式的表达多维度。Prometheus 通过键值对的标签来显示的表达， 然后附加到指标名称上。这样查询语言可以通过这些标签轻松的进行过滤、分组和匹配。

进一步，尤其是 Graphite 和 Statsd 一起工作时，通常在所有监控的实例上仅存储聚合数据，而不是将实例作为一个维度， 然后深入分析单个有问题的实例。

比如，存储 API server 的 HTTP 请求的返回码为 500 并且方法为 POST 到 /tracks 的到达点通常在 Graphite/StatsD 这样表示：

stats.api-server.tracks.post.500 -> 93

在 Prometheus 中样本数据编码是这样（假定是三个 api-server 实例）：

api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample1>"} -> 34
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample2>"} -> 28
api_server_http_requests_total{method="POST",handler="/tracks",status="500",instance="<sample3>"} -> 31

Graphite 使用 Whisper 存储时间序列数据在本地，是一个 RRD 风格的数据库，它希望样本以固定时间间隔到达。 每个时间序列都被存储在分隔的文件中，一段时间后，新样本会覆盖旧样本。

Prometheus 也是每个时间序列单独的文件，但是允许在获取数据或者与运算规则时以任意时间间隔存储样本。 由于仅增加了新的样本，所以老的数据可以被任意保留。Promethues 对于很多短暂的经常变化的时间序列可以运作良好。

Prometheus 除了更容易运行和集成到你的环境之外，还提供了丰富的数据模型和查询语言。 如果你想要一个长期保留历史数据的集群方案，Graphite 可能是一个更好的选择。

为了公平的比较，我们还比如把 Kapacitor 和 InfluxDB 放一起考虑，它们结合一起来，可以解决 Prometheus 和 Alertmanager 相同的问题。

The same scope differences as in the case of Graphite apply here for InfluxDB itself。 此外，InfluxDB 还提供了连续查询，等价于 Prometheus 的记录规则（recording rules）。

Kapacitor 的范围是 Prometheus 记录规则，告警规则和 Alertmanager 的通知功能的组合。 Prometheus 提供了更加强大的查询语言来进行图形显示和告警。Prometheus 告警管理器还提供了告警分组、去重和静默等功能。

和 Prometheus 一样，InfluxDB 数据模型有有键值对作为标签（label），名字叫做标签（tags）。 此外，InfluxDB 还有二级标签，称之为字段（fields），但适用范围有限。 InfluxDB 支持纳秒精度的时间戳，float64，int64，bool 和字符串数据类型。相比而言，Prometheus 支持 float64 的数据类型， 但对字符串和毫秒的精度支持有限。

InfluxDB 使用 日志结构合并树的变种来存储带有时间分片的预写日志的存储。与 Prometheus 每个时间序列仅附加文件的方法相比， 此方法更适合记录事件。

日志、指标和图形，我的天 描述了事件日志和指标记录的不同。

Prometheus 服务器彼此独立运行，仅依靠本地存储来实现核心功能：抓取、规则处理和告警。开源的 InfluxDB 版本类似。

设计上，商业版本的 InfluxDB 产品是一个分布式的存储集群，存储和查询由多个节点一次处理。

这意味着商业的 InfluxDB 将更易于水平扩展，而且意味着你必须从一开始就要管理分布式系统的复杂性。 Prometheus 运行起来更简单，但是有些时候你需要根据产品、服务和数据中心等类似的边界明确的分片。 独立服务器（可以并行冗余运行）也可以为您提供更好的可靠性和故障隔离。

Kapacitor 的开源版本没有规则、告警或者通知的内置分布式/冗余选项，可以由用户通过手动分片来扩展，跟 Promethues 像似。 Influx 提供了 企业级的 Kapacitor，支持高可用/冗余的告警系统。

相比之下，Prometheus 和 Alertmanager 通过运行多余的 Prometheus 副本，然后使用告警管理器的高可用性模式提供了完全开源冗余选项。

两个系统有很大的相似性。都有标签（一个叫 label，一个叫 tag）来高效的支持多维指标。都有基本相同的数据压缩算法。 两个都有广泛的集成，包括彼此之间的集成。都有 hooks 允许你来进一步扩展它们，例如使用统计工具分析数据或者执行自动化操作。

InfluxDB 更好的地方：

• 当你需要进行事件记录的时候。
• 商业选项提供了 influxDB 集群选项，这对于长期数据存储会更好。
• 最终在副本之间保持一直的数据视图。

Prometheus 更好的地方：

• 当你的主要面对的是指标的时候。
• 更强劲的查询语言、告警和通知功能。
• 图形和告警的可用性和正常运行时间（uptime）更好。

InfluxDB 由一家商业公司按照开放核心（open-core）模型进行维护，提供了像闭源集群，托管和支持的高级功能。 Prometheus 是一个完全开源的独立项目，由许多公司和个人维护，其中一些还提供商业服务和支持。

这里的适用范围和 Graphite 应用相同。

OpenTSDB 的数据模型几乎和 Prometheus 相同：时间序列由一组任意的键值对标识（OpenTSDB 的 tags 是 Prometheus 的 labels）。所有的指标数据是 存储在一起的，限制指标的基数。 虽然有一些细微的差异：Prometheus 允许标签值中包含任务的字符，OpenTSDB 做了更多的限制。OpenTSDB 也缺乏完整的查询语言，只允许简单的聚合和数学运算。

OpenTSDB 是在 Hadoop 和 HBase 之上实现的，这意味着水平扩展比较简单，但是你一开始就要接受运行 Hadoop/HBase 集群的总体复杂性。

Prometheus 最初运行起来会很简单，但是一旦超出单个节点的容量，就需要明确的分片。

Prometheus 提供了更丰富的查询语言，可以处理更高的基数指标，并且是构建完整监控系统的一部分。如果你已经在运行 Hadoop 并重视长期存储的优势，那么 OpenTSDB 是一个不错的选择。

Nagios 主要基于脚本退出码进行告警。它们被称为 "checks"。单个告警支持静默，但是不会进行分组，路由或者重复数据删除。

有各种各样的插件。比如，通过管道传输几千字节的 perfData 插件，可以返回时间序列数据库（比如 Graphite）或者使用 NRPE 在远程机器上运行检查。

Nagios 是基于主机的。每个主机可以有有一个或者多个服务，并且每个服务执行一项检查。

没有标签或者查询语言的概念。

除了检查状态之外，Nagios 本身没有存储空间。有些插件可以存储诸如可视化的数据。

Nagios 服务器是独立的，所有的检查配置均通过文件进行。

Nagios 适用于黑盒（blackbox）探测足够小型或者静态的系统的基本监控。

如果你想要白盒监控，或者动态的或者基于云环境的，那么 Promethesu 是不错的选择。

The same general scope differences as in the case of Nagios apply here.

还有一个 套接字客户端，允许将临时检查结果推送到 Sensu 中。

Sensu 和 Nagios 有相同粗糙的数据模型。

Sensu 使用 Redis 来存储监控数据，包括 Sensu 客户端注册表，检查结果，检查执行记录，和当前事件数据。

Sensu 有许多组件。它使用 RabbitMQ 传送，Redis 存储当前状态，并使用单独的服务器进行处理和 API 访问。

可以将 Sensu 部署的所有组件（RabbitMQ，Redis 和 Sensu Server/API）集群化，以实现高可用和冗余配置。

如果你已经有 Nagios 安装并且希望水平扩展，或者想利用 Sensu 的自动注册功能，那么 Sensu 是一个不错的选择。

如果你想要做白盒监控，或者动态的或者基于云环境的，那么 Prometheus 是一个不错的选择。

Prometheus 是具有活跃的生态的开源系统监控和告警工具包。

见上一小结。

Prometheus 主服务器独立运行，没有外部依赖。

是的，在两台或者多台独立的计算机中运行相同的 Prometheus 服务即可。相同的告警将被 Alertmanager 删除。

为了 Alertmanager 的高可用，你可以在 mesh 集群中运行多个实例，并配置 Prometheus 服务向每个实例发送通知。

实际上有多种扩展方式来联邦（federate）Prometheus。阅读 Robust Perception 的 Scaling and Federating Prometheus 获取更多信息。

大部分组件都是由 Go 写的。还有些是用 Java、Python 和 Ruby。

Github 上的所有仓库都已到达 1.0.0 版本，都符合 语义版本。重大更改或者主要版本都是用增量表示。 实验性的组件可能会出现例外，但是例外情况会被提前声明。

即使没有到达 1.0.0 的仓库，通常也是相当稳定的。我们的目标是为每个仓库都制定合适的发布流程最终发布 1.0.0。 无论如何，发行说明中都会指出重大更改（由 CHANGE 来标注）或者针对尚未正式发布的组件进行明确的沟通。

使用拉取（pulling）有很多的优点：

• 开发更改时，可以在笔记本电脑上运行监控；
• 可以更加轻松的判断目标（target）是否挂了（down）；
• 你可以手动在 web 浏览器上访问观察运行情况；

总而言之，我们认为 pulling 比 push 要略好，但是在选型监控系统时，这些不是重点。

对于有必须要 push 的情况，我们提供了 Pushgateway。

精简的答案：别这么干！使用类似 ELK 技术栈来替代它。

略长的答案：Prometheus 是一个收集和处理指标的系统，而不是一个事件日志系统。 Raintank 的博客文章：Logs and Metrics and Graphs, Oh My! 提供了有关日志和指标差异的更多信息。

如果你想从系统日志中提取 Prometheus 指标，Google 的 mtail 可能会帮到你。

最初是由 Matt T. Proud 和 Julius Volz 私下写的。大部分最初开发都是 SoundCloud 赞助的。

现在是由很多公司和个人来共同维护和扩展的。

Apache License 2.0

经过广泛的研究，现在确定 'Prometheus' 的正确复数是 'Prometheis'。

是的，发送 SIGHUP 到 Promtheus 进程或者 HTTP POST 服务的 /-/reload 地址会重新加载配置文件。各种组件会尝试妥善处理失败的更改。

是的，使用 Alertmanager。当前支持以下外部系统：

• 邮件
• 通用的 Webhook
• HipChat
• OpsGenie
• PagerDuty
• Pushover
• Slack

是的，生产环境推荐使用 Grafana。也有 控制台模板。

为了避免时区混乱，尤其是在涉及到所谓的夏时制，我们决定在内部使用 Unix 时间和 UTC 用于所有组件中的显示。 在引入 UI 的时候再选择时区。有关此工作的当前状态，请查看 issue #500。

请查看 Client Libraries，支持很多语言。

如果你有兴趣为新的语言提供客户库，请查看 暴露格式。

是的，Node Exporter 提供了在 Linux 和其他 Unix 系统上暴露一些通用的系统级别指标比如 CPU 使用率，内存、磁盘利用率， 文件系统完整性和网络带宽。

是的，SNMP Exporter 允许监控支持 SNMP 的设备。

是的，使用 Pushgateway。也可以查看批处理作业监控的 最佳实践。

查看 Exporter 和集合。

是的，对于无法直接使用 Java 客户端监控的应用程序，你可以使用 JMX Exporter ，可以独立使用或者作为 Java 代理来用。

不同的语言的客户端库可能不同。对 Java 而言，基准测试表示添加 Counter/gauge 会增加 12-17ns。 除了一些延迟要求非常高的代码之外，其它的可以忽略不计。

我们限制使用 64-bit 浮点型是为了简化设计。IEEE 754 双精度二进制浮点格式 支持最大为 2^53 的整数精度。

Supporting native 64 bit integers would (only) help if you need integer precision above 2^53 but below 2^63. In principle, support for different sample value types (including some kind of big integer, supporting even more than 64 bit) could be implemented, but it is not a priority right now. A counter, even if incremented one million times per second, will only run into precision issues after over 285 years.

注意：Prometheus 团队在 2018 年 8 月 11 日的开发峰会上改变其立场，该项目的 roadmap 现在已经支持 TLS 和身份验证。 更改代码后将更新此文档。

尽管 TLS 和身份验证是经常需要的功能，但是我们故意没有在 Prometheus 的任何服务组件中实现他们。这两个都是很很多不同的选项和参数（仅 TLS 就 10+ 个选项），我们的决定是专注于构建最佳的监控系统，而不是在每个服务组件中都完整的支持 TLS 和身份认证的最佳方案。

如果你需要 TLS 或者身份认证，我们建议在 Prometheus 前面放一个反向代理。比如：使用 Nginx 向 Prometheus 添加基本的身份验证。

把你的 prometheus.yml 从宿主机挂载到容器中：

docker run \
       -p 9090:9090 \
       -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml \
       prom/prometheus

或者添加额外的卷到配置中：

docker run \
       -p 9090:9090 \
       -v /path/to/config:/etc/prometheus \
       prom/prometheus

为了避免在外部管理配置文件，配置可以添加到镜像中。如果配置文件是静态的，并且在所有的环境中都是相同的，这种方法很不错。

为此，创建一个有 Prometheus 配置和 Dockerfile 的新目录，如下：

FROM prom/prometheus
ADD prometheus.yml /etc/prometheus/

然后构建和运行：

docker build -t my-prometheus .
docker run -p 9090:9090 my-prometheus

一个更高级的做法时，使用工具在开始时动态生成配置，甚至可以使用守护程序定期更新。

一些第三方的配置管理系统：

Ansible

• Cloud Alchemy/ansible-prometheus

Chef

• rayrod2030/chef-prometheus

Puppet

• puppet/prometheus

SaltStack

• saltstack-formulas/prometheus-formula

Prometheus 表达语言中，一个表达式或者子表达式可以计算为以下四中类型之一：

• 瞬时向量 一组时间序列，每个时间序列包含一个样本，所有的样本有相同的时间戳；
• 范围向量 一组时间序列，每个时间序列包含多个时间序列样本；
• 标量（Scalar） 一个简单的浮点型值；
• 字符串（String） 一个字符串值，当前未使用；

返回值类型是由查询表达式决定的，比如瞬时向量是可以直接被绘制成图形的。

irate(v range-vector) 计算范围内时间序列的 每秒 瞬时增加率，是 基于最后两个点 计算的。数值中断（比如机器重启，计数器重置）会自动调整。

rate(v range-vector) 计算范围内事件序列的 平均每秒 的增长率，是 基于所有数据点的 。

irate 和 rate 都只能和计数器（Counter）一起使用。因为两个计算的算法不同，所以使用场景略微不同：

• irate 适用于快速变化计数器
• rate 适用于告警以及计数器缓慢变化的计数场景下的图形展示

不管是 irate 还是 rate 最终的结果是速率，不是增长的值，这一点很重要。有如下样本数据：

2201 @1570868068.053
2204 @1570868083.053
2205 @1570868098.053
2216 @1570868113.053

irate 的计算方法为：

(2216-2205)/(1570868113.053-1570868098.053) = 0.7333333333333333

rate 的计算方法为：

(2216-2205)/(1570868113.053-1570868098.053) = 0.7333333333333333
(2205-2204)/(1570868098.053-1570868083.053) = 0.06666666666666667
(2204-2201)/(1570868083.053-1570868068.053) = 0.2
(0.7333333333333333 + 0.06666666666666667 + 0.2) / 3 = 0.3333333333333333

一开始对 TSDB 不是很了解的情况下，不自己算一下还是不是很好理解的。

根据上面的计算方法也可以看出：

• 对于 irate 时间段的选择 [1m] 还是 [5m] ，只要有数据，就没区别； 而 rate 的区别就很大，时间越长越平滑；
• rate 不会把数值中的毛刺直接暴露出来，通过平均值计算潜在的问题就是会有 长尾问题 。

选择 irate 还是 rate 视业务场景而定。

回包格式是 JSON，每个成功的 API 状态码都是 2xx 。

无效的 API 请求会返回 JSON 错误对象和 HTTP 响应码之一：

• 400 Bad Request 参数不存在或者错误
• 422 Unprocessable Entity 表达式不可被执行
• 503 Service Unavailabl 请求超时或者中断

对于没有到达 API 端点（endpoint）之前的错误，返回其它的非 2xx 的代码。

如果存在不会影响正常执行的错误，则会返回一系列的警告。成功执行的数据会返回在 data 字段。

回包的 JSON 格式如下：

{
    "status": "success" | "error",
    "data": <data>,

    // Only set if status is "error". The data field may still hold
    // additional data.
    "errorType": "<string>",
    "error": "<string>",

    // Only if there were warnings while executing the request.
    // There will still be data in the data field.
    "warnings": ["<string>"]
}

输入的时间格式可以是：

• RFC3339 格式
• Unix 秒级别的时间戳，可以带小数位

输出的时间格式一般是 Unix 秒级别的时间戳。

名字中重复的参数以 [] 方式展现。

<series_selector> 是类似 http_requests_total 和 http_requests_total{method=~"(GET|POST)"} 这种格式的时间序列选择器的占位符， 而且需要 URL-encoded。

<duration> 是 [0-9]+[smhdwy] 格式的字符串的占位符，比如说 5m 表示持续 5 分钟。

<bool> 是布尔值 true false 字符串的占位符。

查询语言表达式可以在单个瞬间或者一段时间内求值。

表达式查询结果在 data 中的 result 属性中。JSON 不支持特殊的浮点值，比如 NaN Inf -Inf 等， 所以会被转换成 JSON 字符串，而不是原数字。