查看“Prometheus介绍”的源代码

=== Prometheus ===
Prometheus（普罗米修斯）是一套开源的监控&报警&时间序列数据库的组合，起始是由SoundCloud公司开发的。随着发展，越来越多公司和组织接受采用Prometheus，社会也十分活跃，他们便将它独立成开源项目，并且有公司来运作。Google SRE的书内也曾提到跟他们BorgMon监控系统相似的实现是Prometheus。现在最常见的Kubernetes容器管理系统中，通常会搭配Prometheus进行监控。

Prometheus基本原理是通过HTTP协议周期性抓取被监控组件的状态，这样做的好处是任意组件只要提供HTTP接口就可以接入监控系统，不需要任何SDK或者其他的集成过程。这样做非常适合虚拟化环境比如VM或者Docker 。

Prometheus应该是为数不多的适合Docker、Mesos、Kubernetes环境的监控系统之一。

输出被监控组件信息的HTTP接口被叫做exporter 。目前互联网公司常用的组件大部分都有exporter可以直接使用，比如Varnish、Haproxy、Nginx、MySQL、Linux 系统信息 (包括磁盘、内存、CPU、网络等等)，具体支持的源看：https://github.com/prometheus。

与其他监控系统相比，Prometheus的主要特点是：

一个多维数据模型（时间序列由指标名称定义和设置键/值尺寸）。

非常高效的存储，平均一个采样数据占~3.5bytes左右，320万的时间序列，每30秒采样，保持60天，消耗磁盘大概228G。

一种灵活的查询语言。

不依赖分布式存储，单个服务器节点。

时间集合通过HTTP上的PULL模型进行。

通过中间网关支持推送时间。

通过服务发现或静态配置发现目标。

多种模式的图形和仪表板支持。
 

=== Prometheus架构概览 ===
Prometheus通过抓取或拉取应用程序中暴露的时间序列数据来工作。时间序列数据通常由应用程序本身通过客户端库或称为exporter的代理来作为HTTP端点暴露。目前已经存在很多exporter和客户端库，支持多种编程语言、框架和开源应用程序。Prometheus还有一个推送网关（push gateway），可用于接收少量数据——例如，来自无法拉取的目标数据（如临时作业或者防火墙后面的目标）。

该图说明了普罗米修斯（Prometheus）及其一些生态系统组件的整体架构：

[[文件:Promethues-1.jpg|有框|居中|Promethues架构]]

它的服务过程是这样的Prometheus daemon负责定时去目标上抓取metrics(指标) 数据，每个抓取目标需要暴露一个http服务的接口给它定时抓取。

Prometheus：支持通过配置文件、文本文件、zookeeper、Consul、DNS SRV lookup等方式指定抓取目标。支持很多方式的图表可视化，例如十分精美的Grafana，自带的Promdash，以及自身提供的模版引擎等等，还提供HTTP API的查询方式，自定义所需要的输出。

Alertmanager：是独立于Prometheus的一个组件，可以支持Prometheus的查询语句，提供十分灵活的报警方式。

PushGateway：这个组件是支持Client主动推送metrics到PushGateway，而Prometheus只是定时去Gateway上抓取数据。

如果有使用过statsd的用户，则会觉得这十分相似，只是statsd是直接发送给服务器端，而Prometheus主要还是靠进程主动去抓取。

大多数Prometheus组件都是用Go编写的，它们可以轻松地构建和部署为静态二进制文件。访问prometheus.io以获取完整的文档，示例和指南。

