监控系统基础：采集、存储、展示、告警四个核心环节

做了这么多年监控系统，我越来越觉得，搞懂这四个环节比什么都重要。哪四个？采集、存储、展示、告警。说白了，就是把数据拿过来、存起来、画出来、再决定要不要喊人。你想想看，任何一个监控系统，都逃不出这个框架。这四个环节不是孤立的，它们环环相扣，缺一个整个系统就转不起来。

01 采集——一切数据的起点

采集是源头。没有数据，后面存储、展示、告警全是空谈。我个人习惯把采集拆成两个问题：采什么和怎么采。

采什么？三类数据是主流：

• 指标（Metrics）：CPU、内存、请求延迟、QPS……这些是数值型的时间序列数据，最核心。
• 日志（Logs）：应用打出来的文本记录，结构化或非结构化都常见。
• 链路追踪（Traces）：一个请求从入口到所有依赖服务的完整调用链。

怎么采？业界主要有两种模式——推和拉。我在项目中见过不少团队在这上面踩坑。两种模式各有优劣，直接看对比：

对比维度	推模式 (Push)	拉模式 (Pull)
数据流向	Agent 主动发送 → 接收端	Server 主动抓取 ← 目标端
代表工具	Telegraf、StatsD、Pushgateway	Prometheus Server
适用场景	短生命周期任务、批处理、边缘节点	长期运行的微服务、基础设施
核心优势	动态环境灵活，目标无需暴露端口	采集节奏可控，便于服务发现
主要劣势	接收端压力不可控，存在丢数据风险	需要服务注册与发现机制

采集策略上，不是所有数据都要全量采。对于高基数指标，我建议做采样或聚合。比如请求延迟，可以采 P50、P95、P99，而不是把每个请求的延迟都存下来。

02 存储——数据的持久化基石

数据采回来，得有个地方存。监控数据的特点是写多读少、时间范围查询、数据量大。传统关系型数据库扛不住这种负载，所以有了时序数据库（TSDB）。

我在项目中用过 Prometheus、InfluxDB 和 VictoriaMetrics。选型时重点看三点：写入吞吐量、压缩比、查询性能。

数据模型是所有 TSDB 的核心。拿 Prometheus 举例：

metric_name{label1="value1", label2="value2"} value timestamp

一条数据由 指标名 + 标签 + 值 + 时间戳 组成。标签用来做维度过滤和聚合，这也是时序数据灵活性的来源。

存储策略上，我最常关注两个参数：

• 保留期（Retention）：原始数据存多久？7 天、30 天还是 90 天？
• 下采样（Downsampling）：老数据按小时或天聚合，降低存储成本。

03 展示——数据的外在表达

数据存好了，得让人看懂。展示这层的核心工具是仪表盘（Dashboard），Grafana 是目前的事实标准。

我个人习惯在仪表盘上只放 5-7 个关键图表，一屏能看完最好。展示不是堆图表，而是讲清楚系统的健康状况。

常见的图表类型：

• 折线图：展示趋势，比如 CPU 使用率的变化。
• 柱状图：做对比，比如各节点的内存占用。
• 热力图：看分布，比如请求延迟的散点分布。
• 仪表盘/数字：展示关键状态，比如当前 QPS、错误率。

查询语言是展示层的灵魂。用 PromQL 举个例子：

# 过去5分钟CPU平均使用率超过80%的节点
avg by(instance) (rate(cpu_usage_total[5m])) > 0.8

一条好的 PromQL 能把复杂的聚合逻辑表达清楚，比写一堆代码省事多了。

04 告警——监控的价值出口

监控的最终价值不是看数据，而是触发行动。告警就是那个“喊人”的机制。

告警规则定义“什么情况需要喊人”。比如 Prometheus 的规则配置：

groups:
- name: system-alerts
  rules:
  - alert: HighCPUUsage
    expr: cpu_usage_percent > 90
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "节点 {{ $labels.instance }} CPU 使用率超过 90%"

这个规则说：CPU 使用率超过 90% 且持续 5 分钟，就触发告警。这里的 for 字段很关键——避免瞬时抖动导致误报。

告警分级我通常分四级：

• P0（致命）：核心服务不可用，立即响应。
• P1（严重）：功能受损，需要快速处理。
• P2（一般）：异常但影响有限，工作时间内处理。
• P3（提醒）：只是通知，不强制响应。

但光有分级还不够，告警多了就是噪音。关键在告警收敛：

• 抑制（Inhibition）：上游挂了，下游的告警自动闭嘴。
• 聚合（Grouping）：同类告警合并成一条，避免轰炸。
• 静默（Silence）：已知问题或维护期间暂时屏蔽。

05 四环节的闭环关系

采集、存储、展示、告警不是串行完事，而是一个闭环。告警推动你调整采集策略，展示帮你验证存储是否可靠，存储反过来影响采集的频率和粒度。任何一个环节出问题，整个系统都会跟着抖。

下面这张图把四个环节的关系画清楚了：

你看，告警发现问题后，你会回来调整采集的粒度或新增指标；展示时发现数据不准，你会回头检查存储和采集链路。这个闭环转得越快，系统的可观测性就越成熟。