昔日教人类用火的prometheus，如今在努力报警
原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。
像我这么热爱野外生活的人，初冬时节，还找了个隐蔽的地方去野炊。现在的社会，为了找找到这么一个静谧的存在，我可谓煞费苦心。
初冬的夜，连虫鸣声都没有，星空高而深远。蜷缩在篝火旁边，我想起了普罗米修斯。在希腊神话中，他教会人类学会使用火，彻底告别了茹毛饮血的年代。
早在2012年，还有一部叫做《普罗米修斯》的电影上演，它是《异行》的前传，其壮丽宏大的场景让人印象深刻。
在这无尽的时空和未知的领域面前，我一个小小程序员，真是连屁都不如。比我强大的比我用功，比如立下flag学python的潘总，他应该能勉强算得上个屁。
普罗米修斯的英文是prometheus，从这拗口的名字就可以看出，它是个舶来品。prometheus是google内部监控报警系统的开源版本，现在非常流行。
监控系统是老生常谈的问题了，xjjdog在以前也专门总结过。《这么多监控组件，总有一款适合你》，这篇长文，从多个维度上介绍了监控体系，而prometheus面向的就是metric类型的数据监控。
今天，我们要着重介绍的，就是prometheus。来势汹汹，大有一统天下的架势。本篇文章主要是为了引起你的兴趣，并提供了很多实践过的配置文件。说了这么多废话，就让我们正式开始吧。
1、介绍
你在使用一些类似于grafana的展示组件时，能够发现底层的数据存储，能够使用Prometheus，而这两个东西明显没有血缘关系。在享受grafana至高无上的美丽时，应该认识到一个现实：现在的监控系统，都拆分成了非常具体的细小模块，让你可以根据经验和习惯进行精细化选择。
Prometheus生态系统由多个组件组成，其中一些是可选的。多数Prometheus组件由Go语言编写，使这些组件很容易编译和部署。网上很多文章翻译的晦涩难懂，xjjdog在这里便使用人话描述。
注：敲黑板，带★是重点，要考 。不学没法用
★1）Prometheus Server：主要负责数据采集和存储，提供PromQL查询语言的支持。注意，它同时是一个存储！
2）客户端SDK：支持非常多语言的类库，越多越好。
3）Push Gateway：Prometheus获取监控数据的主要方式是拉取模式，但总有一些瞬时发生的监控项，这种信息无法pull。所以这个组件是为了支持一些存活时间很短的事件，把这些信息进行缓冲。
4）PromDash：使用Rails开发可视化的Dashboard，用于可视化指标数据
★5）Exporter：数据采集组件，也就是一些agent。负责从目标处搜集数据，并将其转化为Prometheus支持的格式
★6）Alertmanager：报警管理器，用于发送到正确的逻辑分组。常见的接收方式有：电子邮件，pagerduty，OpsGenie, webhook 等
7）prometheus_cli：命令行工具
8）其他辅助性工具：多种导出工具，可以支持Prometheus存储数据转化为HAProxy、StatsD、Graphite等工具所需要的数据存储格式
长篇大论的扯了一通，还是逃脱不了收集、处理、展示三大部件。看了以上的介绍，你应该能够看懂这张官方图。看那些大框框，不要关注细节。
我们来抽取一下比较特殊的要点。
1）它获取监控数值的方式是拉模式
2）它有一个存储数据的时序数据库，查询语言灵活，但不是SQL
3）有SDK、Agent、中间网关三种数据汇总方式
4）可以使用grafana代替它自带的丑八怪界面
5）能够细粒度配置报警，统一管理
2、安装和配置
了解了上面的组件，安装配置就顺利的多。先把Prometheus下载下来，然后解压。
cd /opt
wget -c https://github.com/prometheus/prometheus/releases/download/v2.14.0/prometheus-2.14.0.linux-amd64.tar.gz
tar zxvf prometheus-2.14.0.linux-amd64.tar.gz2.1、配置server
在安装目录下编辑配置文件prometheus.yml，我们解释比较重要的部分。很多时候，我们需要监控非常多的组件，比如系统状态、canal、kafka、jvm等等，如果将所有的配置文件都放在这里，势必会又臭又长，所以一般采用子配置文件的方式。注意，配置文件分了两部分，上面的是触发规则，下面的是主机名称，注意区别。
各个被监控的组件，需要自行部署Exporter，然后把http接口暴露出来。
alerting:
alertmanagers:
- static_configs:
- targets: ["10.81.28.227:9093"]
# 分文件配置，我们以sys系统参数为例说明
rule_files:
- "sys_monit.yml"
- "kafka_monit.yml"
# 抓取配置
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
labels:
group: "监控服务端"
- job_name: 'system'
#通过文件去动态发现配置
file_sd_configs:
- refresh_interval: 1m
files:
- sys.yml #配置文件路径
- job_name: 'kafka'
file_sd_configs:
- refresh_interval: 1m
files:
- kafka.yml再来看一下其中一个子配置文件sys.yml，它定义了一批要监控的机器。也就是到什么地方去找数据。
[
{
"labels": {
"job": "shop001.web.pub.pro.ali.dc",
"instance": "system"
},
"targets": [ "10.174.88.9:9100"
] }
]然后我们启动Prometheus：
nohup ./prometheus &2.2、报警配置
alertmanager需要单独下载，这种方式真是脑回路惊奇。
https://github.com/prometheus/alertmanager/releases报警的配置文件分为两部分，其中一部分，放在上面的prometheus.yml文件中rule_files模块，用来指定匹配规则；另外一部分，放在alertmanager.yml中，用来指定报警的去向。
比如，我想要把报警发送到臭名昭著的dingding，就可以这么写。
global:
resolve_timeout: 5m
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 10m
receiver: 'pro'
routes:
- receiver: 'canal'
match:
alertname: 'canal 延迟'
receivers:
- name: 'sys'
webhook_configs:
- url: 'http://10.81.28.227:8060/dingtalk/pro/send'
- name: 'canal'
webhook_configs:
- url: 'http://10.81.28.227:8060/dingtalk/canal/send'接下来看一下规则部分，比如sys_monit.yml，你应该看到这个过程是怎么运转起来的了。
roups:
- name: netstat_tcp_time_wait
rules:
- alert: 主机连接数 time_wait
expr: netstat_tcp_time_wait > 60000
for: 5m
labels:
status: warning
annotations:
summary: "{{$labels.job}}"
description: "{{ $labels.instance }} time_wait > 60k(当前值：{{ $value}})"如果你安装了dashboard的话，应该能看到这些信息了。但是，每次更改阈值，都需要重启server，这一部分，做的不是很好。另外，yml深层的嵌套信息，在配置繁多的时候，显得比较杂乱。从上面的配置文件就可以看出，这些配置文件的解析，使用的是简单的占位符的方式。在设计报警之前，你需要知道每一个监控项的名称，以及意义。
3、其他集成
telegraf是比较好用的数据收集agent。通常，它是通过push的方式汇报监控数据，但是通过加入几行配置，可以把push变成pull（暴露一个专用接口）。主要的配置文件如下：
[[outputs.prometheus_client]]
listen = "0.0.0.0:9100"以下是一个grafana主机监控的效果图。由于它的颜值比prometheus自带的高，所以一般都使用grafana。
但是自带的UI也不是一无是处，比如下面查看整个系统机器状态的页面。
用于调试查询语句的界面等。
另外，prometheus可以很容易的接入以下的系统：
1) springboot。参见
https://yq.aliyun.com/articles/272542
2） canal接入。在canal.properties 中添加
canal.metrics.pull.port=11112注意：canal版本必须canal 1.1.x系列以上
End
一个监控系统，主要的难点是生态。prometheus最近几年发展迅速，非常多的组件都对其进行了集成，这对我们来说是比较大的福音。但是，它的配置文件还是有点复杂，尤其是在管理大型机器群的时候，需要频繁的更改配置文件，并不能够做到自动发现。
所以，通常使用prometheus的时候，会配合很多内部系统，写很多的shell脚本，自动更改这些配置进行重启，尽量做到自动化。
由于涉及的配置文件，实在是太多，且配置有相对的难度。我将这些信息，放在了仓库里。有需要的，自行参考。
https://github.com/xjjdog/prometheus-cnf-pro清单：
1、prometheus配置，规则配置 (11个)
2、alertmanager配置 (1个)
3、telegraf (2个)
4、grafana(5个）
作者简介：小姐姐味道 (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。
近期热门文章
《996的乐趣，你是无法想象的》
魔幻现实主义，关爱神经衰弱
《一切荒诞的傲慢，皆来源于认知》
不要被标题给骗了，画面感十足的消遣文章
《必看！java后端，亮剑诛仙》
后端技术索引，中肯火爆。全网转载上百次。
《学完这100多技术，能当架构师么？（非广告）》
精准点评100多框架，帮你选型
《Linux上，最常用的一批命令解析（10年精选）》
CSDN发布首日，1k赞。点赞率1/8。