==== 指标收集 ====
Prometheus称其可以抓取的指标来源为端点（endpoint）。端点通常对应单个进程、主机、服务或应用程序。为了抓取端点数据，Prometheus定义了名为目标（target）的配置。这是执行抓取所需的信息——例如，如何进行连接，要应用哪些元数据，连接需要哪些身份验证，或者定义抓取将如何执行的其他信息。一组目标被称为作业（job）。作业通常是具有相同角色的目标组——例如，负载均衡器后面的Apache服务器集群，它们实际上是一组相似的进程。生成的时间序列数据将被收集并存储在Prometheus服务器本地，也可以设置从服务器发送数据到外部存储器或其他时间序列数据库。
==== 服务发现 ====
可以通过多种方式来处理要监控的资源的发现，包括：
*用户提供的静态资源列表。
*基于文件的发现。例如，使用配置管理工具生成在Prometheus中可以自动更新的资源列表。
*自动发现。例如，查询Consul等数据存储，在Amazon或Google中运行实例，或使用DNSSRV记录来生成资源列表。
==== 聚合和警报 ====
服务器还可以查询和聚合时间序列数据，并创建规则来记录常用的查询和聚合。这允许从现有时间序列中创建新的时间序列，例如，计算变化率和比率，或者产生类似求和等聚合。这样就不必重新创建常用的聚合，例如用于调试，并且预计算可能比每次需要时运行查询性能更好。Prometheus还可以定义警报规则。这些是为系统配置的在满足条件时触发警报的标准，例如，资源时间序列开始显示异常的CPU使用率。Prometheus服务器没有内置警报工具，而是将警报从Prometheus服务器推送到名为Alertmanager（警报管理器）[插图]的单独服务器。Alertmanager可以管理、整合和分发各种警报到不同目的地——例如，它可以在发出警报时发送电子邮件，并能够防止重复发送。
==== 查询数据 ====
Prometheus服务器还提供了一套内置查询语言PromQL。
==== 自治 ====
每个Prometheus服务器都设计为尽可能自治，旨在支持扩展到数千台主机的数百万个时间序列的规模。数据存储格式被设计为尽可能降低磁盘的使用率，并在查询和聚合期间快速检索时间序列。提示 为了速度和可靠性，建议Prometheus服务器充分使用内存（Prometheus在内存中做很多事）和SSD磁盘。
==== 冗余和高可用性 ====
冗余和高可用性侧重弹性而非数据持久性。Prometheus团队建议将Prometheus服务器部署到特定环境和团队，而不是仅部署一个单体Prometheus服务器。如果你确实要部署高可用HA模式，则可以使用两个或多个配置相同的Prometheus服务器来收集时间序列数据，并且所有生成的警报都由可消除重复警报的高可用Alertmanager集群来处理。
==== 可视化可视化 ====
通过内置表达式浏览器提供，并与开源仪表板Grafana集成。此外，Prometheus也支持其他仪表板。
=== Prometheus的数据模型 ===
Prometheus从根本上所有的存储都是按时间序列去实现的，相同的metrics(指标名称) 和label(一个或多个标签) 组成一条时间序列，不同的label表示不同的时间序列。为了支持一些查询，有时还会临时产生一些时间序列存储。

==== metrics name&label指标名称和标签 ====
标签标签为Prometheus数据模型提供了维度。它们为特定时间序列添加上下文。例如，total_website_visits时间序列可以使用能够识别网站名称、请求IP或其他特殊标识的标签。

Prometheus可以在一个时间序列、一组时间序列或者所有相关的时间序列上进行查询。标签共有两大类：插桩标签（instrumentation label）和目标标签（target label）。插桩标签来自被监控的资源——例如，对于与HTTP相关的时间序列，标签可能会显示所使用的特定HTTP动词。这些标签在由诸如客户端或exporter抓取之前会被添加到时间序列中。目标标签更多地与架构相关——它们可能会识别时间序列所在的数据中心。目标标签由Prometheus在抓取期间和之后添加。时间序列由名称和标签标识（尽管从技术上讲，名称本身也是名为__name__的标签）。如果你在时间序列中添加或更改标签，那么Prometheus会将其视为新的时间序列。提示 你可以理解label就是键/值形式的标签，并且新的标签会创建新的时间序列。标签名称可以包含ASCII字符、数字和下划线。提示 带有__前缀的标签名称保留给Prometheus内部使用。

每条时间序列是由唯一的”指标名称”和一组”标签（key=value）”的形式组成。

指标名称：一般是给监测对像起一名字，例如http_requests_total这样，它有一些命名规则，可以包字母数字_之类的的。通常是以应用名称开头_监测对像_数值类型_单位这样。例如：push_total、userlogin_mysql_duration_seconds、app_memory_usage_bytes。

标签：就是对一条时间序列不同维度的识别了，例如一个http请求用的是POST还是GET，它的endpoint是什么，这时候就要用标签去标记了。最终形成的标识便是这样了：http_requests_total{method=”POST”,endpoint=”/api/tracks”}。

记住，针对http_requests_total这个metrics name无论是增加标签还是删除标签都会形成一条新的时间序列。

查询语句就可以跟据上面标签的组合来查询聚合结果了。

如果以传统数据库的理解来看这条语句，则可以考虑http_requests_total是表名，标签是字段，而timestamp是主键，还有一个float64字段是值了。（Prometheus里面所有值都是按float64存储）。

