2. 监控体系架构设计：拉模式 vs 推模式、分层架构、数据流设计
监控架构选型，说白了就是回答两个问题：数据怎么拿？数据怎么流？
我见过不少团队，一上来就追时髦，Prometheus 拉模式、Kafka 推模式全上，结果数据链路乱成一锅粥。排错的时候，连数据丢在哪一步都搞不清楚。今天咱们就把这事掰扯清楚。
2.1 拉模式 vs 推模式：谁更适合你？
先看一张对比图，心里有个底。
核心结论：拉模式适合指标类监控（CPU、内存、QPS），推模式适合事件类监控（日志、异常、调用链）。
| 维度 | 拉模式 (Pull) | 推模式 (Push) |
|---|---|---|
| 典型代表 | Prometheus | Datadog Agent / Kafka |
| 数据采集 | 监控系统主动拉取目标端点 | 目标主动上报数据到收集端 |
| 服务发现 | 依赖注册中心（Consul/K8s API） | 依赖 Agent 配置或 SDK |
| 扩展性 | 拉取频率受限于采集器数量 | 容易水平扩展，数据先入队列 |
| 数据丢失风险 | 目标宕机则丢失该周期数据 | 队列缓冲，重试机制更灵活 |
| 防火墙友好 | 需要目标暴露端口，跨网络麻烦 | Agent 主动出站，穿透性好 |
| 适用场景 | 基础设施指标、K8s 集群 | 业务日志、分布式追踪、事件告警 |
我个人习惯：核心指标用拉模式，业务事件用推模式。为什么？
拉模式有个天然好处——谁拉谁负责。监控系统知道每个目标上次拉取的时间，如果超时了，立刻能感知到。我在项目中遇到过一个问题：业务方用推模式上报订单量，结果 Agent 进程 OOM 了，数据停了 3 小时没人发现。换成拉模式后，Prometheus 直接报 TargetDown，5 分钟就发现了。
避坑指南：我曾经在混合架构里犯过一个错——让同一个指标既走拉又走推。结果告警重复，数据对不上。后来定了个规矩：一个指标只走一条路。拉模式的数据源在 Prometheus 里查，推模式的数据源在 Elasticsearch 或 Kafka 里查，互不干扰。
2.2 分层架构：别让监控系统变成单点
你想想看，如果监控系统自己挂了，谁来监控监控？所以架构必须分层。
我一般把监控体系分成四层：
- 采集层：Exporter、Agent、SDK。负责从目标拿数据。
- 传输层：消息队列、负载均衡。负责把数据安全送到后端。
- 存储层：时序数据库、日志存储。负责持久化。
- 展示层：Grafana、告警引擎。负责可视化和通知。
下面这张图能帮你快速理解分层关系：
嗯，这里要注意：每一层都要有高可用设计。采集层可以多副本部署，传输层用 Kafka 做缓冲，存储层做数据分片和副本。我曾经见过一个团队，存储层只部署了一个单机 Prometheus，硬盘满了直接丢数据。后来我帮他们加了 Thanos 做长期存储和全局视图，才算稳下来。
警告：不要把所有监控数据都塞进同一个存储后端。指标数据用 TSDB，日志数据用 ES，调用链数据用 Jaeger。混在一起会导致查询性能急剧下降，排错时你连日志都搜不出来。
2.3 数据流设计：从采集到展示，每一步都要可观测
数据流设计，说白了就是数据从哪来，经过哪，到哪去。我习惯画一张数据流图，标清楚每个节点的输入输出。
以拉模式为例，典型的数据流是这样的：
- Exporter 暴露端点：比如 node_exporter 在 9100 端口暴露 /metrics。
- Prometheus 拉取：根据服务发现配置，定时（默认 15s）拉取数据。
- 数据写入 TSDB：Prometheus 将数据写入本地磁盘或远程存储。
- Grafana 查询：Grafana 通过 PromQL 查询数据并渲染图表。
- 告警触发：Prometheus Alertmanager 根据规则发送告警。
推模式的数据流稍有不同：
- Agent 采集：比如 Filebeat 采集日志文件。
- 发送到 Kafka：Agent 将数据推送到 Kafka Topic。
- 消费者处理：Logstash 或 Flink 从 Kafka 消费数据，做清洗和转换。
- 写入存储：数据写入 Elasticsearch 或 ClickHouse。
- 展示与告警：Kibana 展示，ElastAlert 触发告警。
关键设计原则：数据流中每个环节都要有指标暴露。比如 Kafka 的消费延迟、Prometheus 的拉取成功率、ES 的写入速率。这样当数据链路出问题时，你能快速定位是哪个环节卡住了。
我记得有一次线上告警延迟了 20 分钟才收到。查了一圈，发现是 Kafka 消费组 lag 飙到了 10 万条，但消费端没有监控消费延迟。后来我在每个消费者里都加了一个指标：consumer_lag，一旦超过阈值立刻告警。从那以后，数据积压再也没超过 5 分钟。
2.4 实战建议：如何选择你的第一套架构？
如果你是刚起步，我建议这样选：
- 团队小于 10 人：直接用 Prometheus + Grafana 拉模式，日志用 ELK 推模式。简单粗暴，够用。
- 团队 10-50 人：引入 Kafka 做传输层缓冲，存储层用 Thanos 或 VictoriaMetrics 做长期存储。
- 团队大于 50 人：考虑全链路推模式 + 拉模式混合，引入 OpenTelemetry 统一数据格式，存储层做多级冷热分离。
小技巧：不管选哪种模式，数据采样一定要做。全量采集在规模大了以后成本极高。我一般对指标做 10s 粒度的全量采集，对日志做 1% 的采样，对调用链做 10% 的采样。够用，且省钱。
最后说一句：架构没有银弹。拉模式简单可靠，推模式灵活可控。关键是你得清楚自己的场景，然后把每一层的数据流都画出来，标清楚监控点。这样排错的时候，你才能像看地图一样，一眼找到问题在哪。