asmnesar/incident-response-toolkit

# sredoctor 一个基于插件的 CLI 工具，可针对主机或服务运行一系列只读诊断检查，并打印出结构化的分诊报告——这正是你在发生故障时，希望在第二个终端中打开的工具，而不是在压力下凭记忆重新输入那七个相同的 `systemctl`/`df`/`curl` 命令。 它与 Loki/Promtail 日志聚合栈、Prometheus 告警规则、模拟正常运行时间检查器以及一组 `sredoctor` 直接从其输出中链接到的 runbook 配合使用。 ## 为什么选择 CLI 而不仅仅是仪表盘 当你需要的服务已经配置好监控，且仪表盘也已经存在时，仪表盘是非常好用的。但导致故障的往往正是那些*尚未*纳入仪表盘监控的事物——一个新的依赖项、一台从未完全接入监控的主机、或是一个临时批处理作业。`sredoctor` 旨在零配置的情况下随处可用：通过 SSH 登录，运行一条命令，即可获得关于磁盘/内存/网络/服务健康状况的结构化状态读取，而无需专门为该特定机器预先搭建任何监控栈。 ## 架构：将检查作为插件 每项检查都是实现 `run() -> CheckResult` 接口的小类（参见 `sredoctor/checks/base.py`）。CLI 通过扫描 `sredoctor/checks/` 目录来发现检查项，而不是逐个按名称导入它们——添加新检查只需在该目录中放入一个文件，而无需编辑中央注册表，从而避免了与其他人并行提交的 PR 中的检查项发生合并冲突的风险。 ``` $ sredoctor diagnose --host prod-api-03 [PASS] disk_space / at 41% (ok) [PASS] disk_space /var/log at 58% (ok) [FAIL] service_health nginx: inactive (dead) -> runbook: runbooks/service-down.md [WARN] network_latency p99 to db-primary: 340ms (baseline: 12ms) -> runbook: runbooks/db-latency.md [PASS] certificate_expiry api.example.com: 47 days remaining 2 issues found (1 failure, 1 warning). Full report: /tmp/sredoctor-report-20260727-1142.json ``` ## 棘手之处 某些检查（网络延迟、服务健康状况）需要一个基准来进行对比，否则 WARN 和 FAIL 阈值就毫无意义——根据该链路通常的实际情况，“340ms”既可能是灾难性的，也可能是完全正常的。`sredoctor/checks/network_latency.py` 会从其按主机维护的本地 sqlite 缓存（`~/.sredoctor/history.db`）中读取最近的历史记录，而不是硬编码一个阈值。这样一来，在特定主机上的第二次及后续运行才具有实际意义。而在全新主机上的首次运行会回退到通用的默认值，并记录一条提示，表明基准仍在预热中。 ## 仓库布局 ``` sredoctor/ cli.py Entry point, argument parsing, report formatting checks/ base.py CheckResult + Check interface disk_space.py service_health.py network_latency.py baseline-aware, sqlite history cache certificate_expiry.py tests/ runbooks/ Markdown runbooks that check output links to directly monitoring/loki/ Promtail + Loki config for centralized log aggregation monitoring/alerts/ Prometheus alerting rules synthetic/ Standalone synthetic uptime/latency checker + cron setup ``` ## 安装 / 运行 ``` pip install -e . sredoctor diagnose # run all checks against localhost sredoctor diagnose --host prod-api-03 # via SSH sredoctor diagnose --check disk_space # run a single check ``` ## 局限性 - 检查是按顺序运行的，而非并行——对于约 6 个内置检查项来说这没问题，但如果后续扩展到几十个，就需要引入工作池（worker pool）了。 - sqlite 基准缓存是按运行 sredoctor 的单台机器划分的，无法在团队间共享。后续的改进方向是将基准数据推送到共享存储（哪怕只是 S3），这样每个人的 `sredoctor` 就都能受益于相同的历史记录了。

标签：故障诊断, 日志聚合, 自定义请求头, 运维工具, 逆向工具