Promethues告警的简单介绍

本文目录一览：

• 1、Prometheus 实现邮件告警

• 2、Prometheus 四大度量指标和应用

• 3、【实践】2.Prometheus命令和配置详解

• 4、Prometheus的四大指标类型

• 5、Prometheus

• 6、prometheus问题赏析-填坑的心路历程

Prometheus 实现邮件告警

Prometheus 实现邮件告警（Prometheus+Alertmanager+QQ邮箱或者网易163邮箱，目前测试过这两种邮箱都可以发送告警邮件）

Prometheus实现邮件告警原理如下：

Prometheus官方有一个附带的中间件：alertmanager，通过设置rules规则和路由转发可以实现邮件告警，前提是你需要有一个可以发送邮件的邮件服务端（可以自建或者使用互联网公司提供的免费邮箱）

告警原理图

Prometheus完整架构图

我之前得出的错误结论如下：

推荐直接在虚拟机操作系统上直接安装Prometheus和Alertmanager，不推荐其中任何一方在容器中运行，因为测试过在容器中运行Prometheus和alertmanager，结果出现如下错误情况

第一种情况是：我的node-exporter掉线跌机了（手动关机，模拟突然掉线跌机），Prometheus却提示节点依然在线？有时候却能够正常显示节点掉线跌机，生成告警发送邮件

第二种情况是：我的node-exporter掉线跌机了（手动关机，模拟突然掉线跌机），Prometheus提示节点掉线，告警生成，但是没有发送邮件，我手动恢复node-exporter后，告警解除，邮件能正常发送邮件提示告警已经解除。。。。

第三种情况是：我的node-exporter掉线跌机了（手动关机，模拟突然掉线跌机），Prometheus提示节点掉线，告警生成，正常成功发送邮件，我手动恢复node-exporter后，告警解除，邮件没有发送出来。。。。

以上三种情况之前经常出现，当时第一步以为是自己设置的scrape_interval不合理导致的，结果调试几次，问题没有解决，第二步以为是自己的服务器时间没有做到精确同步，然后我去设置和阿里云的ntp服务器同步，结果问题依然没有解决，第三步，换个方向，把alertmanager迁移到虚拟机操作系统上安装运行，问题解决！

北京时间是GMT+8小时，有些同志的时间可能是UTC的，但是如果是在要求不太十分精确的情况下，UTC时间是刚刚好等于GMT时间

为了避免时区的混乱，prometheus所有的组件内部都强制使用Unix时间，对外展示使用GMT时间。

要改时区有两个办法

1 .修改源码，重新编译。

2. 使用 docker 运行 Prometheus，挂载本地时区文件

docker run --restart always -e TZ=Asia/Shanghai --hostname prometheus --name prometheus-server -d -p 9090:9090 -v /data/prometheus/server/data:/prometheus -v /data/prometheus/server/conf/prometheus.yml:/etc/prometheus/prometheus.yml -u root prom/prometheus:v2.5.0

正文开始

安装alertmanager

容器安装方式：

docker run -d --name alertmanager -p 9093:9093 -v /usr/local/Prometheus/alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml prom/alertmanager:latest

先在宿主机/usr/local/Prometheus下创建一个文件夹alertmanager，然后在文件夹里创建alertmanager.yml配置文件，待会才能映射到alertmanager容器里的/etc/alertmanager目录下

global：全局配置

   resolve_timeout: 问题解决的超时时间

   smtp_from: 发送告警邮件的邮箱账号

   smtp_smarthost: 邮箱 SMTP 服务地址,这里是以QQ邮箱为例，也可以用网易163邮箱，这个和我之前设置zabbix邮件告警时的配置一样

   smtp_auth_username: 如果没有设置邮箱别名，那就是账户名

   smtp_auth_password:  邮箱的授权码，不是 账户密码，你可以在QQ邮箱或者网易163邮箱网页端设置，开启 POP3/SMTP 服务时会提示，和配置zabbix邮件告警的时候几乎一样

   smtp_require_tls: 是否使用 tls，根据环境不同，来选择开启和关闭。如果提示报错 email.loginAuth failed: 530 Must issue a STARTTLS command first，那么就需要设置为 true。着重说明一下，如果开启了 tls，提示报错 starttls failed: x509: certificate signed by unknown authority，需要在 email_configs 下配置 insecure_skip_verify: true 来跳过 tls 验证。

templates： 告警模板目录，可以不编写模板，有默认模板

    Subject: '{{ template "email.default.subject" . }}'

    html: '{{ template "email.default.html" . }}'