==== 采样数据 ====
时间序列的真实值是采样（sample）的结果，它包括两部分：·一个float64类型的数值·一个毫秒精度的时间戳
==== 符号 ====
表示结合这些元素，可以看到Prometheus如何将时间序列表示为符号（notation）
 <time series name>{<label name>=<label value>, ...}
首先是时间序列名称，后面跟着一组键/值对标签。通常所有时间序列都有一个instance标签（标识源主机或应用程序）以及一个job标签（包含抓取特定时间序列的作业名称）。

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

=== 安全模型 ===
Prometheus可以通过多种方式进行配置和部署，关于安全有以下两个假设：
*不受信任的用户将能够访问Prometheus服务器的HTTP API，从而访问数据库中的所有数据。
*只有受信任的用户才能访问Prometheus命令行、配置文件、规则文件和运行时配置。

提示 从Prometheus 2.0开始，默认情况下某些HTTP API的管理功能被禁用。因此，Prometheus及其组件不提供任何服务器端的身份验证、授权或加密。如果在一个更加安全的环境中工作，则需要自己实施安全控制——例如，通过反向代理访问Prometheus服务器或者正向代理exporter。

=== Prometheus四种数据类型 ===
==== Counter（计数器） ====

Counter 类型代表一种样本数据单调递增的指标，即只增不减，除非监控系统发生了重置。例如，可以使用 counter 类型的指标来表示服务的请求数、已完成的任务数、错误发生的次数等。counter 主要有两个方法：
 //将counter值加1.
 Inc()
 // 将指定值加到counter值上，如果指定值<0 会panic.
 Add(float64)
Counter 类型数据可以让用户方便的了解事件产生的速率的变化，在 PromQL 内置的相关操作函数可以提供相应的分析，比如以 HTTP 应用请求量来进行说明：
 //通过rate()函数获取HTTP请求量的增长率
 rate(http_requests_total[5m])
 //查询当前系统中，访问量前10的HTTP地址
 topk(10, http_requests_total)
不要将 counter 类型应用于样本数据非单调递增的指标，例如：当前运行的进程数量（应该用 Guage 类型）。

Counter用于累计值，例如记录请求次数、任务完成数、错误发生次数。一直增加，不会减少。重启进程后，会被重置。

例如：http_response_total{method=”GET”,endpoint=”/api/tracks”} 100，10秒后抓取http_response_total{method=”GET”,endpoint=”/api/tracks”} 100。

==== Gauge （仪表盘）====
Guage 类型代表一种样本数据可以任意变化的指标，即可增可减。guage 通常用于像温度或者内存使用率这种指标数据，也可以表示能随时增加或减少的“总数”，例如：当前并发请求的数量。

对于 Gauge 类型的监控指标，通过 PromQL 内置函数 delta() 可以获取样本在一段时间内的变化情况，例如，计算 CPU 温度在两小时内的差异：

 dalta(cpu_temp_celsius{host="zeus"}[2h])
还可以通过PromQL 内置函数 predict_linear() 基于简单线性回归的方式，对样本数据的变化趋势做出预测。例如，基于 2 小时的样本数据，来预测主机可用磁盘空间在 4 个小时之后的剩余情况：
 predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0

Gauge常规数值，例如 温度变化、内存使用变化。可变大，可变小。重启进程后，会被重置。

例如： memory_usage_bytes{host=”master-01″} 100 < 抓取值、memory_usage_bytes{host=”master-01″} 30、memory_usage_bytes{host=”master-01″} 50、memory_usage_bytes{host=”master-01″} 80 < 抓取值。

==== Histogram （直方图）====
在大多数情况下人们都倾向于使用某些量化指标的平均值，例如 CPU 的平均使用率、页面的平均响应时间。这种方式的问题很明显，以系统 API 调用的平均响应时间为例：如果大多数 API 请求都维持在 100ms 的响应时间范围内，而个别请求的响应时间需要 5s，那么就会导致某些 WEB 页面的响应时间落到中位数的情况，而这种现象被称为长尾问题。

为了区分是平均的慢还是长尾的慢，最简单的方式就是按照请求延迟的范围进行分组。例如，统计延迟在 0~10ms 之间的请求数有多少而 10~20ms 之间的请求数又有多少。通过这种方式可以快速分析系统慢的原因。Histogram 和 Summary 都是为了能够解决这样问题的存在，通过 Histogram 和 Summary 类型的监控指标，我们可以快速了解监控样本的分布情况。

