工作流程总结

1.Prometheus服务器周期性地或在设定的时间段内，通过以下方式获取内容：

• 从已经配置好的job或者exporter中拉取metric（指标）
• 接收从Pushgateway推送过来的metric
• 从其他的Prometheus服务器中拉取metric

2.Prometheus服务器获取到数据后存储在本地（也可以选择远端存储），通过一定规则对数据进行清理和整理，并且把结果存储到新的时间序列中。

3.Prometheus服务器定时查询已经定义好的规则，若发现满足定义的触发条件，便将alert信息推送至已配置好的Alertmanager。

4.Alertmanager收到alert信息后，根据配置文件对接收到的alert信息进行处理（聚合、去重、降噪），然后将它们转换为网页、电子邮件和其他通知方式发出告警。

5.最后通过Prometheus Web UI、Grafana可视化收集查询数据

摘录来自 Prometheus监控技术与实践

prometheus工作原理

服务发现：Prometheus周期性得以pull的形式对target进行指标采集，而监控目标集合是通过配置文件中所定义的服务发现机制来动态生成的。
relabel：当服务发现得到所有target后，Prometheus会根据job中的relabel_configs配置对target进行relabel操作，得到target最终的label集合。
采集：进行完上述操作后，Prometheus为这些target创建采集循环，按配置文件里配置的采集间隔进行周期性拉取，采集到的数据根据Job中的metrics_relabel_configs进行relabel，然后再加入上边得到的target最终label集合，综合后得到最终的数据。
存储： Prometheus不会将采集到的数据直接落盘，而是会将近2小时的series缓存在内存中，2小时后，Prometheus会进行一次数据压缩，将内存中的数据落盘。
服务发现 ==> targets ==> relabel ==> 抓取 ==> metrics_relabel ==> 缓存 ==> 2小时落盘。

优势与不足

1.Prometheus的基本原理是通过HTTP协议周期性获取被监控组件的状态信息，任意组件只要提供HTTP接口就可以接入监控系统内，使得prometheus的适应性很强
2.prometheus并不适合要求监控数据100%准确的场景

摘录来自 Prometheus监控技术与实践

二进制安装部署

tar -zxvf prometheus-2.4.0.linux-amd64.tar.gz -C /data
cd /data
chown -R prometheus:prometheus prometheus-2.4.0.linux-amd64
ln -sv prometheus-2.4.0.linux-amd64 prometheus
cd /data/prometheus

启动

./prometheus

热加载配置

指定配置文件、启动热加载，后台启动

nohup ./prometheus --config.file=“/path/to/prometheus.yml" --web.enable-lifecycle &

重启

curl -XPOST http://localhost:9090/-/reload

systemctl管理prometheus

vim /usr/lib/systemd/system/prometheus.service
[Unit]
Description=Prometheus server
After=network.target

[Service]
Type=simple
User=prometheus
Group=prometheus
ExecStart=/data/prometheus/prometheus
--config.file="/data/prometheus/prometheus.yml"
--storage.tsdb.path="/data/prometheus/data"
--storage.tsdb.retention=15d
--web.console.templates="/data/prometheus/consoles"
--web.console.libraries="/data/prometheus/console_libraries"
--web.max-connections=512
--web.external-url"http:// 192.168.24.17:9090"
--web.listen-address "0.0.0.0:9090"
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemctl daemon-reload
systemctl start prometheus

system文件内容介绍

［Unit］，提供服务描述信息、启动顺序与依赖关系。
［Service］，服务的关键部分，设置服务运行时使用的一些具体参数。
［Install］，定义如何启动，以及是否开机启动。

常用信息说明

［Unit］区块有两个常用选项：
·Description，服务信息描述。
·After，服务类别描述，定义unit的启动次序。

［Service］区块常用选项：
·Type，设置进程启动类型，其类型有：
·simple：默认值，执行ExecStart指定的命令，启动为主进程。
·forking：进程将在启动过程中使用fork()系统调用，创建后父进程立即退出，而子进程将作为该服务的主进程继续运行。
·oneshot：与simple类似，不同之处在于该进程必须在systemd启动后继单元之前退出。
·dbus：类似于simple，但会等待D-Bus信号后启动。
·notify：当前服务启动完毕，通知systemd再继续往下执行。
·idle：其他任务执行完毕，当前服务才会运行。
·User、Group：设定服务运行的用户和用户组。
·EnvironmentFile：环境配置文件。
·ExecStart：设置启动服务要运行的命令或脚本。
·ExecStartPre：在ExecStart之前执行的命令，语法规则与ExecStart=完全相同。
·ExecStartPost：在ExecStart之后执行的命令，语法规则与ExecStart=完全相同。
·ExecReload：可选指令，设置服务被要求重新载入配置时所执行的命令行。
·ExecStop：可选指令，设置停止服务要运行的命令或脚本。
·Restart：服务进程正常退出、异常退出、被杀死、超时时，是否重新启动该服务，可以设置如下值：
·no（默认值）：退出后不会重启。
·on-success：只有正常退出时（退出状态码为0），才会[…]”
·on-abnormal：只有被信号终止和超时，才会重启。
·on-abort：只有在收到没有捕捉到的信号而终止时，才会重启。
·on-watchdog：只有超时退出时，才会重启。
·always：不管是什么退出原因，总是重启。