route：报警的分发设置

    group_by：分组

    group_wait: 分组等待时间

    group_interval: 5m 每组时间间隔

    repeat_interval: 10m 重复间隔

    receiver: 接收方式，请注意！这里的名字要对应下面receivers中的任何一个名字，不然会报错，这里其实就是选择方式，有邮箱，企业微信，wehook，victorops等等

receivers：接受方式汇总，即告警方式汇总

例子：

receivers:

- name:'default-receiver' 

email_configs:

- to:'whiiip@163.com'    

  html: '{{ template "alert.html" . }}'    

  headers: { Subject: "[WARN] 报警邮件test"}

inhibit_rules:   抑制规则

当存在与另一组匹配的警报（源）时，抑制规则将禁用与一组匹配的警报（目标）。

包括源匹配和目标匹配

alertmanager官方是这样说的

Inhibition

Inhibition is a concept of suppressing notifications for certain alerts if certain other alerts are already firing.

Example:  An alert is firing that informs that an entire cluster is not reachable. Alertmanager can be configured to mute all other alerts concerning this cluster if that particular alert is firing. This prevents notifications for hundreds or thousands of firing alerts that are unrelated to the actual issue.

Inhibitions are configured through the Alertmanager's configuration file.

当存在与另一组匹配器匹配的警报（源）时，禁止规则会使与一组匹配器匹配的警报（目标）静音。目标警报和源警报的equal列表中的标签名称都必须具有相同的标签值。

在语义上，缺少标签和带有空值的标签是同一件事。因此，如果equal源警报和目标警报都缺少列出的所有标签名称，则将应用禁止规则。

为了防止警报禁止自身，与规则的目标和源端 都 匹配的警报不能被警报（包括其本身）为真来禁止。但是，我们建议选择目标匹配器和源匹配器，以使警报永远不会同时匹配双方。这很容易进行推理，并且不会触发此特殊情况。

接着是规则rules

不解释了，自己研究官方文档

alertmanager的非容器安装方式是

 wget

tar xf alertmanager-0.20.0.linux-amd64.tar.gz

mv alertmanager-0.20.0.linux-amd64 /usr/local/alertmanager

vim /usr/lib/systemd/system/alertmanager.service

[Unit]

Description=alertmanager

Documentation=

After=network.target

[Service]

Type=simple

User=root

ExecStart=/usr/local/alertmanager/alertmanager --config.file=/usr/local/alertmanager/alertmanager.yml

Restart=on-failure

[Install]

WantedBy=multi-user.target

Alertmanager 安装目录下默认有 alertmanager.yml 配置文件，可以创建新的配置文件，在启动时指定即可。

其余方式和上面一样

接着是Prometheus，我之前的博客里有写了容器安装和非容器安装的方法，自己去翻阅

然后是在prometheus.yml里修改相关配置

首先去掉alertmanager的注释，改成IP加你设置的端口号，默认是9093

接着在rule_files: 下面写下规则文件的绝对路径，可以是具体文件名，也可以是*，也可以分几级文件，*默认是全部匹配

接着是被监控项的设置，这里设置完成可以在Prometheus网页里的targets里看得到

请注意，这里设置的参数名字要和rule规则中设置的参数名字一模一样，否则你的prometheus服务会无法启动，然后报错

如果不在特定的job下设置scrape_interval（优先级高于全局）,则默认采用gobal下的scrape_interval

最后模拟节点掉线，手动关闭node-exporter或者Cadvisor

docker stop node-exporter 或者容器ID

docker stop cadvisor 或者容器ID

或者把up{{job='prometheus'}} == 1 设置成1，反向设置，不用关掉服务，就可以看看告警成不成功

说明一下 Prometheus Alert 告警状态有三种状态：Inactive、Pending、Firing。

Inactive：非活动状态，表示正在监控，但是还未有任何警报触发。

Pending：表示这个警报必须被触发。由于警报可以被分组、压抑/抑制或静默/静音，所以等待验证，一旦所有的验证都通过，则将转到 Firing 状态。

Firing：将警报发送到 AlertManager，它将按照配置将警报的发送给所有接收者。一旦警报解除，则将状态转到 Inactive，如此循环。

没有配置告警模板时的默认告警格式是这样的

节点恢复后邮件告知是这样的

写了模板后是这样的

还要重新映射模板文件夹路径到alertmanager容器里的相对路径，然后重启alertmanager，当然，如果目录下没有模板文件，则不显示

告警模板

在alertmanager.yml中修改相关设置

重启alertmanager

