Root Cause Analysis（RCA）里的 root 是“故障根因”，不是 Linux 超级用户，更不是 Android Root。Coroot、PyRCA、OpenTelemetry 等工具分析服务行为，不会解锁 Bootloader。本篇只用合成数据完成一次纸面事故分析，不连接生产环境，也不让 AI 自动改配置。
你会完成什么#
- 把用户症状、触发事件、根因和促成因素分开写。
- 用 metrics、logs、traces 和 deploy events 建立同一时间窗。
- 为两个候选假设写可证伪预测，而不是先选结论再找截图。
- 通过时间顺序、传播路径和回滚后恢复排除错误假设。
- 产出一份不含个人归责、能被同事复核的最小 RCA。
先看结论#
| 证据 | 能回答 | 不能单独证明 |
|---|---|---|
| Metrics | 何时、多少、趋势与范围 | 哪一个请求路径先失败 |
| Logs | 某组件报告了什么事件/错误 | 最后报错的组件就是根因 |
| Traces | 单次请求跨服务耗时与传播 | 所有用户都受同样影响 |
| Deploy events | 哪个版本何时变化 | 部署与故障相关就一定因果 |
| AI/RCA 推荐 | 候选组件与关联线索 | 自动得到真实根因或安全修复 |
心智模型#
10:00 deploy catalog v42
↓（先发生）
10:02 database query p95 ↑ → 10:03 catalog spans ↑ → 10:04 gateway timeout ↑
↓ ↓
假设 A：新查询缺索引 用户症状：结账失败
10:12 rollback v41 → 10:14 全链恢复（支持 A，但仍需复现/查询计划验证）工具清单#
| 工具/信号 | 角色 | 什么时候用 | 来源与注意 |
|---|---|---|---|
| OpenTelemetry | 统一生成/传输 traces、metrics、logs | 建立跨服务关联 ID 与时间线 | 遥测可能含 token/用户数据，先做采集治理 |
| Prometheus | 查询时间序列与规则 | 量化错误率、延迟、饱和度 | 标签基数和窗口选择会扭曲判断 |
| Alertmanager | 聚合、抑制并通知告警 | 控制告警噪声与路由 | silence 不是修复，结束时间要明确 |
| Grafana Explore | 并排探索不同信号 | 围绕同一时间窗关联证据 | dashboard 截图不是原始证据的替代品 |
| Coroot | 拓扑与多信号 RCA 辅助 | 已合法部署且数据范围明确时 | AI 结论是候选假设，不是最终裁决 |
| PyRCA | 算法/研究型 RCA | 有清洗数据和评估基线时 | 相关图依赖假设，不能替代系统知识 |
项目全景：可观测性与 DevOps的 17 个项目，一个不漏#
17 个项目可串成“采集信号—发现异常—定位根因—人工处置”的观测闭环，同时单列 Android 性能、安全与网络监控工具。
| 技术路线 | 项目数 | 处理等级 | 在主题任务中的位置 |
|---|---|---|---|
| Android 性能、安全与网络观测 | 5 | 候选路线 | 按无 Root 通知监听、Root 内核防护、局域网控制、卡顿诊断和 tombed 监控区分权限需求，并先用测试设备验证数据范围。 |
| 全栈 APM、遥测与时序平台 | 4 | 候选路线 | 比较指标、日志、追踪、连续剖析、SLO 与拓扑如何关联成证据链，避免仅凭单一异常图表下结论。 |
| AI 诊断 Agent 与 ChatOps | 2 | 候选路线 | 把自然语言调查作为只读辅助：限制凭据、记录查询、链接证据，并让人工批准任何修复。 |
| 异常检测、RCA 算法与基准 | 4 | 候选路线 | 用业务指标分析、RCAEval 与确定性机器人运行时讲数据集、基准指标和可重复实验，区分相关性与因果性。 |
| 主机监控与硬件诊断 | 2 | 候选路线 | 以 monitoring.sh、xtop 和 GPU-T 建立先只读采样、再定位资源瓶颈的流程，并说明“无需 root”工具能看到的边界。 |
1. Android 性能、安全与网络观测 · 5#
按无 Root 通知监听、Root 内核防护、局域网控制、卡顿诊断和 tombed 监控区分权限需求，并先用测试设备验证数据范围。
本组共 5 项：5 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。
| 项目 | 上游定位与识别信号 | 状态与采用前检查 |
|---|---|---|
| yqs112358/TombedMonitor | 主题用途：将 yqs112358/TombedMonitor 纳入「Android 性能、安全与网络观测」候选路线，根据 Java 核对功能、平台与版本适配。 上游自述（保留原文）：An Android tool to help monitoring tombed processes and apps (root permission needed) | 未归档源项目 · ★ 49 · 协议未声明 · 2023-08-25。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
| ImKKingshuk/RootShield | 主题用途：将 ImKKingshuk/RootShield 纳入「Android 性能、安全与网络观测」候选路线，根据 android-kernel · android-kernel-kitchen · android-kernel-patching · C 核对功能、平台与版本适配。 上游自述（保留原文）：RootShield : The Ultimate Shield for Rooted Android Devices - Protect your rooted Android device from unauthorized file operations and process executions! 🛡️ RootShield is a powerful kernel module that ensures your device remains secure by monitoring and preventing risky activities. RootShield is your device’s ultimate defense mechanism. 🛠️🔥 | 未归档源项目 · ★ 25 · GPL-3.0 · 2025-12-08。边界命中：先读 README，确认它确实属于当前任务，再决定是否使用。 |
| yeyu-lab/PerfettoKit | 主题用途：将 yeyu-lab/PerfettoKit 纳入「Android 性能、安全与网络观测」候选路线，根据 ai-agent · ai-model · android · Kotlin 核对功能、平台与版本适配。 上游自述（保留原文）：🧠 AI-Powered Android performance detection & root-cause analysis SDK — pinpoint jank with multi-dimensional data, then let LLM generate fix suggestions with code examples. Supports GPT / Ollama / DeepSeek. | 未归档源项目 · ★ 9 · Apache-2.0 · 2026-06-26。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
| VishaL6i9/HarpyAndroid | 主题用途：将 VishaL6i9/HarpyAndroid 纳入「Android 性能、安全与网络观测」候选路线，根据 android · android-app · arp-spoofing · Kotlin 核对功能、平台与版本适配。 上游自述（保留原文）：HarpyAndroid - Network monitoring and control app for rooted Android devices. Discover devices, block/unblock network access, DNS/DHCP spoofing. Built with Kotlin & Jetpack Compose. | 未归档源项目 · ★ 6 · 协议未声明 · 2026-07-08。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
| GeiserX/CashPilot-android | 主题用途：将 GeiserX/CashPilot-android 纳入「Android 性能、安全与网络观测」候选路线，根据 android · android-agent · app-monitor · Kotlin 核对功能、平台与版本适配。 上游自述（保留原文）：Android monitoring agent for CashPilot — tracks passive income apps (Honeygain, EarnApp, Grass, etc.) without root via NotificationListenerService | 未归档源项目 · ★ 5 · GPL-3.0 · 2026-07-20。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
2. 全栈 APM、遥测与时序平台 · 4#
比较指标、日志、追踪、连续剖析、SLO 与拓扑如何关联成证据链，避免仅凭单一异常图表下结论。
本组共 4 项：4 个源项目、0 个 Fork，其中 1 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。
| 项目 | 上游定位与识别信号 | 状态与采用前检查 |
|---|---|---|
| coroot/coroot | 主题用途：将 coroot/coroot 纳入「全栈 APM、遥测与时序平台」候选路线，根据 ai · alerting · apm · Go 核对功能、平台与版本适配。 上游自述（保留原文）：Coroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections. | 未归档源项目 · ★ 7839 · Apache-2.0 · 2026-07-02。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
| databufflabs/databuff | 主题用途：将 databufflabs/databuff 纳入「全栈 APM、遥测与时序平台」候选路线，根据 ai · ai-native · aiops · Java 核对功能、平台与版本适配。 上游自述（保留原文）：AI-native OpenTelemetry APM with multi-agent root-cause analysis across traces, metrics, and service topology | 未归档源项目 · ★ 334 · AGPL-3.0 · 2026-07-20。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
| startreedata/thirdeye | 主题用途：将 startreedata/thirdeye 纳入「全栈 APM、遥测与时序平台」候选路线，根据 anomaly-detection · pinot · rootcauseanalysis · TypeScript 核对功能、平台与版本适配。 上游自述（保留原文）：ThirdEye is an integrated tool for realtime monitoring of time series and interactive root-cause analysis. | 未归档源项目 · ★ 121 · NOASSERTION · 2026-04-16。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
| project-thirdeye/thirdeye | 主题用途：将 project-thirdeye/thirdeye 纳入「全栈 APM、遥测与时序平台」候选路线，根据 Java 核对功能、平台与版本适配。 上游自述（保留原文）：ThirdEye is an integrated tool for realtime monitoring of time series and interactive root-cause analysis. It enables anyone inside an organization to collaborate on effective identification and analysis of deviations in business and system metrics. ThirdEye supports the entire workflow from anomaly detection, over root-cause analysis, to issue resolution and post-mortem reporting. | 已归档源项目 · ★ 97 · Apache-2.0 · 2022-10-17。已归档：保留作历史、迁移或兼容性参考，不作为默认安装源。 |
3. AI 诊断 Agent 与 ChatOps · 2#
把自然语言调查作为只读辅助：限制凭据、记录查询、链接证据，并让人工批准任何修复。
本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。
| 项目 | 上游定位与识别信号 | 状态与采用前检查 |
|---|---|---|
| ongridio/ongrid | 主题用途：将 ongridio/ongrid 纳入「AI 诊断 Agent 与 ChatOps」候选路线，根据 ai-agents · aiops · alerting · Go 核对功能、平台与版本适配。 上游自述（保留原文）：An ops AI Agent that understands your infrastructure, finds the root cause, and fixes it — right from Slack, Telegram, Lark or DingTalk. | 未归档源项目 · ★ 497 · AGPL-3.0 · 2026-07-17。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
| cprobe/catpaw | 主题用途：将 cprobe/catpaw 纳入「AI 诊断 Agent 与 ChatOps」候选路线，根据 Go 核对功能、平台与版本适配。 上游自述（保留原文）：A lightweight monitoring agent that detects anomalies, auto-diagnoses root causes with AI, and lets you troubleshoot interactively via chat | 未归档源项目 · ★ 249 · AGPL-3.0 · 2026-04-08。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
4. 异常检测、RCA 算法与基准 · 4#
用业务指标分析、RCAEval 与确定性机器人运行时讲数据集、基准指标和可重复实验，区分相关性与因果性。
本组共 4 项：4 个源项目、0 个 Fork，其中 1 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。
| 项目 | 上游定位与识别信号 | 状态与采用前检查 |
|---|---|---|
| chaos-genius/chaos_genius | 主题用途：将 chaos-genius/chaos_genius 纳入「异常检测、RCA 算法与基准」候选路线，根据 ai · alert · alert-messages · Python 核对功能、平台与版本适配。 上游自述（保留原文）：ML powered analytics engine for outlier detection and root cause analysis. | 已归档源项目 · ★ 778 · MIT · 2024-09-12。已归档：保留作历史、迁移或兼容性参考，不作为默认安装源。 |
| phamquiluan/RCAEval | 主题用途：将 phamquiluan/RCAEval 纳入「异常检测、RCA 算法与基准」候选路线，根据 aiops · benchmark · itbench · Jupyter Notebook 核对功能、平台与版本适配。 上游自述（保留原文）：(FSE'26, WWW'25, ASE'24) RCAEval: A Benchmark for Root Cause Analysis. | 未归档源项目 · ★ 176 · MIT · 2026-06-10。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
| ftahirops/xtop | 主题用途：将 ftahirops/xtop 纳入「异常检测、RCA 算法与基准」候选路线，根据 Go 核对功能、平台与版本适配。 上游自述（保留原文）：xtop — modern replacement for top/htop with root-cause analysis and eBPF insights. | 未归档源项目 · ★ 41 · Apache-2.0 · 2026-07-14。边界命中：先读 README，确认它确实属于当前任务，再决定是否使用。 |
| xronos-inc/xronos | 主题用途：将 xronos-inc/xronos 纳入「异常检测、RCA 算法与基准」候选路线，根据 concurrency · determinism · observability · C++ 核对功能、平台与版本适配。 上游自述（保留原文）：Xronos revolutionizes robotics software — enabling reproducible behavior, timing control, and rapid root cause analysis through built-in observability. | 未归档源项目 · ★ 35 · BSD-3-Clause · 2026-06-26。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
5. 主机监控与硬件诊断 · 2#
以 monitoring.sh、xtop 和 GPU-T 建立先只读采样、再定位资源瓶颈的流程，并说明“无需 root”工具能看到的边界。
本组共 2 项：2 个源项目、0 个 Fork，其中 0 项已归档。新手应先从“未归档的源项目”核对 README 和 Release，再用 Fork 追溯设备适配或历史差异；分组本身不等于推荐安装。
| 项目 | 上游定位与识别信号 | 状态与采用前检查 |
|---|---|---|
| lseurttyuu/GPU-T | 主题用途：将 lseurttyuu/GPU-T 纳入「主机监控与硬件诊断」候选路线，根据 amd · amdgpu · appimage · C# 核对功能、平台与版本适配。 上游自述（保留原文）：A GPU-Z inspired diagnostic tool for Linux. GPU-T provides detailed hardware specs, real-time sensors, and advanced diagnostics for AMD and NVIDIA GPUs (Intel support planned). Built with .NET & Avalonia UI. Features hardware lookup, sensor logging, and ReBAR detection. Shipped as a self-contained AppImage. No root required. | 未归档源项目 · ★ 306 · MIT · 2026-07-14。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
| HEADLIGHTER/Born2BeRoot-42 | 主题用途：将 HEADLIGHTER/Born2BeRoot-42 纳入「主机监控与硬件诊断」候选路线，根据 21born2code · 21school · 42born2code · Shell 核对功能、平台与版本适配。 上游自述（保留原文）：monitoring.sh script, walk through installation and setting up, evaluation Q&A | 未归档源项目 · ★ 85 · 协议未声明 · 2023-05-21。活跃候选：先核对 README、最新 Release、目标版本与已知问题。 |
开始前#
创建一个本地 Markdown 文档，写下合成服务：gateway → catalog → database。设定影响为“10:03–10:14，20% 合成结账请求超时”。使用本篇时间线，不接触真实日志。所有时刻假定同一 UTC 时区。先定义正常基线：gateway 错误率小于 1%，catalog p95 80 ms，database query p95 30 ms。
操作步骤#
1. 把事实按同一时间轴排好#
在文档建表：10:00 deploy catalog v42；10:02 database query p95 从 30 ms 到 900 ms；10:03 catalog trace 的 DB span 变长；10:04 gateway timeout 增加；10:07 catalog 日志出现 query deadline；10:12 回滚 v41；10:14 所有指标恢复。把“观察事实”与“解释”分列，不能把“bad deploy”直接写进事实列。
2. 写两个可被推翻的假设#
假设 A：v42 新查询缺索引，预测 DB span 先变慢、只影响调用该查询的路径、回滚后恢复。假设 B：gateway CPU 饱和，预测 gateway CPU 在最早时刻升高、多个无关路由同时变慢、下游 DB 并非先变。为每个预测标出需要的 metric、trace 或 log，而不是用同一错误计数重复证明。
3. 用传播顺序排除一个假设#
给定额外事实：gateway CPU 一直 35%，无关 /health 与 /profile 路由正常；受影响 trace 的 catalog DB span 占总耗时 92%。这些证据反驳假设 B，并与 A 一致。仍然把“v42 新查询缺索引”写成高置信候选；真正确认还需在隔离副本比较 query plan 或复现，而不是让 AI 替你补证据。
4. 写修复、回滚与验证条件#
即时缓解是回滚 v42，已由 10:14 恢复支持。永久修复计划写为：在测试数据副本上获得 query plan、设计/评审索引或查询改写、负载测试、金丝雀部署，并以 DB p95、gateway 错误率和受影响 trace 三项同时回归为成功。回滚触发条件是任一指标超过预设阈值。完成后删除只含合成数据的草稿或保留为模板；没有生产状态需要回滚。
验证#
- RCA 先写用户影响和时间窗，再写技术结论。
- 每条结论至少引用一种明确证据，且时间顺序合理。
- 被排除的 gateway 假设有反证，不是简单删掉。
- 根因、促成因素、症状和缓解措施分别列出。
- 永久修复包含测试、上线观察指标与触发回滚的阈值。
排错#
| 现象 | 常见原因 | 安全处理 |
|---|---|---|
| 日志先看到 gateway timeout | 上游最接近用户，最先被注意但未必最先发生 | 回到 trace span 和下游时间序列看传播顺序 |
| 不同图时间对不上 | UTC/本地时区或采样窗口不同 | 统一时区与查询区间，记录数据延迟 |
| 回滚后恢复就宣布已证明 | 同时存在流量变化或依赖恢复 | 增加复现、query plan 或反事实证据 |
| AI 给出唯一根因 | 模型把关联排序包装成确定性 | 要求证据引用，并保留至少一个替代假设 |
| 自动化建议直接扩容 | 症状缓解掩盖查询缺陷 | 先审批、限定范围，并写明回滚与成本阈值 |
完成清单#
- 我能解释 RCA 中的 root 与 Android Root 无关。
- 我把所有证据放进同一时区和影响窗口。
- 我写了两个可证伪假设，并用独立证据排除一个。
- 我没有使用真实用户数据或让工具自动改生产。
- 我为永久修复定义了成功指标和回滚阈值。