MCP 监控 + 日志直查

这个 pack 是什么 —— 以及不是什么

这个 pack 不是一套监控栈。你已经有一套了。Prometheus 在抓指标、Grafana 在渲图、Sentry 在聚合异常，Loki 或 SigNoz 也许在吃日志。pack 是叠在这套栈上的 agent 接入层 —— 就是那些 MCP server 和 subagent，让 Claude / Cursor / ChatGPT 或任何 MCP 客户端能直接用自然语言查 trace、日志、告警、dashboard，不需要人去点。

如果你想要底层日志流水线（winston / Fluent Bit / Loki / ClickHouse / lnav），看 log-analysis-search pack。如果你想要更广的 deploy + monitor 栈（Vercel / Uptime Kuma / OpenTelemetry Collector / Alertmanager），看 deploy-monitor-observability pack。本 pack 假设上面那些你已经有了，专门补齐 MCP 接入层，让 agent 真能用起来。

为啥这事重要：大部分团队已经在花钱（或自建）了足够多的可观测工具。他们缺的是一条 on-call 流程 —— 告警来了能自动三角化、SRE 问「02:47 改了啥」能一句话拿到答案、上线出事故时摘要在人打开 dashboard 之前就写好。MCP 接对了就是干这个的。

每一个选品都是开源、或者有可自建的开源 MCP server。有几个包的是商业后端（Datadog、Sentry SaaS、Axiom），但 MCP server 本身是你能读源码再跑的开源代码。不收黑箱 agent SDK。

推荐安装顺序

1. SigNoz MCP Server — 日志 + trace + 告警查询 MCP。从这里开始，因为 SigNoz 是少数开源后端里原生把日志/trace/指标统一进一个存储的。一旦 agent 能查 SigNoz，它就能回答「过去一小时最慢的接口」「这个错首次出现是什么时候」「现在哪些告警在烧」——不用三个工具来回跳。如果你不用 SigNoz，跳到第 2 步。
2. Axiom MCP — Log Search and Analytics for AI Agents — 云端日志搜索 MCP。当你日志在托管存储里、查询用 APL（Axiom Processing Language）而不是 LogQL 时的替代方案。和 SigNoz MCP 是同一种活，后端不同。看你日志在哪里二选一，两个都装就是浪费。
3. Grafana MCP — Dashboards, Alerts & OnCall Tools — dashboard MCP，整个 pack 的支柱。Grafana 的 MCP 把面板数据、告警规则、OnCall 排班、dashboard 搜索全暴露出来。装完之后，agent 能拉你手动打开的同一张图，读底层 PromQL/LogQL 表达式，并对它做推理。不装这个，agent 对 Grafana 渲染的一切就是瞎的。
4. Datadog MCP Server — Query Metrics and Logs from AI Agents — Datadog 用户的对应方案。和第 1+3 步合起来是一个职能，但走 Datadog 的指标/日志/APM。默认只读是底线安全姿势，开放给自主 agent 之前一定再核一遍。
5. Sentry MCP — Error Monitoring Server for AI Agents — 错误 MCP。Sentry 官方 server，能返回 issue 列表、stack trace、回归状态、release 健康度。凌晨 3 点 agent 三角化告警从这里开始 —— 「这是新错还是已知回归」是一个工具一句话就能答的问题。
6. sentry-errors — Auto-Triage Subagent for Sentry — 告警工作流 agent。这是叠在 Sentry MCP 之上的层：一个 Claude subagent，告警一响它就醒，调 Sentry MCP 拉 issue，调 SigNoz/Grafana MCP 拉上下文，写出结构化的三角化笔记。你可以自己写，但这个已经验证过；fork 就好。
7. Pup — Datadog CLI Companion for AI Agents — CLI 桥。当 agent 的 MCP toolset 表达不了某个查询（或你不信任 MCP 暴露写操作）时，Pup 给 agent 一个沙箱化的 Datadog CLI。默认只读 flag，配合 audit log。
8. langfuse-mcp — Query Langfuse Traces via MCP — LLM trace MCP。分类不同：它查的不是你应用的请求 trace，而是 Langfuse 里的 LLM trace —— prompt、response、tool call、cost。当 on-call 问题是「02:47 agent 为啥答错了」而不是「02:47 checkout 为啥炸了」时就是它。线上跑 LLM 功能的话必装。
9. Monoscope — LLM Query for Logs/Traces/Metrics — 统一自然语言查询层。架在多个后端（日志、trace、指标）前面，让 agent 或人能直接问「过去 30 分钟 checkout 模块 p99 > 500ms 的错误」——不用先决定走哪个工具。当你逐个 MCP 调嫌烦的时候上它。