docker restart alertmanager

最终效果不是很好

Prometheus 四大度量指标和应用

Gauge 类型代表一个可以任意变化的指标数据，其可增可减。在应用场景中，像是 Go 应用程序运行时的 Goroutine 的数量 就可以用该类型来表示，在系统中统计 CPU、Memory 等等时很常见，而在业务场景中， 业务队列的数量 也可以用 Gauge 来统计，实时观察队列数量，及时发现堆积情况,因为其是浮动的数值，并非固定的，侧重于反馈当前的情况

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

Histogram 类型在应用场景中非常的常用，因为其代表的就是分组区间的统计，而在分布式场景盛行的现在， 链路追踪 系统是必不可少的，那么针对不同的链路的分析统计就非常的有必要，例如像是对 RPC、SQL、HTTP、Redis 的 P90、P95、P99 进行计算统计，并且更进一步的做告警，就能够及时的发现应用链路缓慢，进而发现和减少第三方系统的影响。

Summary 类型将会在一段时间范围内对数据进行采样，但是与 Histogram 类型不同的是 Summary 类型将会存储分位数（在客户端进行计算），而不像 Histogram 类型，根据所设置的区间情况统计存储。提供三种摘要指标: 样本值的分位数分布情况,所有样本值的大小总和,样本总数

简单是展示配合 grafana 的 http_durations_histogram_seconds_bucket 的效果

【实践】2.Prometheus命令和配置详解

Prometheus配置方式有两种：

（1）命令行，用来配置不可变命令参数，主要是Prometheus运行参数，比如数据存储位置

（2）配置文件，用来配置Prometheus应用参数，比如数据采集，报警对接

不重启进程配置生效方式也有两种：

（1）对进程发送信号SIGHUP

（2）HTTP POST请求，需要开启--web.enable-lifecycle选项curl -X POST

配置文件格式是yaml格式，说明：

.yml或者.yaml 都是 yaml格式的文件，

yaml格式的好处: 和json交互比较容易

python/go/java/php 有yaml格式库，方便语言之间解析,并且这种格式存储的信息量很大。

命令行可用配置可通过prometheus -h来查看。

配置文件使用yml格式，配置文件中一级配置项如下，说明参考#备注内容。

配置文件中通用字段值格式

boolean: 布尔类型值为true和false

scheme: 协议方式包含http和https

原始配置文件内容：

全局默认的数据拉取间隔

全局默认的单次数据拉取超时，当报context deadline exceeded错误时需要在特定的job下配置该字段。

全局默认的规则(主要是报警规则)拉取间隔

该服务端在与其他系统对接所携带的标签

该字段配置与Alertmanager进行对接的配置

样例：

上面的配置中的 alert_relabel_configs 是指警报重新标记在发送到Alertmanager之前应用于警报。 它具有与目标重新标记相同的配置格式和操作，外部标签标记后应用警报重新标记，主要是针对集群配置。

这个设置的用途是确保具有不同外部label的HA对Prometheus服务端发送相同的警报信息。

Alertmanager 可以通过 static_configs 参数静态配置，也可以使用其中一种支持的服务发现机制动态发现，我们上面的配置是静态的单实例。

此外， relabel_configs 允许从发现的实体中选择 Alertmanager，并对使用的API路径提供高级修改，该路径通过 __alerts_path__ 标签公开。

完成以上配置后，重启Prometheus服务，用以加载生效，也可以使用热加载功能，使其配置生效。然后通过浏览器，访问 就可以看 inactive pending firing 三个状态，没有警报信息是因为我们还没有配置警报规则 rules 。

这里定义和prometheus集成的alertmanager插件，用于监控报警。后续会单独进行alertmanger插件的配置、配置说明、报警媒介以及route路由规则记录。

此项配置和 scrape_configs 字段中 relabel_configs 配置一样，用于对需要报警的数据进行过滤后发向 Alertmanager

说明

relabel-configs的配置允许你选择你想抓取的目标和这些目标的标签是什么。所以说如果你想要抓取这种类型的服务器而不是那种，可以使用relabel_configs

相比之下，metric_relabel_configs是发生在抓取之后，但在数据被插入存储系统之前使用。因此如果有些你想过滤的指标，或者来自抓取本身的指标（比如来自/metrics页面）你就可以使用metric_relabel_configs来处理。

该项目主要用来配置不同的 alertmanagers 服务，以及Prometheus服务和他们的链接参数。 alertmanagers 服务可以静态配置也可以使用服务发现配置。Prometheus以pushing 的方式向alertmanager传递数据。

