Prometheus 监控系统核心概念与架构解析

Prometheus 是什么？

Prometheus 是一套开源的监控、报警及时间序列数据库的组合，最初由 SoundCloud 开发。随着社区发展，它逐渐独立为开源项目并由云原生计算基金会（CNCF）托管。Google SRE 指南中也提及了与其 BorgMon 系统相似的实现思路。如今在 Kubernetes 容器管理生态中，Prometheus 几乎是事实标准的监控组件。

核心优势

• 外部依赖极少，部署简单
• 丰富的系统集成支持（Docker、HAProxy、Nginx、JMX 等）
• 服务自动发现机制
• 可嵌入代码内部采集指标
• 专为分布式和微服务架构设计

关键特性

• 自定义多维数据模型
• 高效存储：单条采样约占用 3.5 字节。以 320 万时间序列、每 30 秒采样、保留 60 天为例，磁盘消耗约 228GB
• 强大的 PromQL 查询语言
• 灵活的可视化集成（Grafana、Promdash 等）

相比 Graphite 等产品，Prometheus 在读写性能上表现优异，其数据结构设计与 OpenTSDB 有异曲同工之妙。

系统架构

核心流程如下：Prometheus Server 负责定时从目标端抓取 metrics 数据，因此每个被监控目标需暴露 HTTP 接口供其拉取。 支持多种服务发现方式，包括配置文件、文本文件、ZooKeeper、Consul 以及 DNS SRV 查找。 Alertmanager 是独立组件，处理 Prometheus 发出的告警通知，支持灵活的路由策略。 可视化方面，除了 Grafana 等主流工具，也提供内置模板引擎及 HTTP API 供自定义输出。 PushGateway 允许客户端主动推送指标数据，适用于短生命周期的任务监控。

熟悉 StatsD 的用户会发现两者相似，区别在于 StatsD 通常采用推模式直接发送服务器，而 Prometheus 主要基于拉取模式。

数据模型

所有数据存储均基于时间序列。一条时间序列由唯一的指标名称（metric name）和一组标签（labels）组成。不同标签组合代表不同的时间序列。

指标名称与标签

每条时间序列格式为：指标名称 {标签="值"}。 指标命名建议遵循 应用_对象_类型_单位 规范，例如：

• push_total
• userlogin_mysql_duration_seconds
• app_memory_usage_bytes

标签用于区分同一指标的不同维度，如 HTTP 请求的方法（GET/POST）或端点（endpoint）。

http_requests_total{method="POST", endpoint="/api/tracks"}

注意：针对同一指标名，增加或删除标签都会形成新的时间序列。若类比传统数据库，指标名相当于表名，标签是字段，timestamp 是主键，数值为 float64 类型。

四种数据类型

Counter

累计值，只增不减。适用于请求总数、错误计数等。重启后重置。 示例：http_response_total{method="GET", endpoint="/api/tracks"} 100

Gauge

常规数值，可增可减。适用于温度、内存使用率等。重启后重置。 示例：memory_usage_bytes{host="master-01"} 100

Histogram