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

Prometheus配置方式有两种：

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

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

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

（1）对进程发送信号SIGHUP

（2）HTTP POST请求，需要开启--web.enable-lifecycle选项curl -X POST http://192.168.66.112:9091/-/reload

配置文件格式是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服务，用以加载生效，也可以使用热加载功能，使其配置生效。然后通过浏览器，访问 http://192.168.1.220:19090/alerts 就可以看 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 http://localhost:9090/-/reload 或者 对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支持多种服务现工具，详细配置这里不再展开

更多参考官网： https://prometheus.io/docs/prometheus/latest/configuratio 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 配置详解

https://www.dazhuanlan.com/2019/12/12/5df11ada207ce/

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

http://www.21yunwei.com/archives/7321

（3）官方文档说明

https://prometheus.io/docs/prometheus/latest/configuration/configuration/

（4）Prometheus监控神器-Rules篇

https://zhuanlan.zhihu.com/p/179295676

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

https://zhuanlan.zhihu.com/p/179292686

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

https://zhuanlan.zhihu.com/p/179294441

日志Logging[ELK]+指标Metrics[AMP]+追踪Tracing[SkyWalking]

通过指标发现性能问题，通过追踪定位性能，通过日志定位出具体请求的明细参数

Actuator+Micrometer+Prometheus+Grafana

Actuator: 采集内部应用内部信息暴露给外部，提供原始监控数据，比如健康检查，指标收集，应用信息

Micrometer: 为性能数据收集提供通用的API，包括：计时器，计数器，可以与不同的监控系统适配

Prometheus: 系统监控报警框架，提供多维度数据模型和灵活的查询方式，采用Pull方式采集数据

Granfana: 数据监控和数据统计，可视化，报警，通知

- 引入SpringBoot Actuator及micrometer    

- 配置actuator

我们只配置了prometheus和loogers，prometheus可以监控程序，loggers可以修改日志级别，其他根据需要开启和关闭。配置以后可以通过/actuator/prometheus进行访问。

* 如果因为contentType访问失败，需要在WebMvcConfig中configureMessageConverters增加"application/openmetrics-text"的支持。

- 主要指标

运行时间

process_uptime_seconds{job="flower-webapi"}

jvm full GC - 24小时gc次数 - 可以设置报警

increase(jvm_gc_pause_seconds_count{application="agent", cause="Metadata GC Threshold"}[24h])

jvm 内存使用 -查看不同区域内存，合理调整jvm参数

jvm_memory_used_bytes{job="flower-webapi", area="heap"}/1024/1024

api qps - 5分钟访问量

sum(increase(http_server_requests_seconds_count{job="flower-webapi"}[5m])/300)

还可以查看

jvm线程数，jvm gc收集次数和收集耗时

接口请求次数，请求时长，日志情况

- 安装和配置

Prometheus监控的目标是：长期趋势分析

Prometheus中文文档

- 探让粗索PromQL

metric指标-要监控的对象

格式：<metric name>{<label name>=<label value>,}

sample-样本-某个时间戳的指标的值

metric类型

Counter计数器：代表一种样本数据单调递增的指标

Guage仪表盘：代表一种样本数据可以任意变化的指标

Histogram直方图：在一段时间内对数据进行采样

Summary摘要斗毁：表示一段时间内的数据采样空滑备结果

部署

docker run -d --name agent-granfana -p 3000:3000 -v grafana.ini:/etc/grafana/grafana.ini grafana/grafana

访问

http://ip:3000

- 同一机器的，使用本机地址访问，端口不对外开发

- 同一机器的，不同Docker，可以使用同一docker网络，端口不用映射

- 同一专有网络的，使用专有网络地址访问，端口不对外开发

- 只有Granfana对外公开，同时设置管理员账号

参考文献

https://mp.weixin.qq.com/s/yqMdXehLCl7-m2kcfjh6OQ

SpringBoot入门系列

番外篇-没用的知识

番外篇-Docker入门

番外篇-Prometheus入门

---