我厌倦了监控盲点，于是我构建了一个用于发现它们的工具

Source: Dev.to

问题陈述

我们已经为代码质量、安全性和测试覆盖率设置了自动检查，但监控方面我们只能寄希望于它能正常工作。

去年，我值班时一个关键服务宕机。我们甚至花了很长时间才收到警报，因为本应捕获该问题的告警在三个月前的维护窗口期间被禁用了。没有人重新启用，也没有人注意到。

事后复盘时，我们在 PagerDuty 和 Datadog 的配置中发现了：

• 指向已离职人员的升级策略。
• 零告警规则（指标虽然被收集，但从未触发告警）。
• 没有任何策略引用的通知渠道。
• 仪表盘面板卡在永久的 “无数据” 状态，大家已经习惯性地忽视它们。

我们有仪表盘，有监控，有告警……但我们根本不知道自己遗漏了什么。

解决方案概览

我构建了一个工具，连接到监控栈（PagerDuty、Datadog、Grafana、Sentry、New Relic 等），执行 差距分析。它不再问 “你的服务是否在运行？” 而是问：

• 你的服务真的配置了告警吗？
• 这些告警是否路由到了有用的目的地？

系统通过各工具的 API 拉取配置，并检查：

• 没有升级策略的服务。
• 没有通知渠道的告警规则。
• 超过 30 天未收到数据的监控。
• 告警被禁用的计划搜索。

每个问题都会被分配严重程度（critical / warning / info）并生成由 AI 提供的具体修复建议。该工具还会在多个维度上为你的设置打分——告警覆盖率、通知路由、仪表盘健康——让你在单一视图中看到最大的差距。

AI 驱动的建议

AI 生成优先级 remediation 步骤，并提供一个 Incident Autopilot：当描述一个症状（例如 “checkout 变慢”）时，它会映射服务的影响范围，识别值班人员，并生成调查手册。

PR/MR 扫描器

最近的新增功能集成了 GitHub/GitLab webhook。当 PR 添加新的 API 端点或数据库连接时，扫描器会标记并建议在合并前添加相应的监控。

未决问题

• 问题是否足够痛苦？ 我接触的大多数团队都知道监控存在盲区，但他们会接入第三方工具进行审计，还是仅仅接受风险？
• 脚本 vs. 平台： 有人说 “我可以写个脚本来做这件事”。虽然为 PagerDuty 升级策略写单个脚本是可行的，但要维护 Datadog 监控、Grafana 告警规则、Sentry 项目配置等的脚本，很快就会变成维护噩梦。
• 安全顾虑： 系统需要只读 API 令牌来访问你的监控工具。令牌在静止时会被加密，且永不以明文存储，但信任屏障依然真实存在。

如果你想尝试，实时演示（无需账号）在此。点击 Enter Demo 并使用合成数据进行探索。

我很想听听大家在处理监控覆盖盲区时的经验。你们今天是怎么应对的？仅靠部落式知识和希望吗？