alertmanager 服务配置和target配置一样，可用字段如下

这个主要是用来设置告警规则，基于设定什么指标进行报警（类似触发器trigger）。这里设定好规则以后，prometheus会根据全局global设定的evaluation_interval参数进行扫描加载，规则改动后会自动加载。其报警媒介和route路由由alertmanager插件实现。

样例：

"first_rules.yml"样例：

Prometheus 支持两种类型的 Rules ，可以对其进行配置，然后定期进行运算：recording rules 记录规则 与 alerting rules 警报规则，规则文件的计算频率与警报规则计算频率一致，都是通过全局配置中的 evaluation_interval 定义。

不论是recording rules还是alerting rules都要在组里面。

要在Prometheus中使用Rules规则，就必须创建一个包含必要规则语句的文件，并让Prometheus通过Prometheus配置中的rule_files字段加载该文件，前面我们已经讲过了。 其实语法都一样，除了 recording rules 中的收集的指标名称 record: string 字段配置方式略有不同，其他都是一样的。

配置范例：

recording rules 是提前设置好一个比较花费大量时间运算或经常运算的表达式，其结果保存成一组新的时间序列数据。当需要查询的时候直接会返回已经计算好的结果，这样会比直接查询快，同时也减轻了PromQl的计算压力，同时对可视化查询的时候也很有用，可视化展示每次只需要刷新重复查询相同的表达式即可。

在配置的时候，除却 record: string 需要注意，其他的基本上是一样的，一个 groups 下可以包含多条规则 rules ，Recording 和 Rules 保存在 group 内，Group 中的规则以规则的配置时间间隔顺序运算，也就是全局中的 evaluation_interval 设置。

配置范例：

上面的规则其实就是根据 record 规则中的定义，Prometheus 会在后台完成 expr 中定义的 PromQL 表达式周期性运算，以 job 为维度使用 sum 聚合运算符 计算 函数rate 对http_requests_total 指标区间 10m 内的增长率，并且将计算结果保存到新的时间序列 job:http_requests_total:rate10m 中， 同时还可以通过 labels 为样本数据添加额外的自定义标签，但是要注意的是这个 lables 一定存在当前表达式 Metrics 中。

模板是在警报中使用时间序列标签和值展示的一种方法，可以用于警报规则中的注释（annotation）与标签（lable）。模板其实使用的go语言的标准模板语法，并公开一些包含时间序列标签和值的变量。这样查询的时候，更具有可读性，也可以执行其他PromQL查询 来向警报添加额外内容，ALertmanager Web UI中会根据标签值显示器警报信息。

{{ $lable.lablename}} 可以获取当前警报实例中的指定标签值

{{ $value }} 变量可以获取当前PromQL表达式的计算样本值。

调整好rules以后，我们可以使用 curl -XPOST 或者 对Prometheus服务重启，让警报规则生效。

这个时候，我们可以把阈值调整为 50 来进行故障模拟操作，这时在去访问UI的时候，当持续1分钟满足警报条件，实际警报状态已转换为 Firing，可以在 Annotations中看到模板信息 summary 与 description 已经成功显示。

规则检查

拉取数据配置，在配置字段内可以配置拉取数据的对象(Targets)，job以及实例

定义job名称，是一个拉取单元。每个job_name都会自动引入默认配置如

这些也可以在单独的job中自定义

服务端拉取过来的数据也会存在标签，配置文件中也会有标签，这样就可能发生冲突。

true就是以抓取数据中的标签为准

false就会重新命名抓取数据中的标签为“exported”形式，然后添加配置文件中的标签

切换抓取数据所用的协议

定义可选的url参数

每次抓取数据请求的认证信息

password和password_file互斥只可以选择其一

bearer_token和bearer_token_file互斥只可以选择其一

抓取ssl请求时证书配置

通过代理去主去数据

Prometheus支持多种服务现工具，详细配置这里不再展开

更多参考官网： n/configuration/

服务发现来获取抓取目标为动态配置，这个配置项目为静态配置，静态配置为典型的targets配置，在改配置字段可以直接添加标签

采集器所采集的数据都会带有label，当使用服务发现时，比如consul所携带的label如下:

这些lable是数据筛选与聚合计算的基础。

抓取数据很繁杂，尤其是通过服务发现添加的target。所以过滤就显得尤为重要，我们知道抓取数据就是抓取target的一些列metrics，Prometheus过滤是通过对标签操作操现的，在字段relabel_configs和metric_relabel_configs里面配置，两者的配置都需要relabel_config字段。该字段需要配置项如下

