WebhookWise

English · 中文

WebhookWise 站在你的监控系统和聊天工具之间。它把 Prometheus、Grafana、 Alertmanager、飞书、或任何能 POST JSON 的东西归一化,逐条判断,决定告诉谁 —— 并记录为什么,所以「我怎么没被叫到」有一个不靠猜的答案。

自托管、MIT、一条 docker compose up。→ github.com/itswl/WebhookWise

总览:一屏看健康度

每个告警工具都说自己降噪。这个能拿出证据说明降没降。

一个 agent 化的调查员会去读那些值得读的告警 —— 检索、关联、推理数分钟 —— 然后给出一份带自己判定的严重度报告。这就构成了一份没人标注过的标注集,而第一次拿它打分,结果并不好看:


WebhookWise 判为 `high` 的告警	一周 330 / 367(90%)
其中被真正调查过、调查员也认同的	21 / 80(26%)

high 已经退化成「有条告警」的意思。于是闭环形成:校准脚本按告警规则给廉价判定打分并提出上限建议,由人决定是否采纳;结果每周 59% 的告警量不再是 high。

护栏比机制更重要 —— 如果调查员有超过三分之一的次数说它确实是 high,脚本就拒绝建议降级,因为那种噪音必须靠把告警做得更具体来解决,而不是靠静音。

这就是整个项目的形状:一个决定、一份「为什么」的记录、以及一条事后发现这个决定错了的路径。

决策链:每一次「拦下」都有答案

八道闸门站在告警和人之间 —— 去重、静默、维护窗、风暴抑制、冷却、预算 —— 而每一次「拦下」都有记录,所以一条静默规则可以被打分,而不是被信任。降噪中心把这些记录读回来算成每条规则的 ROI:拦了多少、省了多少分钟、哪条是僵尸规则(90 天零匹配)。新规则上线前先对历史数据回测。

廉价通道才是默认路径,AI 是那少数昂贵告警自己挣来的。

降噪中心:每条静默规则都有 ROI

读侧通过 MCP 暴露 —— 20 个工具、一份使用指南资源和调查提示词 —— 任何 MCP 客户端都能直接查询这个部署:

claude mcp add --transport http webhookwise \
  https://<your-host>/mcp/ \
  --header "Authorization: Bearer <API_KEY>"

接上之后可以直接问「为什么 #923 没通知我?」、「这个班发生了什么?」、 「哪些规则可以删了?」。仓库里带了四个现成技能:单条告警全链路调查、交接班简报、降噪审计、可观测性排查。

刻意只读 —— Agent 在这里调用的任何东西都不会改变这个部署的行为。唯一的写只是记录一条待批提案,必须由持有写凭据的人批准。

事故列表:相关告警自动聚合


WebhookWise Lite	单容器、SQLite、无 Redis、约 800 行、四道抑制闸门。先感受一下再决定要不要上全量版。
全量版	FastAPI + TaskIQ + PostgreSQL + Redis,全程 OpenTelemetry。`docker compose up -d`。

刻意不做:值班表和状态页。那是 Grafana OnCall 和状态页服务的地盘,把告警的「守门人」这一件事做好就够了。

内置教程页:一条告警的旅程