［Install］区块常用选项：
·Alias：可用于启动的别名。
·WantedBy：表示该服务所在的Target，即所在服务组。

摘录来自 Prometheus监控技术与实践

相关概念

指标（metric）
1.具体要监控的东西，由指标名称和标签构成，例如CPU速率、分区使用率
2.[a-zA-Z_:][a-zA-Z0-9_:]*是有效指标的正则表达式
3.指标名称可以由字母、数字、下划线和冒号组成，但应该以字母开头一个指标由以下几个字段组成：
·指标名称。
·任意数量的标签，当然也可以是零个，表示为键值（key-value）数组。
·当前指标值。
·可选的指标标准时间戳。

标签（label）
1.标签名称可以包含字母、数字和下划线，需要以字母a-z或A-Z开头，然后跟字母、数字和下划线。
2.标签的有效匹配正则表达式为[a-zA-Z_][a-zA-Z0-9_]*。
3.以__（双下划线）开头的标签名称，只能在系统内部使用”
4.新的标签会创建新的时间序列

样本（sample）
1.样本是按照某个时序以时间维度采集的数据，有序的样本形成了实际的时间序列数据列表
2.每个样本包括三部分内容：
·指标
·一个float64类型值（value）。
·毫秒级精度的时间戳（timestamp）。
3.对于没有按照顺序收集的样本，Prometheus会将其丢弃。

时间序列（Time Series）：时间序列是根据指标名称和标签的组合唯一确定的数据序列。它表示随着时间推移，相同指标名称和标签组合对应的测量值的演化。时间序列是Prometheus中存储和查询指标数据的基本单位。

作业（job）：Prometheus的采集任务由配置文件中一个个的Job组成，一个Job里包含该Job下的所有监控目标的公共配置，比如使用哪种服务发现去获取监控目标，比如抓取时使用的证书配置，请求参数配置等等。

relabel_configs：每个Job都可以配置一个或多个relabel_config，relabel_config会对Target的label集合进行处理，可以根据label过滤一些
Target或者修改，增加，删除一些label。relabel_config过程发生在Target开始进行采集之前，针对的是通过服务发现得到的label集合。
metrics_relabel_configs： 每个Job还可以配置一个或者多个metrics_relabel_config，其配置方式和relabel_configs一模一样，但是其用于处理的是从Target采集到的数据中的label。

Series：一个Series就是指标名 label集合，在面板中，表现为一条曲线。

head series： Prometheus会将近2小时的Series缓存在内存中，称为head series。
特别注意relable和metrics_relable的区别，前者在抓取前进行，修改的是target的标签，后者在存储前进行，修改的是metric的标签

target：能够被prometheus监控的目标，称为target

指标图例

指标的类型

测量型（gauge）
1.测量值是一个瞬时数据，数值可以上下增减
2.重启进程后，重置为0
3.典型应用有CPU、内存、磁盘的使用率

计数型（counter）
1.最常用
2.从0开始只增不减的数字，可以重置为零
3.典型应用有系统运行时间、设备收发包字节数、登录次数

直方图（histogram）
1.用于表示在一段时间范围内对数据进行采样，对指定区间以及总数进行分组统计。
2.典型应用有请求持续时间、响应大小等等
3.在Prometheus系统中的查询语言中，它有三种作用：
·对每个采样点进行统计，对应到各个分类值中及bucket（可称为“桶”）
·对每个采样点值累计和（sum）
·对采样点的次数累计和（count）

摘要型（summary）
1.Summary即概率图，类似于Histogram，常用于跟踪与时间相关的数据。
2.典型的应用包括请求持续时间、响应大小等。
3.Summary同样提供样本的count和sum功能；还提供quantiles功能，可以按百分比划分跟踪结果，例如，quantile取值0.95，表示取样本里面的95%数据。Histogram需要通过_bucket计算quantile，而Summary直接存储了quantile的值”

prometheus核心组件

1.prometheus服务器
2.client library
3.expertor
4.pushgateway
5.altermanager

指标摘要

