工具选型与对比：Crash 治理工具全景

我这几年经手的 Crash 治理项目，踩过的坑少说有几十个。最头疼的不是分析问题本身，而是选工具——选错了，后面全白干。今天我就把常用工具掰开揉碎聊聊，帮你省点试错的时间。

先看一张总览图，把主流工具按「采集→分析→聚合→告警→修复」这条链路串起来。你记住这个框架，后面选型就不会跑偏。

一、采集层工具：把 Crash 抓到手里

采集是整个链条的第一步，也是最关键的一步。数据不准，后面都是瞎忙活。

二、分析层工具：把堆栈变人话

拿到 raw stack 之后，你得把地址翻译成函数名、行号。这就是符号化（symbolication）要干的活。我遇到过一个项目，线上 Crash 堆栈全是十六进制地址……当时花了三天才搞定符号表自动匹配。

• LLDB / GDB：本地调试神器。尤其是 LLDB 的 image lookup -a 命令，能直接反解地址。但线上环境你没法 attach debugger，所以还得靠离线符号化。
• mdt (MallocDebug)：macOS/iOS 专用，配合 .dSYM 文件做符号恢复。建议写脚本批量处理。
• dmidecode / atos：Linux 和 macOS 都能用。我写过一个脚本，每天定时用 atos 把线上 Crash 地址转成行号，丢到日志平台去。

三、聚合层工具：从沙子堆里找金子

Crash 数据量一大，原始日志就跟沙子一样。你得用聚合工具把相同 Crash 归到一类——按异常类型、线程堆栈、发生模块去重。

# 一个简单的聚合脚本示例（Python）
import re

crash_db = {}
def aggregate(crash_line):
    # 提取异常类型和关键堆栈
    match = re.search(r'Exception type: (\w+).*at (.*?)(\d+)', crash_line)
    if match:
        key = f"{match.group(1)}::{match.group(2)}"
        crash_db[key] = crash_db.get(key, 0) + 1
    return crash_db

常用的聚合工具：

• Elasticsearch + Kibana：全文检索快，聚合能力强。但写查询语句得懂 ES 的 DSL，团队里得有人会。
• Grafana Loki：轻量级，兼容 Prometheus 生态。适合中小规模，但复杂聚合能力不如 ES。
• Sentry 自带聚合：对新手最友好，免去搭建 ES 的麻烦。但数据量超规模后容易贵。

四、告警层工具：别等人报，让系统叫

Crash 治理的核心指标是 MTTR（平均修复时间）。告警不及时，MTTR 就别指望好看。我司之前全靠人工盯 dashboard，有一次灰度发布后小时级崩溃率飙到 8%，凌晨 2 点才被值班发现……那以后我强制上了自动化告警。

五、选型决策十字阵

每次做选型汇报，我都会掏出这四组问题问自己，问完结论基本就定了：

1. 数据隐私等级？ —— 金融/医疗行业必须自建，选 Sentry 或 ELK；普通App可用 SaaS。
2. 团队规模与运维能力？ —— 3人小团队别碰自建ELK，老老实实用 Bugly 或 Firebase。
3. 需要哪些平台？ —— 只做 iOS？macOS 的 mdt 就够。全平台？必须统一 SDK + 符号化方案。
4. 预算多少？ —— 免费版 Bugly 足够入门；收费版 Sentry 按月付费；自建成本主要是服务器和人力。

嗯，工具选型这块，上面这些够你在大多数场景下做决定了。下一轮我们聊聊 Crash 治理的自动化流程设计——那也是我最拿手的部分之一。