1. Crash监控平台整体架构
Crash 监控平台是整个稳定性体系的“侦察兵”与“指挥中心”。一个生产级平台必须覆盖从崩溃事件发生到研发人员定位问题的全链路，按数据流向可抽象为六大核心层次。本章从原理出发，拆解每一层的职责、典型实现方案及其在工程落地中的关键决策点。
架构目标：端到端延迟 < 5 秒（实时告警）；单日百亿级事件处理能力；数据零丢失（Exactly-Once 语义）。
1.1 六层架构总览
下图为 Crash 监控平台完整数据流，箭头方向表示事件从产生到消费的传递路径：
1.2 各层职责与实现要点
| 层次 | 核心职责 | 典型选型/方案 | 关键指标 |
|---|---|---|---|
| 采集层 | 在应用端捕获崩溃信号，收集堆栈、上下文、设备信息 | Breakpad / libunwind / PLCrashReporter | 捕获率 > 99.5%；Payload 大小 < 64KB |
| 传输层 | 可靠上传、流量控制、压缩、断点续传 | gRPC Stream / Kafka 异步生产 / MQTT | P99 延迟 < 3s；压缩率 > 5:1 |
| 存储层 | 原始数据持久化、元数据索引、过期清理 | HDFS Parquet / ClickHouse MergeTree | 写入吞吐 > 50W eps；磁盘压缩比 4:1 |
| 分析层 | 聚合计算、错误栈归一化、符号化、趋势检测 | Spark Structured Streaming / Flink SQL | 符号化成功率 > 97%；聚合窗口 1min |
| 告警层 | 基于规则触发告警，分级通知（IM/邮件/电话） | AlertManager + Webhook / 自研规则引擎 | 告警准确率 > 95%；误报率 < 5% |
| 可视化层 | 实时看板、趋势图、钻取分析、版本对比 | Grafana + ClickHouse DS / 自研图表 | P95 图表加载 < 2s; 钻取深度 ≥ 3 级 |
1.3 数据流与缓冲机制
为防止上游抖动直接影响下游，每一层之间都引入了缓冲或队列：
- SDK 本地 Spool：崩溃事件先在 app 沙盒写文件，再异步上传；默认保留 3 次重试。
- 传输层磁盘队列：代理进程将待发送请求写入本地 RocksDB，网络恢复后自动消费。
- 存储层写入 Buffer：ClickHouse 使用异步插入（async_insert=1），合并小文件后落盘。
常见错误：采集层直接调用网络接口而不写本地副本，一旦网络断开或闪退，崩溃事件永久丢失。务必在 SDK 中实现“先写磁盘，后发网络”的 Spool 模式。
1.4 性能与稳定性基线
以下是生产环境部署时必须满足的最低要求，任何低于此阈值的设计应视为缺陷：
- 采集层 CPU 占用：符号化前的堆栈解析 < 5ms/次；Hook 注册后 app 帧率下降 < 3%
- 传输层内存占用：单进程常驻内存 < 50MB；缓冲区上限 < 200MB
- 存储层查询 RT：针对 7 天 10 亿事件的聚合查询 < 3s
- 分析层背压：消息积压超过 100 万条时自动扩容 Partition 或并行度
1.5 选型对比：自建 vs 商业化方案
| 维度 | 自建 Crash 平台 | 商业化方案（Sentry / Firebase） |
|---|---|---|
| 数据主权 | 完全可控，可定制索引和字段 | 数据留在第三方，合规风险高 |
| 成本模型 | 固定基础设施成本，事件量越大越划算 | 按事件数计费，亿级事件月费 > 10 万美元 |
| 符号化效率 | 自建符号表管理，可做增量+并行化 | 受限于第三方 API 速率限制 |
| 告警灵活性 | 支持任意 SQL + 自定义通知渠道 | 仅支持预设规则，渠道有限 |
| 集群运维 | 需专职 SRE，引入 Kafka/ClickHouse 运维 | 零运维，但 Vendor Lock-in 严重 |