Prometheus监控系列三 | 架构详解

Prometheus监控系列三 | 架构详解

1 官方架构图

Prometheus 是一套开源的系统监控报警框架。它是由 Google 前员工在2012年创建，作为社区开源项目进行开发，并于2015年正式发布。2016年，Prometheus 正式加入 Cloud Native Computing Foundation。

2 组件介绍

2.1 Prometheus Server

用于收集和存储时间序列数据。Prometheus Server 是 Prometheus 组件中的核心部分，负责实现对监控数据的获取，存储以及查询。 Prometheus Server 可以通过静态配置管理监控目标，也可以配合使用 Service Discovery 的方式动态管理监控目标，并从这些监控目标中获取数据。其次 Prometheus Server 需要对采集到的监控数据进行存储，Prometheus Server 本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后Prometheus Server 对外提供了自定义的 PromQL 语言，实现对数据的查询以及分析。

2.2 Exporter

用于暴露已有的第三方服务的 metrics 给 Prometheus。Exporter 将监控数据采集的端点通过 HTTP 服务的形式暴露给 Prometheus Server，Prometheus Server 通过访问该 Exporter 提供的 Endpoint 端点，即可获取到需要采集的监控数据。

2.3 Push Gateway

主要用于短期的 jobs。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这些 jobs 可以直接向 Prometheus server 端推送它们的 metrics。

2.4 Grafana

第三方展示工具，可以编写 PromQL 查询语句，通过 http 协议与 prometheus 集成。

2.5 AlertManager

从 Prometheus Server 端接收到 alerts 后，会进行去除重复数据，分组，并路由到对方的接受方式，发出报警。常见的接收方式有：电子邮件，钉钉、企业微信，pagerduty等。

2.6 Client Library

客户端库，为需要监控的服务生成相应的 metrics 并暴露给 Prometheus Server。当 Prometheus Server 来 pull 时，直接返回实时状态的 metrics。

3 Prometheus工作流程

• 指标采集：prometheus server 通过 pull 形式采集监控指标，可以直接拉取监控指标，也可以通过 pushgateway 做中间环节，监控目标先 push 形式上报数据到 pushgateway；
• 指标处理：prometheus server 将采集的数据存储在自身 db 或者第三方 db；
• 指标展示：prometheus server 通过提供 http 接口，提供自带或者第三方展示系统；
• 指标告警：prometheus server 通过 push 告警信息到 alert-manager，alert-manager 通过"静默-抑制-整合-下发"4个阶段处理通知到观察者。

4 Prometheus四种指标分类

Counter

计数器类型，只增不减，如机器的启动时间，HTTP 访问量等。机器重启不会置零，在使用这种指标类型时，通常会结合rate()方法获取该指标在某个时间段的变化率。

Gauge

仪表盘，可增可减，如CPU使用率，大部分监控数据都是这种类型的。

Summary

客户端定义；Summary，Histogram 都属于高级指标，用于凸显数据的分布情况。

Histogram

服务端定义，相比 Summary 性能更好，反应了某个区间内的样本数。

5 服务发现

5.1 基于文件的服务发现

通过创建 target.json 文件，将所有的 target 配置在 target.json，在需要更新 target 的时候，只需要更新 target.json，格式如下：

[
  {
    "targets": [ "localhost:8080"],
    "labels": {
      "env": "localhost",
      "job": "cadvisor"
    }
  }
]

在 prometheus 启动的时候，通过 --config.file 指定配置文件 prometheus.yml，格式如下：

global:
  scrape_interval: 15s
  scrape_timeout: 10s
  evaluation_interval: 15s
scrape_configs:
  - job_name: 'file_ds'
    file_sd_configs:
    - refresh_interval: 1m
    - files:
      - targets.json

其中 refresh_interval 指定了定时读取 target.json 的时间间隔。

这种方式虽然解决了不需要修改 prometheus.yml 的问题，但是问题改成了需要运维维护 target.json，没根本解决问题。

5.2 基于Consul的服务发现

关于 Consul 的介绍这里不多介绍，我们只需知道，Consul 是一个服务配置、发现的中间件。

在基于文件的服务发现中提到，target 的更新需要修改 target.json，本质上没有解决运维操作的步骤。而基于 Consul 的服务发现，则是通过节点主动注册信息到 Consul，prometheus 通过和 Consul 集成，从 Consul 中以 http 协议获取 target 的信息，集成见 prometheus.yml 部分配置：

- job_name: consul_sd
    metrics_path: /metrics
    scheme: http
    consul_sd_configs:
      - server: ${consul_ip}:8500
    relabel_configs:
    # 删除consul自身
    - source_labels: [__meta_consul_service]
      regex: '^consul$'
      action: drop
    #元数据信息添加到job标签
    - source_labels: [__meta_consul_service]
      target_label: "job" 

缺点：

• 需要引入额外的中间件 consule
• 需要与 target 集成，在 target 启动时，需要在 consul 上进行注册

5.3 其他动态的服务发现

• azure_sd_config ：从 Azure 的 vm 上拉取配置
• dns_sd_config: 基于 dns 的服务发现

5.4 对比

方式	有点	缺点	依赖项	是否建议
基于文件的服务发现	简单	没解决根本问题，不能采用		不建议采用
基于Consul的服务发现	便于运维	需要target继承sdk，在sdk中向consul注册节点信息	consul集群	建议采用
其他服务发现	便于运维	依赖资源层环境		不建议采用
使用pushgateway	便于运维	需要target继承sdk，在sdk中定时上报指标；单点问题，需要借助nginx实现多机部署		可以考虑

6 AlertManager配置介绍

分组

将告警消息分组，便于大量告警 涌入时带来 通知过多问题。

静默

按照一定规则，在一定时间内不进行通知下发，在时间阈值达到后，进行下发。

抑制

一个告警消息被另一种告警消息抑制，另一种告警发送后，该告警不下发。

管理API

HTTP_METHOD	PATH	DESCRIPTION
GET	/~/healthy	Returns 200 whenever the Alert manager is healthy.
GET	/~/ready	Returns 200 whenever the Alert manager is ready to serve traffic.
PUT	/~/reload	Triggers a reload of the Alertmanager configuration file.