target配置示例

target中metric示例

target中metric示例

使用示例

由以上可知当使用服务发现consul会带入标签__meta_consul_dc，现在为了表示方便需要将该标签变为dc

需要做如下配置，这里面action使用的replacement

过滤采集target

为了防止Prometheus服务过载，使用该字段限制经过relabel之后的数据采集数量，超过该数字拉取的数据就会被忽略

Prometheus可以进行远程读/写数据。字段remote_read和remote_write

（1）Prometheus 配置详解

（2）Prometheus配置文件prometheus.yml 四个模块详解

（3）官方文档说明

（4）Prometheus监控神器-Rules篇

（5）Prometheus监控神器-Alertmanager篇(1)

（6）Prometheus监控神器-Alertmanager篇(2)

Prometheus的四大指标类型

Prometheus有4大指标类型（Metrics Type），分别是Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）和Summary（摘要）。

这是在Prometheus客户端（目前主要有Go、Java、Python、Ruby等语言版本）中提供的4种核心指标类型，但是Prometheus的服务端并不区分指标类型，而是简单地把这些指标统一视为无类型的时间序列。

注意：

font color=red上面这句话应该这么理解，四个指标类型，实际上就是客户端采集数据的四个维度，采集这四个维度的指标数据，但是最终汇总到服务端那里，则是对这四个维度无感的，只是简单的作为时间序列存储起来。/font

 计数器表示一种单调递增的指标，除非发生重置的情况下下只增不减，其样本值应该是不断增大的。例如，可以使用Counter类型的指标来表示服务的请求数、已完成的任务数、错误发生的次数等。

 但是，计数器计算的总数对用户来说大多没有什么用，大家千万不要将计数器类型应用于样本数据非单调递增的指标上，比如当前运行的进程数量、当前登录的用户数量等应该使用仪表盘类型。

为了能够更直观地表示样本数据的变化情况，往往需要计算样本的增长速率，这时候通常使用PromQL的rate、topk、increase和irate等函数，如下所示：

如上所示，速率的输出rate（v range-vector）也应该用仪表盘来承接结果。

在上面的案例中，如果有一个标签是Device，那么在统计每台机器每秒接受的HTTP请求数时，可以用如下的例子进行操作。

补充

 这背后与rate()的实现方式有关，rate()在设计上假定对应的指标是一个计数器，也就是只有font color=redincr（增加）和reset（归零）/font两种行为。而执行了sum()或其他聚合操作之后，得到的就不再是一个计数器了。举个例子，比如sum()的计算对象中有一个归零了，那整体的和会下降，而不是归零，这会影响rate()中判断reset（归零）的逻辑，从而导致错误的结果。

 increase（v range-vector）函数传递的参数是一个区间向量，increase函数获取区间向量中的第一个和最后一个样本并返回其增长量。下面的例子可以查询Counter类型指标的增长速率，可以获取http_requests_total在最近5分钟内的平均样本，其中300代表300秒。

 rate和increase函数计算的增长速率容易陷入font color=red长尾效应中/font。比如在 某一个由于访问量或者其他问题导致CPU占用100%的情况中，通过计算在时间窗口内的平均增长速率是无法反映出该问题的 。

 为什么监控和性能测试中，我们更关注p95/p99位？就是因为长尾效应。由于个别请求的响应时间需要1秒或者更久，font color=red传统的响应时间的平均值就体现不出响应时间中的尖刺了/font，去尖刺也是数据采集中一个很重要的工序，这就是所谓的长尾效应。p95/p99就是长尾效应的分割线，如表示99%的请求在XXX范围内，或者是1%的请求在XXX范围之外。99%是一个范围，意思是99%的请求在某一延迟内，剩下的1%就在延迟之外了。只是正推与逆推而已，是一种概念的两种不同描述。

 irate（v range-vector）是PromQL针对长尾效应专门提供的灵敏度更高的函数。irate同样用于计算区间向量的增长速率，但是其反映出的是瞬时增长速率。irate函数是通过区间向量中最后两个样本数据来计算区间向量的增长速率的。这种方式可以避免在时间窗口范围内的“长尾问题”，并且体现出更好的灵敏度。通过irate函数绘制的图标能够更好地反映样本数据的瞬时变化状态。irate的调用命令如下所示。

 irate函数相比于rate函数提供了更高的灵敏度，不过分析长期趋势时或者在告警规则中，irate的这种灵敏度反而容易造成干扰。因此，在长期趋势分析或者告警中更推荐使用rate函数。

 仪表盘类型代表一种font color=red样本数据可以任意变化的指标，即可增可减/font。它可以理解为状态的快照，Gauge通常用于表示温度或者内存使用率这种指标数据，也可以表示能随时增加或减少的“总数”，例如当前并发请求的数量node_memory_MemFree（主机当前空闲的内容大小）、node_memory_MemAvailable（可用内存大小）等。在使用Gauge时，用户往往希望使用它们font color=red求和、取平均值、最小值、最大值/font等。

 以Prometheus经典的Node Exporter的指标node_filesystem_size_bytes为例，它可以报告从node_filesystem_size_bytes采集来的文件系统大小，包含device、fstype和mountpoint等标签。如果想要对每一台机器上的总文件系统大小求和（sum），可以使用如下PromQL语句。

 without可以让sum指令根据相同的标签进行求和，但是忽略without涵盖的标签。如果在实际工作中需要忽略更多标签，可以根据实际情况在without里传递更多指标。

