1. 监控架构总览：分层架构与联动机制
现代监控系统已从单点工具演变为多层联动的复杂体系。理解其分层架构是进行故障排查的前提。本章从架构视角拆解监控系统的六大核心层，并阐述层间联动机制。
1.1 监控系统分层架构
监控系统通常划分为以下六个逻辑层，每层职责清晰、接口明确：
| 层级 | 核心职责 | 典型组件/技术 | 关键指标 |
|---|---|---|---|
| 数据采集层 | 从目标系统获取原始指标、日志、链路数据 | Agent、Exporter、SDK、Logstash、Fluentd | 采集覆盖率、采集延迟、资源开销 |
| 传输层 | 将采集数据可靠、低延迟地送达存储或处理端 | Kafka、RabbitMQ、gRPC、HTTP/2 | 吞吐量、丢包率、背压处理能力 |
| 存储层 | 持久化海量时序、日志、链路数据，支持高效查询 | Prometheus TSDB、Elasticsearch、InfluxDB、ClickHouse | 写入TPS、查询P99延迟、数据压缩比 |
| 分析层 | 对存储数据进行聚合、降采样、异常检测、关联分析 | PromQL、LogQL、流式计算引擎、机器学习模型 | 分析准确率、召回率、计算耗时 |
| 告警层 | 根据分析结果触发告警规则，进行分级通知与抑制 | Alertmanager、告警规则引擎、通知渠道 | 告警准确率、误报率、通知延迟 |
| 展示层 | 以可视化方式呈现监控数据、告警状态与拓扑关系 | Grafana、Kibana、自定义Dashboard | 页面加载时间、刷新频率、交互响应 |
架构视角提示： 故障排查时，应首先定位问题发生在哪一层。例如，数据延迟可能是传输层背压，也可能是存储层写入瓶颈；告警风暴则往往是分析层规则配置不当或展示层刷新频率过高导致。
1.2 分层架构总览图
下图展示了六层架构的完整拓扑及数据流向。箭头表示数据从采集到展示的逐层传递，虚线表示告警与展示层的反向控制流。
1.3 层间联动机制概述
分层架构的价值在于层间通过标准化接口形成联动，而非孤立运行。故障排查时，需理解以下四种核心联动模式：
- 数据流联动（正向）： 采集层产生的数据经传输层缓冲、存储层持久化、分析层处理，最终驱动告警与展示。这是最基础的联动路径。
- 控制流联动（反向）： 告警层可触发分析层重新计算（如动态调整阈值），展示层可向采集层下发配置变更（如动态调整采样率）。
- 事件驱动联动： 告警事件可触发自动化运维动作（如自愈脚本），同时将事件回写到存储层用于事后分析。
- 元数据联动： 展示层从存储层获取指标元数据（如标签、维度），用于动态生成图表；告警层从分析层获取规则状态，用于抑制重复告警。
排查要点： 当监控系统出现数据断层时，优先检查相邻层之间的接口是否正常。例如，采集层数据已产生但存储层查不到，应排查传输层是否积压或丢失；告警未触发但分析层有异常，应检查告警规则与分析结果的匹配逻辑。
1.4 联动机制示意图
下图聚焦于层间联动的三种典型模式，展示数据流、控制流与事件流在层间的交互关系。
1.5 架构视角下的排查原则
基于分层架构与联动机制，故障排查应遵循以下原则：
- 分层定位： 先确定故障现象属于哪一层（数据缺失、延迟、告警不准、展示异常），再逐层向下排查。
- 接口验证： 检查层间接口的健康状态（如Kafka消费延迟、存储写入QPS、告警规则命中率）。
- 联动回溯： 当故障跨层时，利用联动机制回溯数据流路径，找到断点或瓶颈。
- 控制流检查： 反向控制流（如动态阈值调整）可能引入配置漂移，需检查变更记录。
常见误区： 不要只关注单层指标。例如，展示层图表空白，可能是采集层Agent挂掉、传输层Kafka积压、存储层查询超时或展示层缓存未刷新。必须结合联动机制逐层验证。