Histogram 在一段时间范围内对数据进行采样（通常是请求持续时间或响应大小等），并将其计入可配置的存储桶（bucket）中，后续可通过指定区间筛选样本，也可以统计样本总数，最后一般将数据展示为直方图。

Histogram 类型的样本会提供三种指标（假设指标名称为 <basename>）：

样本的值分布在 bucket 中的数量，命名为 <basename>_bucket{le="<上边界>"}。解释的更通俗易懂一点，这个值表示指标值小于等于上边界的所有样本数量。
  // 在总共2次请求当中。http 请求响应时间 <=0.005 秒 的请求次数为0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.005",} 0.0
  // 在总共2次请求当中。http 请求响应时间 <=0.01 秒 的请求次数为0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.01",} 0.0
  // 在总共2次请求当中。http 请求响应时间 <=0.025 秒 的请求次数为0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.025",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.05",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.075",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.1",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.25",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.5",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.75",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="1.0",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="2.5",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="5.0",} 0.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="7.5",} 2.0
  // 在总共2次请求当中。http 请求响应时间 <=10 秒 的请求次数为 2
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="10.0",} 2.0
  io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="+Inf",} 2.0
所有样本值的大小总和，命名为 <basename>_sum。
  // 实际含义： 发生的2次 http 请求总的响应时间为 13.107670803000001 秒
  io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="200",} 13.107670803000001
样本总数，命名为 <basename>_count。值和 <basename>_bucket{le="+Inf"} 相同。
  // 实际含义： 当前一共发生了 2 次 http 请求
  io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code="200",} 2.0
注意

bucket 可以理解为是对数据指标值域的一个划分，划分的依据应该基于数据值的分布。注意后面的采样点是包含前面的采样点的，假设 xxx_bucket{...,le="0.01"} 的值为 10，而 xxx_bucket{...,le="0.05"} 的值为 30，那么意味着这 30 个采样点中，有 10 个是小于 10 ms 的，其余 20 个采样点的响应时间是介于 10 ms 和 50 ms 之间的。

可以通过 histogram_quantile() 函数来计算 Histogram 类型样本的分位数。分位数可能不太好理解，你可以理解为分割数据的点。我举个例子，假设样本的 9 分位数（quantile=0.9）的值为 x，即表示小于 x 的采样值的数量占总体采样值的 90%。Histogram 还可以用来计算应用性能指标值（Apdex score）。

Histogram（直方图）可以理解为柱状图的意思，常用于跟踪事件发生的规模，例如：请求耗时、响应大小。它特别之处是可以对记录的内容进行分组，提供count和sum全部值的功能。

例如：{小于10=5次，小于20=1次，小于30=2次}，count=7次，sum=7次的求和值。

==== Summary （摘要）====
与 Histogram 类型类似，用于表示一段时间内的数据采样结果（通常是请求持续时间或响应大小等），但它直接存储了分位数（通过客户端计算，然后展示出来），而不是通过区间来计算。

Summary 类型的样本也会提供三种指标（假设指标名称为 ）：

样本值的分位数分布情况，命名为 <basename>{quantile="<φ>"}。
  // 含义：这 12 次 http 请求中有 50% 的请求响应时间是 3.052404983s
  io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.5",} 3.052404983
  // 含义：这 12 次 http 请求中有 90% 的请求响应时间是 8.003261666s
  io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.9",} 8.003261666
所有样本值的大小总和，命名为 <basename>_sum。
  // 含义：这12次 http 请求的总响应时间为 51.029495508s
  io_namespace_http_requests_latency_seconds_summary_sum{path="/",method="GET",code="200",} 51.029495508
样本总数，命名为 <basename>_count。
  // 含义：当前一共发生了 12 次 http 请求
  io_namespace_http_requests_latency_seconds_summary_count{path="/",method="GET",code="200",} 12.0
现在可以总结一下 Histogram 与 Summary 的异同：

它们都包含了 <basename>_sum 和 <basename>_count 指标

Histogram 需要通过 <basename>_bucket 来计算分位数，而 Summary 则直接存储了分位数的值。

例如：count=7次，sum=7次的值求值。

它提供一个quantiles的功能，可以按%比划分跟踪的结果。例如：quantile取值0.95，表示取采样值里面的95%数据。

[[分类:Prometheus]]

返回: [[Prometheus]]