Prometheus

一个开源的监控和告警系统

特点

多维数据模型

  • 使用时间序列数据，每个序列有一个度量指标（metricname）和一组键值对（labels）标识，这样可以灵活对同一类进行细分。
    度量指标
  • counter：计数器，用于记录累计值，例如请求次数。
  • gauge：测量值，可增可减，例如当前内存使用量。
  • histogram：直方图，用于记录值分布，例如请求延迟。
  • summary：摘要，用于统计分位数和总和，例如响应时间的分位数。
标签
  • 一组键值对，用于对时间序列进行细分和区分。例如，监控一个 HTTP 请求的计数器可以通过标签区分不同的请求路径和状态码
http_requests_total{method="POST", handler="/api/v1", status="200"}
http_requests_total{method="GET", handler="/api/v1", status="500"}

例子

假设我们有一个 Web 服务，它记录了每个请求的数量和响应时间。我们可以定义以下指标：

  1. 记录请求数量的计数器：
    • Metric Name: http_requests_total
    • Labels: method, handler, status
  2. 记录响应时间的直方图：
    • Metric Name: http_request_duration_seconds
    • Labels: method, handler

每次有新的请求进来，计数器和直方图都会更新。例如：

http_requests_total{method="POST", handler="/api/v1", status="200"} 1234
http_requests_total{method="GET", handler="/api/v1", status="500"} 56
http_request_duration_seconds_bucket{method="POST", handler="/api/v1", le="0.1"} 5
http_request_duration_seconds_bucket{method="POST", handler="/api/v1", le="0.5"} 50

支持PromQL

查询所有 POST 请求的数量：

promql
复制代码
sum(http_requests_total{method="POST"})

查询 /api/v1 接口的所有请求数量：

promql
复制代码
sum(http_requests_total{handler="/api/v1"})

查询状态码为 200 的请求数量：

promql
复制代码
sum(http_requests_total{status="200"})
优化使用标签
  • 标签数目不要过多：过多的标签会导致时间序列爆炸，影响性能。
  • 标签值尽量稳定：标签值变化太频繁会增加存储和查询负担。
  • 合理设计标签：确保标签的选择能够满足查询需求，同时不过度细化。

时间序列数据库

TSDB Prometheus自带时序数据库
特点

高效写入：Prometheus 的 TSDB 能够每秒写入数百万个样本，适合高频数据采集。
高效查询：针对时间序列数据优化的查询性能。
数据压缩：使用差分编码和 Gorilla 压缩算法减少存储空间。
局部存储：数据默认存储在本地磁盘上，可以通过远程存储扩展。

数据结构

样本 (Sample)：包含一个时间戳和一个值。
时间序列 (Time Series)：由一个度量名和一组标签唯一标识的一组样本。
块 (Block)：TSDB 中的数据以块的形式存储，每个块通常覆盖 2 小时的数据。
WAL (Write-Ahead Log)：在写入到块之前，数据先写入 WAL，以确保数据持久化。

数据存储和管理
  1. 数据存储路径：默认存储路径为 /var/lib/prometheus，可以在 Prometheus 配置文件中通过 storage.tsdb.path 参数修改。
  2. 数据保留策略：默认保留 15 天的数据，可以通过 –storage.tsdb.retention.time 参数设置。
  3. 数据压缩和删除：Prometheus 会自动压缩和删除过期数据。

    独立抓取模型：

基本概念
  1. Scrape：Prometheus 从目标处获取监控数据的过程。
  2. Target：被监控的对象，可以是服务器、应用程序、数据库等。
  3. Job：一组相似目标的集合。
  4. Exporter：用于将目标的数据暴露给 Prometheus 的组件，通常是 HTTP 端点
配置文件’prometheus.yml’
global:
  scrape_interval: 15s     # 每15秒抓取一次数据
  evaluation_interval: 15s # 每15秒评估一次规则
抓取配置

抓取配置定义了 Prometheus 如何发现和抓取目标数据。

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
动态服务发现

Prometheus 支持多种服务发现机制，允许动态发现目标。例如，可以使用 Kubernetes、Consul、Etcd 等进行服务发现。

####### Exporter
Exporter 是将监控数据暴露给 Prometheus 的组件，不同的应用和系统有不同的 Exporter。例如：

  • Node Exporter：用于监控操作系统的资源使用情况。
  • Blackbox Exporter：用于进行探测和检查（如 HTTP、HTTPS、TCP）。
  • MySQL Exporter：用于监控 MySQL 数据库。

多种数据支持：

支持包括通过导出器（exporters）收集第三方系统的数据，支持服务发现（Service Discovery），如 Kubernetes、Consul、Etcd 等

告警：

内置了 Alertmanager，用于处理告警通知和管理告警规则。

结构

  1. Prometheus Server：
    存储：使用基于时间序列数据库（TSDB）的本地存储来存储监控数据。
    抓取（Scrape）：定期从目标端点（如应用程序、数据库等）拉取指标数据。
    PromQL 查询引擎：允许用户通过 PromQL 查询存储的数据。
  2. 数据导出器（Exporters）：
    节点导出器（Node Exporter）：收集系统级别的指标，如 CPU、内存、磁盘使用等。
    应用程序导出器：如 MySQL Exporter、Redis Exporter，专门用于从特定应用中收集指标。
  3. 服务发现（Service Discovery）：
    支持多种服务发现机制，如 Kubernetes、Consul、DNS 等，自动发现并监控动态变化的服务和主机。
  4. Alertmanager：
    告警规则：定义告警规则，当满足条件时触发告警。
    告警通知：管理告警的路由和发送，支持多种通知方式，如电子邮件、Slack、PagerDuty 等。
    告警抑制和分组：可以配置告警抑制规则和告警分组，避免告警风暴。
  5. Pushgateway：
    用于接收临时性任务（如批处理任务）的指标数据，这些任务无法被 Prometheus 定期拉取。

工作流程

  1. 配置和服务发现：通过配置文件或服务发现机制，Prometheus 确定需要监控的目标。
  2. 抓取数据：Prometheus 定期从目标端点拉取指标数据。
  3. 存储数据：将拉取到的指标数据存储在本地的时间序列数据库中。
  4. 查询和可视化：通过 PromQL 查询数据，结合 Grafana 等可视化工具展示监控结果。
  5. 告警处理：根据定义的告警规则，Prometheus 触发告警并通过 Alertmanager 发送通知。