补充 ：

node_filesystem_size_bytes指标查询

device, fstype, mountpoint都是他的标签。

sum without(device, fstype, mountpoint)(node_filesystem_size_bytes)查询

 如果要根据Node Exporter的指标node_filesystem_size_bytes计算每台机器上最大的文件安装系统大小，只需要将上述案例中的sum函数改为max函数，如下所示。

 除了求和、求最大值等，利用Gauge的函数求最小值和平均值等原理是类似的。除了基本的操作外，Gauge经常结合PromQL的predict_linear和delta函数使用。

 predict_linear（v range-vector，t scalar）函数可以预测时间序列v在t秒后的值，就是使用线性回归的方式，预测样本数据的Gauge变化趋势。例如，基于2小时的样本数据，预测未来24小时内磁盘是否会满，如下所示：

PromQL还有一个内置函数delta()，它可以获取样本在一段时间内的变化情况，也通常作用于Gauge。例如，计算磁盘空间在2小时内的差异，如下所示。

Histogram是一个对数据分布情况的图形表示，由一系列高度不等的长条图（bar）或线段表示，用于展示单个测度得知的分布。

[图片上传失败...(image-3e55f2-1622153155462)]

上边界、样本值总和、样本总数

例子

这三个查询一起看

所有样本值的总和，命名为basename_sum。

prometheus_http_request_duration_seconds_sum{handler="/targets",instance="192.168.16.134:9090",job="prometheus"}0.405075955 表示12 次http请求的总响应时间是0.405075955

命名为basename_count，其值和basename_bucket{le="+Inf"}相同（所有）。

prometheus_http_request_duration_seconds_count{handler="/targets",instance="192.168.16.134:9090",job="prometheus"}12 表示总共发生了12次请求

 sum函数和count函数相除，可以得到一些平均值，比如Prometheus一天内的平均压缩时间，可由查询结果除以instance标签数量得到，如下所示。

 除了Prometheus内置的压缩时间，prometheus_local_storage_series_chunks_persisted表示Prometheus中每个时序需要存储的chunk数量，也可以用于计算待持久化的数据的分位数。

 Histogram可以用于观察样本数据的分布情况。Histogram的分位数计算需要通过histogram_quantile（φfloat，b instant-vector）函数进行计算，但是histogram_quantile计算所得并非精确值。其中，φ（0φ1）表示需要计算的分位数（这个值主要是通过prometheus_http_request_duration_seconds_bucket和prometheus_http_request_duration_seconds_sum两个指标得到的，是一个近似值）。

例子如下。

 与Histogram类型类似，摘要用于表示一段时间内的数据采样的结果（通常是请求持续时间或响应大小等），但它直接存储了分位数（通过客户端计算，然后展示出来），而非通过区间来计算（Histogram的分位数需要通过histogram_quantile（φfloat，b instant-vector）函数计算得到）。因此，对于分位数的计算，Summary在通过PromQL进行查询时有更好的性能表现，而Histogram则会消耗更多的资源。反之，对于客户端而言，Histogram消耗的资源更少。在选择这两种方式时，用户应该根据自己的实际场景选择。

Histogram是在服务端计算的，Summary是在客户端计算的。

 安装并启动Prometheus后，在访问 时可以看到Prometheus自带的一些Summary信息，这些信息和Histogram一样在注释中（#HELP和#TYPE）也会显示，如下所示。

 在上述例子中，可以看到基于Go语言编写的Prometheus的gc总次数是1907，耗时0.193642882s，其中中位数（quantile=0.5）计算的耗时为4.8366e-05s，代表1907次中50%的次数是小于4.8366e-05s的。