流水线怎么协同

   [ 告警触发 ]
         │
         ▼
   sentry-errors subagent           ← 唤醒、编排
         │
         ├──▶ Sentry MCP             (issue、stack trace、是否回归？)
         ├──▶ SigNoz / Axiom MCP     (时间戳前后的日志)
         ├──▶ Grafana MCP            (面板状态、告警规则、OnCall 名单)
         ├──▶ Datadog MCP / Pup CLI  (Datadog 用户的指标查询)
         ├──▶ langfuse-mcp           (路径里有 AI 功能时拉 LLM trace)
         │
         ▼
   Monoscope (可选)                  ← 统一 NL 查询、fan-out
         │
         ▼
   [ 结构化三角化笔记 → 工单 / Slack / 电话 ]

形状是有讲究的：subagent 在最上面、MCP server 在中间、后端存储在最底。每个 MCP 都是薄壳，价值在组合。单调用一次 SigNoz MCP 很有意思；sentry-errors 在 4 个 MCP 上 fan-out 然后写一段话，那才是真正的解锁。

如果你从零开始：第 4 步（Datadog）和第 7 步（Pup）你不在 Datadog 就跳。第 8 步（langfuse-mcp）不跑 LLM 功能就跳。最小可用组合是 SigNoz MCP + Grafana MCP + Sentry MCP + sentry-errors subagent —— 4 个选品，agent 已经能回答凌晨 3 点的大部分问题。

你会遇到的取舍

• MCP vs 自定义 function-calling — 这里每一个 MCP server 都可以用 OpenAI function-calling 重写一遍对同一个后端 API。MCP 胜在你有不止一个 agent runtime 时（Claude Desktop、Cursor、ChatGPT 自定义 GPT、内部 agent）—— 一次写 MCP，所有客户端复用。Function-calling 胜在你只有一个定制 agent + 一个客户端。
• 只读 vs 读写 scope — 这里的每一个监控 MCP 都能配成读写（ack 告警、静默告警、改 dashboard）。on-call 三角化，只读是唯一合理默认。读写是每个 server 单独的决定，必须配 audit log，并强制走人审批。
• 开源 MCP vs 厂商 MCP — Grafana MCP 和 Sentry MCP 是 Grafana Labs / Sentry 一方维护的。SigNoz MCP 和 Axiom MCP 也是一方。Datadog MCP 和 Pup 是社区针对 Datadog API 维护的。一方更稳定；社区在边缘特性上迭代更快。部署前看一眼 maintainer。
• sentry-errors vs 自己写 subagent — sentry-errors 是一套有自己态度的三角化流程。如果你事故 playbook 不一样（你先 page 再三角化），用起来会别扭。fork 就行，价值在 fan-out 模式，不在具体那段 prompt。
• Monoscope vs 单独 MCP server — Monoscope 是统一器。你 MCP 不到 4 个之前不需要它。当 fan-out 延迟或 token 成本真的成问题时再加。

常见踩坑

• 默认暴露写权限 — 几乎所有 MCP server 文档都先举写操作示例（因为更炫）。监控/可观测 MCP 这种地方，agent 不该有静默告警、ack incident、改 dashboard 的能力，除非走一条明确的人审批通道。每个 MCP 配置必审。
• 大日志查询的 agent token 成本 — agent 问「过去 24 小时所有错误」走 SigNoz MCP 能拉几 MB 进上下文。在 MCP server 配置里设响应大小上限、超过 N 行就拒并要求 agent 加过滤条件。
• 一次 MCP 调用混查日志和指标 — agent 会尝试。大部分后端一次只回答一件事是擅长的。纪律编进 system prompt：先问 SigNoz MCP 拿 trace ID，再问 Grafana MCP 拿指标面板，不要一句问俩。
• MCP server 之间没相关性 — trace_id 是胶水。如果你的日志、trace、指标没共享 trace_id，agent 的 fan-out 拉到四件不相关的东西然后幻觉出连接。修 instrumentation 优先于修 agent。
• MCP server 和生产跑在同一台 VM — 只读 MCP 在 agent 突发使用下也占内存和 CPU。MCP 跑在独立小 VM，和可观测后端隔离，免得失控 agent 把日志存储 OOM 了。
• sentry-errors 没限流 — 告警风暴时（上线回归、基础设施事件）subagent 每条告警都醒。在告警源做去重窗口（Alertmanager / Sentry 规则），或限流 subagent 调用次数。别为同一个根因付 Anthropic API 500 张三角化笔记的钱。