2. 监控体系架构

监控体系不是“装一个采集器 + 配一个告警”就能成立的。它更像一条从被监控对象到运维人员的完整信号链：采集层负责把设备、系统、应用的真实状态变成可传输的数据；传输层负责把这些数据可靠、低延迟地送到后端；存储层负责按时间序列保存并支撑查询；分析层负责把原始数据变成有意义的判断；告警层负责把判断结果以合适的方式送达正确的人。五层各司其职，又必须协同，任何一层职责错位，都会表现为“监控不准、告警不灵、排障不快”。

一、五层职责划分

采集层是监控体系的“感官”。它的核心职责是把被监控对象的状态转换为结构化数据，包括指标（Metrics）、日志（Logs）、链路追踪（Traces）和事件（Events）。采集方式主要有三类：一是 Agent 主动采集，例如在 Linux 主机上部署 node_exporter，暴露 /metrics 接口；二是无 Agent 的远程探测，例如 SNMP 轮询交换机、ICMP 探测、HTTP 探活；三是应用内埋点，例如通过 OpenTelemetry SDK 上报调用链。采集层的关键参数是采集周期和超时时间。例如主机指标 15s 一次、端口探活 30s 一次、日志实时推送，都是常见配置。采集层不负责判断“是否异常”，它只负责“如实上报”。

传输层是监控体系的“神经”。它负责把采集数据从边缘送到中心，常见协议包括 Prometheus 的 remote_write、Kafka 消息队列、Fluentd/Filebeat 日志转发、gRPC/HTTP 上报。传输层要解决三个问题：可靠性（断点续传、本地缓存、重试）、吞吐与延迟（批量、压缩、分区）、安全（TLS、鉴权、网络隔离）。例如在跨机房场景中，采集端先写入本地 Kafka，再由 MirrorMaker 同步到中心集群，可以避免网络抖动导致数据丢失。传输层一旦积压，分析层看到的就是“延迟的数据”，告警就会滞后。

存储层是监控体系的“记忆”。它按数据类型选择不同存储：时序指标通常进入 Prometheus、VictoriaMetrics、InfluxDB；日志进入 Elasticsearch、Loki；链路进入 Jaeger、Tempo。存储层的核心职责是按时间维度高效写入与查询，并通过保留策略（Retention）控制成本。例如原始指标保留 15 天、降采样后的 5 分钟粒度保留 1 年，是常见做法。存储层还要处理标签基数（Cardinality）问题：如果给每个请求都打上唯一 ID 作为标签，时序数量会爆炸，写入和查询都会崩溃。

分析层是监控体系的“大脑”。它把存储层的数据转化为判断，包括阈值判断、同比环比、基线检测、多指标关联、日志聚类、根因分析。分析层的输出不是“数据”，而是“结论”：某服务错误率超过 5%、某主机磁盘 4 小时内将写满、某接口 P99 延迟较昨日同时段上升 3 倍。分析层要明确判断窗口和聚合维度。例如 rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05，表示 5 分钟窗口内 5xx 占比超过 5%。窗口太短会抖动，太长会迟钝。

告警层是监控体系的“手脚”。它负责把分析层的结论转化为可送达、可处理、可闭环的通知。告警层要处理去重、抑制、静默、分组、升级、路由。例如同一台主机 100 个指标同时异常，应聚合成一条“主机异常”告警，而不是发 100 条；维护窗口内应静默；核心交易告警应电话升级，普通告警走 IM 群。告警层还要记录告警产生、认领、处理、恢复的全过程，否则无法复盘。

二、协同关系：数据流与反馈闭环

五层之间不是简单的串联，而是“正向数据流 + 反向反馈流”的双向协同。正向流是：采集层产生数据 → 传输层搬运 → 存储层落盘 → 分析层计算 → 告警层通知。反向流是：告警层的结果和运维人员的处置经验，反过来调整采集周期、传输策略、存储保留、分析窗口和告警规则。没有反向流，监控体系就会僵化：采集周期永远 15s，但业务已经变成秒级交易；告警规则永远 5 分钟，但故障已经要求 30 秒内发现。

举一个具体的协同示例。某电商系统在大促期间出现“订单创建接口 P99 延迟升高”。采集层每 15s 采集一次 JVM 指标和 HTTP 指标；传输层通过 Kafka 将数据送到中心；存储层写入 VictoriaMetrics；分析层用 histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{path="/order/create"}[5m])) 计算 P99；告警层在 P99 超过 800ms 持续 2 分钟时触发告警。运维人员收到告警后，发现是数据库连接池耗尽，于是扩容连接池，同时把采集周期从 15s 调整为 5s，把分析窗口从 5m 调整为 2m，以便更快发现同类问题。这就是一次完整的协同闭环。

三、常见职责错位与判断依据

实际运维中，五层职责错位非常常见，识别这些错位是排障的关键。

• 采集层做了分析层的事：在 Agent 里写复杂判断逻辑，导致采集端 CPU 升高、规则难以统一管理。判断依据：Agent 配置中出现大量 if-else 阈值判断，而不是单纯暴露指标。
• 传输层做了存储层的事：在 Kafka 中长期保留原始数据，把消息队列当数据库用。判断依据：Kafka 磁盘持续增长，且消费延迟与保留策略无关。
• 存储层做了分析层的事：在 Prometheus 中配置大量 recording rules 做复杂聚合，导致查询变慢。判断依据：recording rules 数量超过 200 条，且规则计算耗时占 CPU 比例过高。
• 分析层做了告警层的事：在分析脚本里直接发邮件、发短信，绕过告警层的去重和抑制。判断依据：同一故障收到多条重复通知，且无法统一静默。
• 告警层做了分析层的事：在告警规则里写复杂 SQL 或长表达式，导致告警评估超时。判断依据：告警规则评估时间超过采集周期，出现漏报。

四、分层设计的一个可参考参数基线

以下参数基线适用于中等规模（约 500 台主机、50 个服务）的监控体系，可作为初始配置参考，实际需根据业务容忍度和资源情况调整。

需要强调的是，这张表不是“标准答案”，而是帮助理解各层参数如何相互制约的示例。例如采集周期从 15s 改为 5s，传输层吞吐会变为原来的 3 倍，存储层写入压力也会同步上升，分析层的窗口如果仍保持 5 分钟，则灵敏度提升有限。因此，任何一层的参数调整，都要评估对上下游的影响，而不是孤立地改一个数字。

五、协同关系的核心结论

采集层要“准”，传输层要“稳”，存储层要“省”，分析层要“灵”，告警层要“准而少”。五层之间通过正向数据流和反向反馈流形成闭环。判断一个监控体系是否成熟，不看它有多少个仪表盘，而看它能否在故障发生时，用最短的路径把正确的信息送到正确的人手里，并且在故障结束后，能把经验沉淀为规则和参数的调整。这才是五层架构真正的协同价值。