Prometheus（一）

云计算-Security

已于 2023-10-05 13:18:25 修改

阅读量280

点赞数

分类专栏：监控文章标签：运维 linux 服务器

于 2021-07-05 16:27:37 首次发布

本文链接：https://blog.csdn.net/IT_ZRS/article/details/118492549

版权

监控专栏收录该内容

16 篇文章 7 订阅

订阅专栏

前言

在上一篇文章中提到，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标签的所有时序数据，而且是当前时间戳的最新数据。