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 — レイテンシーアラート、トレースエラー率アラート、スパン固有のアラート
• errors.md — エラー率アラート、新規エラーグループアラート、クラッシュ率アラート
• sessions.md — セッションヘルスアラート、ユーザーに影響するエラー率アラート
• metrics.md — カスタムメトリクスしきい値、集計メトリクスアラート、複合アラート

アラートが製品の境界をまたぐ場合（例: エラーデータに起因するメトリクスアラート）、両方のコンパニオンを読み込みます。

ガイドライン

• 簡潔に保ちます。 アラート調査は通知に供給されるため、出力は構造化され、一目で把握できるものにしてください。前置き（「以下が私の分析です…」）や、繰り返しの枠付けは不要です。
• 識別子を引用します。 診断内のすべての主張は、特定のトレース ID、エラーグループ ID、セッション ID、またはログのタイムスタンプを参照するべきです。
• アラートがノイズと思われる場合は、そのことを明示的に述べてください — 「このアラートは のために発火しましたが、根本的な挙動は のため通常の変動範囲内です」。ノイズは正当な結果です。根本原因をでっち上げないでください。
• 今行った調査をやり直さないでください。 診断出力は、オンコール担当者が再クエリすることなくアクションを起こせるものにしてください。