Prometheus（一）

前言

在上一篇文章中提到，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 的数据模型。

<点击跳转至开头>