Summary类型的样本也会提供3种指标，假设指标名称为basename。

Summary和Histogram的异同

Summary的强大之处就是可以利用除法去计算时间的平均值。如果要从Histogram和Summary中计算最近5分钟内的平均请求持续时间http_request_duration_seconds，可以用如下表达式进行。

count本质上是一个计数器，sum通常情况下也会像计数器那样工作。但是font color=redSummary和Histogram可能观察到负值，比如温度（-20℃），这种情况下会导致观察的总量下降，无法再使用rate函数/font。

比如下面的例子就可以计算过去5分钟内每次响应中返回的平均字节数。

关于这个例子，我们需要注意几点。

·因为http_response_size_bytes_count和http_response_size_bytes_sum是计数器类型，所以必须在计算前先使用rate等函数。

·因为Prometheus的API会有很多handler，所以可以使用without过滤掉handler的返回值。

·PromQL要先执行rate()再执行sum()，不能先执行sum()再执行rate()。

·在统计学上，尤其是计算平均值时，要先进行sum等求和运算再做除法。对一个平均值再求平均是不正确的，如下所示。

count的例子

案例一：计算所有的实例CPU核心数。

count by (instance) ( count by (instance,cpu) (node_cpu_seconds_total{mode=

"system"}) )

案例二：计算单个实例192.168.1.1的CPU核心数。