指标摘要通常来说， 单个指标对我们价值很小， 往往需要联合并可视化多个指标， 这其中需要应用一些数学变换。 例如， 我们可能会将统计函数应用于指标或指标组， 一些可能应用的常见函数包括：
·计数： 计算特定时间间隔内的观察点数。
·求和： 将特定时间间隔内所有观察点的值累计相加。
·平均值： 提供特定时间间隔内所有值的平均值。
·中间数： 数值的几何中点， 正好50％的数值位于它前面， 而另外50％则位于它后面。
·百分位数： 度量占总数特定百分比的观察点的值。
·标准差： 显示指标分布中与平均值的标准差， 这可以测量出数据集的差异程度。 标准差为0表示数据都等于平均值， 较高的标准差意味着数据分布的范围很广。
·变化率： 显示时间序列中数据之间的变化程度

告警要考虑的因素

要建立一个出色的通知系统， 需要考虑以下基础信息：
·哪些问题需要通知
·谁需要被告知
·如何告知他们
·多久告知他们一次
·何时停止告知以及何时升级到其他人

Prometheus Relabel机制
https://blog.csdn.net/lovely_nn/article/details/123043447

relabel机制的意义

在 Prometheus 中，Relabel（重标记）机制是为了动态地修改或过滤采集到的监控数据（或样本），以便对数据进行更准确的处理、存储、展示或分析。
这机制的存在和意义主要基于以下几点：

1. 数据清洗与修正：采集到的监控数据可能会包含不一致、不准确或需要修正的部分。Relabel 可以用来清洗和修正这些数据，确保其准确性和可信度。
2. 标准化数据格式：不同来源的监控数据可能具有不同的数据格式或标签。Relabel 可以用于标准化这些数据，使其符合统一的数据格式，便于后续处理。
3. 过滤和排除不需要的数据：有时候，我们可能只对特定的数据感兴趣，Relabel 可以帮助我们过滤掉不需要的数据，减少数据存储和处理的负担。
4. 动态标记：在运行时，可以根据特定规则动态地为数据添加、修改或删除标签，这种动态标记可以基于已有的标签或者数据内容。

relabel的类型

relabel_config （常用）
在被prometheus抓取之前修改，针对的是target

metric_relabel_configs （常用）
在被prometheus存储之前修改，针对的是Metric

alert_relabel_configs
在被发送到alertmanager之前，针对的是alert

write_relabel_configs
写到远程存储的样本

工作步骤

1. separator 分隔符将 source_labels 中的标签列表值连接起来
2. regex 正则表达式与上一步连接的字符串进行匹配
3. replacement 引用上面的regex正则表达式捕获组，通过($1, $2, ...)将它们的值进行替换
4. 把经过正则表达式替换的 replacement 字符串作为 target_label 标签的新值存储起来

relabel_config配置语法

[ source_labels: '[' [, ...] ']' ]
[ separator: | default = ; ]
[ target_label: ]
[ regex: | default = (.*) ]
[ modulus: ]
[ replacement: | default = $1 ]
[ action: <relabel_action> | default = replace ]

字段说明
action
执行的 relabeling 动作，可选值包括 replace、keep、drop、hashmod、labelmap、labeldrop 、labelkeep，默认值为 replace
separator
分隔符，一个字符串，用于在连接源标签 source_labels 时分隔它们，默认为;
source_labels
源标签，使用配置的分隔符串联的标签名称列表，并与提供的正则表达式进行匹配
target_label
目标标签，当使用 replace 或者 hashmod 动作时，应该被覆盖的标签名
regex
正则表达式，用于匹配串联的源标签，默认为 (.*)，匹配任何源标签
modulus
模数，串联的源标签哈希值的模，主要用于 Prometheus 水平分片
replacement
写在目标标签上，它可以参考由 regex 捕获的正则表达式捕获组

关于relabel_config的action类型说明：
replace：设置或替换/覆盖标签值，是默认的action
keep：满足特定条件的实例对象进行采集，其他的不采集
drop：满足特定条件的实例不采集，其他的采集
labeldrop：对抓取的实例特定标签进行删除，其他的保留
labelkeep：对抓取的实例特定标签进行保留，其他标签删除
labelmap：将源标签的值映射到一组新的标签中去
hashmod：对服务的整体目标进行分片

白盒/黑盒监控
黑盒监控，主要关注的是现象，一般都是正在发生的东西，例如出现一个告警，某文件系统不可写入，那么这种监控就是站在用户的角度能看到的监控，重点在于能对正在发生的故障进行告警。
白盒监控，主要关注的是原因，也就是系统内部暴露的一些指标，将数据采集后统一发给监控系统。

Prometheus的监控采集形式（白盒）
Exporter target的agent端
Instrumentation target内建prometheus兼容的指标暴露器
Pushgateway 短期的，不易于实现的，自定义的监控

监控的维度
系统层监控 CPU，内存
中间件/基础设施应用的监控 Nginx，MongDB
应用层的监控 代码的状态、性能
业务层的监控 系统登陆、注册数

聚合函数表达式

([parameter,])[without|by()]
先分组，后聚合