中间件体系（Middleware Platform）
目标：为业务系统提供统一、稳定、高可用、可治理的基础运行能力
P0（运行基础）
├── 网关（Kong / APISIX）
├── 配置中心（Nacos）
├── RPC 平台（Dubbo）
├── 数据存储（MySQL / PostgreSQL / Mongo）
P1（解耦与性能）
├── MQ（Kafka / RabbitMQ）
├── 缓存平台（Redis / Memcached）
├── 搜索（Elasticsearch）
├── 文件存储（MinIO）
P2（治理与稳定）
├── 缓存失效监控 & 一致性
├── 任务调度（Airflow / XXLJob）
├── 中间件监控与告警
P3（平台化）
├── 中间件统一管控台
├── 多租户 / 资源隔离
├── 成本 & 容量管理
中间件体系的本质不是“技术选型”，而是“运行能力抽象”：
企业级中间件平台与可观测性体系（Observability Platform）
下面我将从企业级中间件平台与可观测性体系（Observability Platform）的视角，系统性、工程化、可落地地详细展开 中间件监控与告警。这不是“装个 Prometheus + 配个告警”，而是如何把中间件的“不可见风险”变成“可运营信号”。
一、先给总论（非常重要）
中间件监控的目标不是“看指标”， 而是：提前感知退化、快速定位根因、避免业务事故。
因此，中间件监控与告警必须做到三件事：
- 指标可解释
- 告警可行动
- 问题可追溯
二、中间件监控的对象全景
中间件不是一个东西，而是一组“系统能力”。
2.1 中间件类型
| 类别 | 典型 |
|---|---|
| 接入 | 网关 / LB |
| 通信 | RPC / MQ |
| 数据 | DB / Cache / Search |
| 配置 | Config Center |
| 任务 | Scheduler |
| 存储 | Object / File |
| 协调 | ZK / ETCD |
2.2 监控的三个层次（必须区分）
| 层次 | 关注点 |
|---|---|
| 组件层 | 自身健康 |
| 平台层 | 资源与容量 |
| 业务层 | 对业务的影响 |
三、核心监控指标模型（黄金法则）
3.1 RED / USE / 四个黄金信号
RED（服务视角）
- Rate（QPS）
- Errors（错误率）
- Duration（延迟）
USE（资源视角）
- CPU
- Memory
- Disk
- Network
四个黄金信号（Google SRE）
- Latency
- Traffic
- Errors
- Saturation
四、各类中间件的关键监控指标（重点）
4.1 网关 / API Gateway
| 指标 | 意义 |
|---|---|
| QPS | 流量 |
| 4xx / 5xx | 错误 |
| P99 RT | 延迟 |
| 限流次数 | 保护触发 |
4.2 RPC / Service Mesh
| 指标 | 意义 |
|---|---|
| 调用成功率 | 稳定性 |
| 重试次数 | 退化信号 |
| 熔断次数 | 故障 |
| P99 | 尾延迟 |
4.3 MQ
| 指标 | 意义 |
|---|---|
| Lag | 消费积压 |
| TPS | 吞吐 |
| Rebalance | 稳定性 |
| DLQ | 异常 |
4.4 Cache（Redis）
| 指标 | 意义 |
|---|---|
| Hit Rate | 缓存价值 |
| Evicted Keys | 风险 |
| Used Memory | 饱和 |
| Slowlog | 性能 |
4.5 Search / ES
| 指标 | 意义 |
|---|---|
| Query RT | 查询性能 |
| CPU / Heap | GC 风险 |
| Shard 状态 | 可用性 |
| Rejected | 压力 |
4.6 配置中心
| 指标 | 意义 |
|---|---|
| 推送延迟 | 一致性 |
| 失败率 | 风险 |
| 客户端数 | 规模 |
4.7 调度平台
| 指标 | 意义 |
|---|---|
| 失败率 | 可靠性 |
| 延迟 | 调度能力 |
| 重试 | 稳定性 |
| Worker 心跳 | 健康 |
五、告警设计（比监控更重要）
90% 的监控失败，败在告警设计。
5.1 告警必须“可行动”
❌ 坏告警
CPU > 80%
✅ 好告警
Redis CPU > 80% 持续 5 分钟
+ Evicted Keys > 0
+ Hit Rate < 90%
5.2 多指标组合告警（关键）
单指标 ≠ 事故
Errors ↑ + Latency ↑ + Saturation ↑
5.3 告警分级（企业级）
| 级别 | 含义 |
|---|---|
| P1 | 已影响业务 |
| P2 | 高风险 |
| P3 | 预警 |
| P4 | 信息 |
六、告警风暴与治理
6.1 告警去重 / 收敛
- 同一资源
- 同一根因
- 同一时间窗口
6.2 告警抑制
- 变更窗口
- 已知故障
6.3 告警升级策略
5 分钟未 ACK → 升级
七、可观测性融合（Logs / Metrics / Traces）
中间件监控必须与 Trace 结合，否则定位慢。
7.1 指标 → Trace → 日志
告警 → 找异常 Trace → 看中间件日志
7.2 关键 Trace 注入点
- MQ 生产 / 消费
- RPC 调用
- Cache 命中 / miss
- DB 查询
八、平台化架构设计
Observability Platform
├── Metrics（Prometheus）
├── Logs（Loki / ES）
├── Traces（Jaeger）
├── Alert Manager
├── 事件中心
├── Runbook
└── SLO / Error Budget
九、SLO & Error Budget（进阶）
从“报警驱动”走向“目标驱动”。
- 定义 SLI（成功率 / 延迟）
- 计算 Error Budget
- 预算用完 → 冻结发布
十、反模式（非常重要）
- ❌ 指标多但没人看
- ❌ 告警噪音过大
- ❌ 中间件与业务割裂
- ❌ 无 Runbook
十一、落地 Checklist（可直接用）
监控
- 每个中间件 RED 指标
- 资源 USE 指标
- 饱和度监控
告警
- 多指标组合
- 分级
- 有处理指引