count by (instance) ( count by (instance,cpu) (node_cpu_seconds_total{mode="system",

instance="192.168.1.1"})

Prometheus

Prometheus是一个开源系统监控和报警工具包，具有活跃的生态系统。是一个多维数据模型，其中的时间序列数据由指标名称和键/值对识别。它不依赖分布式存储，单个服务器节点是自治的。通过一个中间网关支持推送时间序列，可以通过服务发现或静态配置来发现目标，支持多种模式的图表和仪表盘制作。

Prometheus具体架构图如下：

Prometheus 直接或通过中介推送网关从检测的作业中抓取指标，用于短期作业。 它将所有抓取的样本存储在本地，并对这些数据运行规则，以从现有数据聚合和记录新的时间序列或生成警报。 Grafana 或其他 API 使用者可用于可视化收集的数据。

--config.file="prometheus.yml" Prometheus配置文件路径。

--web.listen-address="0.0.0.0:9090" 用于监听UI、API和遥测的地址。

--web.config.file="" [EXPERIMENTAL] 可以启用TLS或认证的配置文件的路径。

--web.read-timeout=5m 超时读取请求和关闭空闲连接之前的最大持续时间。

--web.max-connections=512 最大同时连接数。

--web.external-url=URL 外部可访问Prometheus所在的URL（例如，如果Prometheus通过反向代理提供服务）。用于生成返回到Prometheus本身的相对和绝对链接。如果URL有路径部分，它将用于为Prometheus服务的所有HTTP端点添加前缀。如果省略，将自动派生相关的URL组件。

--web.route-prefix=path Web端点的内部路线的前缀。默认为-web.external-url的路径。

--web.user-assets=path 静态资源目录的路径，位于 /user。

--web.enable-lifecycle 通过HTTP请求启用关闭和重新加载。

--web.enable-admin-api 启用管理控制行动的API端点。

--web.console.templates="consoles" 控制台模板目录的路径，位于/consoles。

--web.console.libraries="console_libraries" 控制台库目录的路径。

--storage.tsdb.path="data/" 指标存储的基本路径。仅用于server模式。

--storage.tsdb.retention.time = 样本在储存中保留多长时间。设置此标志后，它会覆盖“storage.tsdb.retention”。如果此标志、“storage.tsdb.retention”或“storage.tsdb.retention.size”均未设置，则保留时间默认为15d。支持的单位：y、w、d、h、m、s、ms。仅用于server模式。

--storage.tsdb.retention.size = 块存储的最大字节数。需要一个单位，支持的单位：B、KB、MB、GB、TB、PB、EB。例如：“512MB”。仅用于server模式。

--storage.tsdb.no-lockfile 不在数据目录中创建锁文件。仅用于server模式。

--storage.tsdb.allow-overlapping-blocks 允许重叠块，从而启用垂直压缩和垂直查询合并。仅用于服务器模式。

--storage.agent.path="data-agent/" 指标存储的基本路径。仅用于agent模式。

--storage.agent.wal-compression 压缩代理WAL。仅用于agent模式。

--storage.agent.retention.min-time= 当WAL被截断时，样本在被强行删除之前的最小年龄，仅用于agent模式。

--storage.agent.retention.max-time= 当WAL被截断时，样本在被强行删除之前的最大年龄，仅用于agent模式。

--storage.agent.no-lockfile 不在数据目录中创建锁文件。仅用于agent模式。

--storage.remote.flush-deadline=duration 在关闭或重新加载配置时等待刷新样本的时间。

--storage.remote.read-sample-limit=5e7 在单个查询中通过远程读取接口返回的最大样本总数。 0 表示没有限制。对于流式响应类型，将忽略此限制。仅用于server模式。

--storage.remote.read-concurrent-limit=10 并发远程读取调用的最大数量。 0 表示没有限制。仅用于server模式。

--rules.alert.for-outage-tolerance=1h 为恢复“for”警报状态而容忍Prometheus中断的最长时间。仅用于server模式。

--rules.alert.for-grace-period=10m 警报和恢复“for”状态之间的最短持续时间。这仅适用于配置的“for”时间大于宽限期的警报。仅用于server模式。

--rules.alert.resend-delay=1m 在向 Alertmanager 重新发送警报之前等待的最短时间。仅用于server模式。

--alertmanager.notification-queue-capacity=10000 等待Alertmanager通知的队列容量。仅用于server模式。

--query.lookback-delta=5m 在表达式评估和联合期间，检索指标的最长回溯持续时间。仅用于server模式。

--query.timeout=2m 查询在中止之前可能需要的最长时间。仅用于server模式。

--query.max-concurrency=20 并发执行的最大查询数。仅用于server模式。

--query.max-samples=50000000 单个查询可以加载到内存中的最大样本数。请注意，如果查询尝试将比这更多的样本加载到内存中，查询将失败，因此这也限制了查询可以返回的样本数量。仅用于server模式。

--enable-feature= 逗号分隔的要启用的功能名称。有效选项：agent、exemplar-storage、expand-external-labels、memory-snapshot-on-shutdown、promql-at-modifier、promql-negative-offset、remote-write-receiver。extra-scrape-metrics、new-service-discovery-manager。

--log.level=info 只记录给定严重程度或以上的信息。其中之一：[debug, info, warn, error]。

--log.format=logfmt 日志信息的输出格式。其中之一：[logfmt, json]。

通用占位符定义如下：

全局配置区域：

scrape_config部分指定了一组描述如何抓取它们的目标和参数，目标可以通过static_configs参数静态配置或使用支持的服务发现机制之一动态发现。

Prometheus自身支持basic验证和TLS（将来可能会改变），也可以通过nginx开启basic验证。

Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。

一般来说可以将Exporter分为2类：

Prometheus UI提供了快速验证PromQL以及临时可视化支持的能力，而在大多数场景下引入监控系统通常还需要构建可以长期使用的监控数据可视化面板（Dashboard）。这时用户可以考虑使用第三方的可视化工具如Grafana，Grafana是一个开源的可视化平台，并且提供了对Prometheus的完整支持。

在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。

Alertmanager 处理客户端应用程序（例如 Prometheus 服务器）发送的警报。 它负责对它们进行重复数据删除、分组和路由到正确的接收器集成，例如Email、PagerDuty 或 OpsGenie。 它还负责警报的静音和抑制。

报警全家桶

prometheus问题赏析-填坑的心路历程

prometheus强制使用UTC世界统一时间，比实际北京时间早8个小时，可以在grafana修改时间为浏览器当前时间。

生产环境在用prometheus修改配置后如何在不影响正常使用的前提下更新配置，需要启动带如下参数：

热加载语法：

登录grafana服务器，执行如下语句：

prometheus两个及以上指标参与运算时，两个指标具有不同的标签值，无法匹配，导致两个正常的指标组合运算后返回no data。

原因是： 当 prometheus 对表达式求值时，该操作隐式应用于共享相同标签集的指标。尽管指定了指标名称和大多数标签，但 Prometheus 一直在寻找具有相同标签集的指标。

举例： 一个指标具有标签 metric=“Used”，另一个指标具有标签 metric=“Total”.可能是其中一个指标具有一些额外的标签，即会导致运算结果无返回值。

解决方案： 使用ignore(或on)来减少考虑的标签集。

真实解决案例：

prometheus运算要求两个指标必须拥有相同的标签集，这两个指标的标签集存在差异。有两种可以实现计算的方法：

1、使用ignoring(node)，忽略差异的标签，如：

2、比较取巧的方法，通过max，min等计算符将结果转换为数值进行计算，而非prometheus数据类型。