前言
在上一篇文章中提到,Prometheus
是最初在 SoundCloud 上构建的开源系统监视和警报工具包 。对于我们运维工程师来说,其重要程度不言而喻,没有监控就谈不上运维。实际上 Prometheus 并不是想象中那么简单,相关的中文资料是非常少。它不像 zabbix、nagiaos等老牌监控已集成很多模块可直接使用,它需要基本的数学基础知识,同时它对于Linux系统的底层基础知识要求比较严格。举个例子:监控 CPU 的使用率,对于 zabbix 来说就有直接的计算模板进行计算,而对于 Prometheus 来说需要手动进行相关计算,而这个计算取决于你是否对 CPU 使用率
这个概念的认知和理解,以及其工作原理等,对于 CPU 使用率的计算方式后面会提到。
一、架构及特点
1.1 架构
Prometheus 从 exporter 拉取数据,或者间接地通过网关 gateway 拉取数据(如果在 k8s 内部署,可以使用服务发现的方式),它默认本地存储抓取的所有数据,并通过一定规则进行清理和整理数据,并把得到的结果存储到新的时间序列中,采集到的数据有两个去向,一个是报警,另一个是可视化。PromQL 和其他 API 可视化地展示收集的数据,并通过 Alertmanager 提供报警能力。
- Server 主要负责数据采集和存储,提供 PromQL 查询语言的支持。
- Alertmanager 警告管理器,用来进行报警。
- Push Gateway 支持临时性 Job 主动推送指标的中间网关。
1.2 特点
- 多维数据模型
- 灵活的查询语言
- 不依赖分布式存储,单个服务器节点可直接工作;
- 基于HTTP的pull方式采集时间序列数据;
- 推送时间序列数据通过PushGateway组件支持;
- 通过服务发现或静态配置发现目标;
- 多种图形模式及仪表盘支持(grafana);
- 适用于以机器为中心的监控以及高度动态面向服务架构的监控。
以上基本特点再我之前的博客中有提到,那篇文章主要讲了Prometheus 与 Grafana 的一个安装部署过程,有需要的可以去参考一下《Prometheus + Grafana 监控平台》,因此安装过程不再具体介绍。
二、基础配置文件
global:
scrape_interval: 15s
evaluation_interval: 15s
rule_files:
# - "first.rules"
# - "second.rules"
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
说明:
-
global:全局配置模块
scrape_interval: 15s # Prometheus server获取监控指标的频率 evaluation_interval: 15s # Prometheus server评估规则的频率
-
rule_files:规则模块
# 指定我们希望Prometheus服务器加载的任何规则的位置,比如: rule_files: - "rules/*.yml" - "second_rules.yml" # 可加载prometheus.yml所在当前路径下及rules目录下的yml文件
-
scrape_configs:指标监视资源模块
启动Prometheus server时可抓取Prometheus server自身的健康状态,实际上相当于给使用用户的一个参考模板 - job_name: 'prometheus' # 工作名:默认prometheus,可自定义 static_configs: - targets: ['localhost:9090'] # 被监控主机(根据实际情况修改)
三、名词解释
-
Alert:告警
告警是Prometheus服务触发告警规则的结果,Prometheus服务将告警发送到alertmanager(告警管理)
-
Alertmanager:告警管理器
警告管理器接收警告,并把它们聚合成组、去重复数据、应用静默和节流,然后发送通知到邮件、Pageduty或者Slack等系统中。
-
Bridge:网桥
网桥是一个从客户端库提取样本,然后将其暴露给非Prometheus监控系统的组件。例如:Python客户端可以将度量指标数据导出到Graphite。
-
Client library:客户库
客户库是使用某种语言(Go、Java、Python、Ruby等),可以轻松直接调试代码,编写样本收集器去拉取来自其他系统的数据,并将这些度量指标数据输送给Prometheus服务。
-
Collector:收集器
收集器是表示一组度量指标导出器的一部分。它可以是单个度量指标,也可以是从另一个系统提取的多维度度量指标。
-
Direct instrumentation:直接测量
直接测量是将测量在线添加到程序的代码中。
-
Exporter:暴露器
Exporter是暴露Prometheus度量指标的二进制jar,将非Prometheus数据格式的转化为Prometheus支持的数据格式。
-
Notification:通知
通知表示一组或者多组的警告,通过警告管理器将通知发送到邮件,Pagerduty或者Slack等系统中。
-
PromDash:面板
PromDash是Prometheus的Ruby-on-rails主控面板构建器。它和Grafana有高度的相似之处,但是它只能为Prometheus服务。
-
Prometheus:监控系统
Prometheus经常称作Prometheus系统的核心二进制文件。它也可以作为一个整体,被称作Prometheus监控系统。
-
PromQL:查询语言
PromQL是Prometheus查询语言。它支持聚合、分片、切割、预测和连接操作。
-
Pushgateway
Pushgateway会保留最近从批处理作业中推送的度量指标。这允许服务中断后Prometheus能够抓取它们的度量指标数据。
-
Silence
在AlertManager中的静默可以阻止符合标签的告警通知(防止反复发送告警)。
-
Target
在Prometheus服务中,一个应用程序、服务、端点的度量指标数据。
四、数据模型
4.1 Metric(指标)
所谓的指标就是我们监控的目标对象,例如:cpu_usage_system
、mem_used
、disk_used
等。每一个时间序列数据由 metric 度量指标名称和它的标签 labels 值组成。metric度量指标命名:ASCII字母、数字、下划线和冒号,必须配正则表达式[a-zA-Z_:][a-zA-Z0-9_:]*
。
所有指标(Metric)通用格式可表示如下:
<metric name>{<label name>=<label value>, ...}
例如:
diskio_read_bytes{name="dm-0",instance="10.20.10.62:9237"}
# diskio_read_bytes:指标名(Metric)
# {...}:花括号里的内容为标签
4.2 Labels(标签)
标签(label)反映了当前样本的特征维度,通过这些维度可以对样本数据进行过滤、聚合等。标签label名称可以包含ASCII字母、数字和下划线。它们必须匹配正则表达式[a-zA-Z_][a-zA-Z0-9_]*
。注意:带有_
下划线的标签名称被保留内部使用。
例如:
diskio_read_bytes{name="dm-0",instance="10.20.10.62:9237"}
# 上面提到了,花括号中即为标签内容,可包含多组标签,你可以把标签理解为一个键值对,该案例作用就是匹配diskio_read_bytes指标下指定name、instance标签的所有时序数据,而且是当前时间戳的最新数据。
总结
以上是 Prometheus 的基础知识,后面我会结合官方文档和自己实际生产来陆续总结我对 Prometheus 的一些理解,当然也非常欢迎和各位大佬们共同交流/学习。总结一下本次文章主要涉及的内容:
- Prometheus 的架构及其特点(不管学哪一门技术,我觉得这都是必修课);
- 基础配置文件介绍(这里忽略了安装步骤,在我前面的博客中已有介绍,所以这里不再重复操作了);
- 关于 Prometheus 的一些专业名词;
- Prometheus 的数据模型。