alert-investigation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Alert investigation

警报调查

You are investigating a specific triggered alert. Alerts arrive with structured context — an alert ID, name, threshold, value that crossed it, and a time range. Your job is to explain why it fired, assess scope, and recommend action.

你正在调查一个特定的触发警报。警报会附带结构化上下文——警报ID、名称、阈值、触发阈值的数值以及时间范围。你的任务是解释警报触发的原因，评估影响范围，并给出行动建议。

Prerequisites

前提条件

This skill uses the following LaunchDarkly observability MCP tools:

```
query-logs
```
— query log records
```
query-traces
```
— query distributed traces
```
query-error-groups
```
— query error groups
```
query-sessions
```
— query sessions
```
query-aggregations
```
— query aggregated/time-bucketed metrics
```
get-keys
```
— discover available attribute keys before filtering

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

```
query-logs
```
— 查询日志记录
```
query-traces
```
— 查询分布式链路追踪数据
```
query-error-groups
```
— 查询错误组
```
query-sessions
```
— 查询会话数据
```
query-aggregations
```
— 查询聚合/时间桶化指标
```
get-keys
```
— 在过滤前发现可用的属性键

Workflow

工作流程

Parse the alert context. The first turn of the conversation carries alert variables:
```
alertID
```
,
```
alertName
```
,
```
alertValue
```
,
```
group
```
,
```
groupValue
```
,
```
query
```
,
```
thresholdWindow
```
,
```
timeRange
```
, plus a product-specific link. Use these, don't re-derive them.
Load the per-product companion. Based on the alert's product type, load the matching companion:
```
logs.md
```
,
```
traces.md
```
,
```
errors.md
```
,
```
sessions.md
```
, or
```
metrics.md
```
. Each captures the per-product investigation shape.
Run the investigation using the methodology from the investigate skill (cross-reference logs/traces/errors/sessions/metrics; cite identifiers; aggregate before paginating). Scoped to the alert's time range and filter.
Produce a structured diagnosis. See output template below.

解析警报上下文。对话的第一轮会携带警报变量：
```
alertID
```
、
```
alertName
```
、
```
alertValue
```
、
```
group
```
、
```
groupValue
```
、
```
query
```
、
```
thresholdWindow
```
、
```
timeRange
```
，以及一个产品特定链接。直接使用这些变量，无需重新推导。
加载对应产品的配套文档。根据警报的产品类型，加载匹配的配套文档：
```
logs.md
```
、
```
traces.md
```
、
```
errors.md
```
、
```
sessions.md
```
或
```
metrics.md
```
。每个文档都定义了对应产品的调查框架。
开展调查。使用调查技能中的方法（交叉引用日志/链路追踪/错误/会话/指标数据；引用标识符；分页前先聚合）。调查范围限定在警报的时间范围和过滤条件内。
生成结构化诊断结果。参考下方的输出模板。

Output template

输出模板

Alert investigations have a consistent structure so consumers (notification channels, dashboards) can parse them.

undefined

警报调查需采用统一结构，以便接收方（通知渠道、仪表盘）能够解析。

undefined

What triggered

触发原因

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

<1-2句话说明警报名称、阈值以及触发警报的数值。>

Likely cause

可能原因

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

<引用具体证据的根本原因说明：链路追踪ID、日志时间戳、错误组ID、标志键、部署时间。>

Scope

影响范围

<受影响的对象或范围。用户数量、服务数量、会话数量、错误组数量。影响的时间窗口。>

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.>

undefined

<1-3条待命人员或负责人应采取的具体行动。优先给出具体内容：“在环境Y中回滚标志X”、“重启服务Z”、“调查链路<id>中的下游故障”。避免使用“进一步调查”——如果无法确定根本原因，请说明具体需要调查的内容和方式。>

undefined

When to load which companion

何时加载对应配套文档

logs.md
— log alert, log pattern alert
traces.md
— latency alert, trace-error-rate alert, span-specific alert
errors.md
— error-rate alert, new-error-group alert, crash-rate alert
sessions.md
— session-health alert, user-facing-error-rate alert
metrics.md
— custom metric threshold, aggregated metric alert, composite alert

If the alert crosses product boundaries (e.g. a metric alert driven by error data), load both companions.

logs.md
— 日志警报、日志模式警报
traces.md
— 延迟警报、链路错误率警报、特定跨度警报
errors.md
— 错误率警报、新错误组警报、崩溃率警报
sessions.md
— 会话健康警报、用户端错误率警报
metrics.md
— 自定义指标阈值、聚合指标警报、复合警报

如果警报跨产品边界（例如由错误数据驱动的指标警报），则加载两个配套文档。

Guidelines

指导原则

Stay tight. Alert investigations feed notifications — keep the output structured and scannable. No preamble ("Here is my analysis..."), no repeated framing.
Cite identifiers. Every claim in the diagnosis should reference a specific trace ID, error group ID, session ID, or log timestamp.
If the alert appears to be noise, say so explicitly — "This alert fired because of <X>, but the underlying behavior is within normal variance because <Y>". Noise is a legitimate outcome; don't invent root causes.
Don't redo the investigation you just did. The diagnosis output should let the on-call act without re-querying.

简洁紧凑。警报调查结果会用于通知——保持输出结构化且易于扫描。无需开场白（“以下是我的分析...”），无需重复框架内容。
引用标识符。诊断中的每一项结论都应引用具体的链路追踪ID、错误组ID、会话ID或日志时间戳。
如果警报看起来是误报，请明确说明——“此警报触发是因为<X>，但底层行为在正常波动范围内，原因是<Y>”。误报是合理的结果；不要编造根本原因。
不要重复刚完成的调查。诊断输出应让待命人员无需重新查询即可采取行动。