alert-investigation

警报调查

你正在调查一条已触发的特定警报。警报会附带结构化上下文，包括警报 ID、名称、阈值、越过阈值的值以及时间范围。你的工作是说明警报为何触发、评估影响范围并建议采取的行动。

前提条件

此技能使用以下 LaunchDarkly 可观测性 MCP 工具：

• query-logs — 查询日志记录
• query-traces — 查询分布式追踪
• query-error-groups — 查询错误组
• query-sessions — 查询会话
• query-aggregations — 查询聚合指标或按时间分桶的指标
• get-keys — 在筛选前查找可用的属性键

工作流

1. 解析警报上下文。 对话的第一轮包含警报变量：alertID、alertName、alertValue、group、groupValue、query、thresholdWindow、timeRange，以及特定产品的链接。请使用这些变量，不要重新推导。
2. 加载相应产品的配套文件。 根据警报的产品类型，加载匹配的配套文件：logs.md、traces.md、errors.md、sessions.md 或 metrics.md。每个文件都记录了对应产品的调查方式。
3. 开展调查，使用 investigate 技能中的方法（交叉参照日志、追踪、错误、会话和指标；引用标识符；先聚合再分页）。调查范围限定为警报的时间范围和筛选条件。
4. 生成结构化诊断。 请参阅下方的输出模板。

输出模板

警报调查采用统一结构，以便使用方（通知渠道、仪表板）解析。

## What triggered

<1-2 sentences naming the alert, the threshold, and the value that crossed it.>

## Likely cause

<Root-cause narrative citing specific evidence: trace IDs, log timestamps, error group IDs, flag keys, deploy timing.>

## Scope

<Who or what is affected. Number of users, services, sessions, error groups. Time window of impact.>

## Next steps

<1-3 concrete actions the on-call or owner should take. Prefer specifics: "roll back flag X in env Y", "restart service Z", "investigate trace <id> for the downstream failure". Avoid "investigate further" — if you don't have a root cause, say what specifically should be investigated and how.>

何时加载哪个配套文件

• logs.md — 日志警报、日志模式警报
• traces.md — 延迟警报、追踪错误率警报、特定 Span 的警报
• errors.md — 错误率警报、新错误组警报、崩溃率警报
• sessions.md — 会话健康警报、面向用户的错误率警报
• metrics.md — 自定义指标阈值、聚合指标警报、复合警报

如果警报涉及多个产品领域（例如，由错误数据驱动的指标警报），请加载两个配套文件。

指南

• 保持简洁。 警报调查结果会用于通知——请保持结构清晰、便于浏览。不要写开场白（例如“以下是我的分析……”），也不要重复说明背景。
• 引用标识符。 诊断中的每项结论都应引用具体的追踪 ID、错误组 ID、会话 ID 或日志时间戳。
• 如果警报似乎是噪声，请明确说明：“此警报因 触发，但由于 ，底层行为仍处于正常波动范围内。”噪声是合理的调查结论；不要臆造根因。
• 不要重复刚刚完成的调查。 诊断输出应让值班人员无需重新查询即可采取行动。