signoz-investigating-alerts

Alert Investigate

SigNoz アラートが発火した原因を診断します。このスキルは、アラート自体のシグナルと発火時間帯前後の関連シグナルを照合し、根拠を添えて可能性の高い原因を順位付けして提示します。signoz-explaining-alerts と対をなすスキルです。explain はルールを静的に解読し、investigate は特定のインシデントを診断します。

前提条件

このスキルは SigNoz MCP サーバーのツール（signoz_get_alert、signoz_get_alert_history、signoz_execute_builder_query、signoz_query_metrics、signoz_search_traces、signoz_search_logs、signoz_get_trace_details など）を多用します。ワークフローを実行する前に、signoz_* ツールが利用可能であることを確認してください。利用できない場合は、SigNoz MCP サーバーがインストールまたは設定されていません。まず signoz-mcp-setup を実行して、MCP 接続を初期化または修復してください。

使用する場面

ユーザーが次のことを求めている場合に、このスキルを使用してください。

• 特定のアラートが発火した理由を理解する。
• アラートによって引き起こされた最近のインシデントの根本原因を特定する。
• アラートのシグナルを関連するメトリクス、トレース、ログと照合する。
• 「実際のシグナル」による発火と、フラッピングやしきい値設定の不備を区別する。

ユーザーが次のことを求めている場合は使用しないでください。

• アラートが監視するよう設定されている内容を理解する → signoz-explaining-alerts。
• 新しいアラートを作成する → signoz-creating-alerts。
• アラートを変更する（しきい値を上げる、ヒステリシスを追加するなど）→ signoz_update_alert を直接呼び出してください。
• アラートを起点としない自由形式のアドホックな調査を行う → signoz-generating-queries。

必須入力

入力	必須	不足時の取得元
アラート識別子（ルール ID または名前）	はい	$ARGUMENTS[0] または最近のコンテキスト
時間範囲	いいえ	signoz_get_alert_history の最新の発火をデフォルトとして使用

アラート名が曖昧な場合、このスキルはベストエフォートで読み取り専用の調査を行います。

1. signoz_list_alert_rules を呼び出し、ページネーションを行って名前をあいまい検索します。
2. 解釈を明示します。「14:32 UTC に発火した『High Error Rate - Checkout』（ID 42）を調査しています。別のアラートまたは発火を指している場合は、お知らせください。」
3. 続行します。

取得した完全な履歴（すべてのページを取得し、失敗した呼び出しがない場合）に、照会した過去の期間内の発火状態への遷移が含まれていない場合は、停止してください。調査する発火時間帯はありません。次のように応答します。

"過去 7 日間、アラート '[name]' の発火イベントは返されなかったため、調査する発火時間帯はありません。signoz-explaining-alerts を使ってルールを確認するか、アラートが有効になっているか確認してください。"

これを「発火していません」と短縮してはいけません。保持期間や、新しい ID で再作成されたルールが原因で、完全な履歴が空になることがあります。履歴の呼び出しに失敗した場合や、ページネーションが途中で終了した場合は、履歴を完全に読み取れなかったことを伝えてください。発火履歴、現在の state、disabled、配信（これを返すアラートツールはありません）は、それぞれ別の事実として報告してください。

ワークフロー

調査は 3 つの段階で実行され、各段階には厳格な早期終了ゲートがあります。 Tier 1 は常に実行します。Tier 2 は Tier 1 で実際の発火を確認した場合にのみ実行します。 Tier 3 は Tier 2 で相関する異常が見つかった場合にのみ実行します。ゲートを省略すると、問題のないアラートに対して不要なトレース／ログクエリが大量に発生します。

ステップ 1：アラートと発火期間を特定する（Tier 0）

1. アラート ID が指定されていない場合は、signoz_list_alert_rules（ページネーションあり）で解決します。
2. signoz_get_alert を呼び出してルール設定全体を取得します。アラートが評価したクエリ、しきい値、リソーススコープを把握するために必要です。
3. 最初に timeRange: "7d" と order: "desc" を指定して signoz_get_alert_history を呼び出します。タイムラインに発火状態と非アクティブ状態への遷移を含めるため、state は省略します。data.nextCursor がある場合（完全性に関する注記にも hasMore: true と報告されます）に限り、続けて取得します。これを cursor として渡し、timeRange を注記にある解決済みの絶対値 start と end に置き換え、同じ state／フィルター（省略する場合はその省略も含む）と order を維持します。nextCursor がなくなった場合、または注記に hasMore: false と報告された場合に停止します。offset やページの件数で判断してはいけません。後から意図的に指定する state フィルターで「resolved」／「recovered」を意味する場合は、inactive を使用します。列挙値は inactive|pending|recovering|firing|nodata|disabled です。recovering は発火を維持する一時的な状態であり、解決ではありません。
   パターン分析には、すべての遷移データが必要です。行はラベルグループごとの fingerprint 単位で出力されるため、別グループの行を混在させないでください。レスポンスから、次の処理を行います。
   • ルール全体のインシデント期間を作成します。overallStateChanged: true である重複のない行を使用します。overallState: "firing" への遷移でインシデントが始まり、次の overallState: "inactive" への遷移で終了します。対応付ける前に、重複するタイムスタンプを除外し、unixMilli の昇順で並べ替えます。$ARGUMENTS[1] で別のインシデントが選択されていない限り、最新のインシデントを使用します。
   • 影響を受けた時系列を fingerprint ごとに分割し、各行のラベルを保持します。そのグループの発火と解決のタイミング、および Tier 1～3 のクエリのスコープにするグループを判断する場合は、stateChanged: true の行だけを使用します。
   • ルール全体の遷移、または名前付き fingerprint 1 つから、発火パターンを記録します。
     • one-off → 前後に長い静穏期間がある単発の発火です。
     • sustained → 1 回以上の評価サイクルにわたって発火状態が続いた発火です。
     • flapping → 1 時間以内に 3 回以上発火し、発火と解決を交互に繰り返します。
     • recurring → 定期的な間隔（たとえば毎時など、cron のような間隔）で発火します。
   • 異なる fingerprint を根拠に flapping と判断してはいけません。このパターンは Tier 2／3 の指針になります。

ステップ 2：ティア 1（何が発火し、どの程度だったか）

このティアは常に実行されます。発火が実際のものか（しきい値への一時的な接触やフラッピングではないか）を確認し、その規模を定量化します。

1. 発火開始時刻を中心とする時間範囲 [fire_start - 30m, fire_start + 30m] で、アラートの主要クエリを再実行します。
   • アラートに保存されたビルダー、数式、PromQL、またはClickHouseクエリエンベロープには、signoz_execute_builder_query を使用します。
   • 保存されたクエリを、保存されたとおりに再現します。ルールにグループ化クエリの limit と order が設定されている場合は、今回の実行でも維持してください。評価対象となったのは、そのクエリで選択された上位N系列（時間範囲全体で順位付け）のみであるため、再現でも同じ対象を確認する必要があります。この上限を調査結果として記録してください。上位N件の外にあるグループは評価されておらず、below ルールを降順で並べ替えると、しきい値を超える系列がすべて除外される可能性があります。上位N件に対するアラートが意図したものではない限り、limit／order を指定せずにルールを更新することが対処方法です。
   • 保存されたクエリに境界が指定されていない場合、アラートはすべての系列を評価していますが、signoz_execute_builder_query には表示用の limit が適用されます。ステップ 1 で特定したフィンガープリントを確認するには、limit を引き上げるのではなく、そのラベルをフィルターに追加してください。グループを順位付けするには、ダッシュボードの orderBy ではなく、v5 の order（メトリクス／数式では __result desc、ログ／トレースでは主集計の降順）を使用し、返されたグループ数が limit とちょうど一致した場合はその旨を記載してください。
2. 次の値を計算します。
   • 発火時間範囲内のピーク値。
   • しきい値超過の規模：「above」アラートでは (peak - threshold) / threshold * 100、「below」アラートでは逆向きに計算します。
   • 発火継続時間：ルール全体の発火から非アクティブまでの時間、またはグループ単位の調査では選択したフィンガープリントの継続時間です。どちらを使ったかを明記してください。
   • 発火前のベースライン：発火開始前の30分間における平均値。
3. 早期終了ゲート：しきい値超過の規模がしきい値の10％未満で、かつ発火継続時間が評価ウィンドウ1回分未満の場合は、「境界的な発火」と分類します。アラートの感度が高すぎる可能性があります。ティア 2 と 3 を省略し、ステップ 5 に進み、仮説は「しきい値が厳しすぎる可能性があるため、調整を推奨する」の1つだけにします。

ステップ 3：ティア 2（関連シグナルとベースラインの比較）

ティア 1 で実際のしきい値超過が確認された場合のみ実行します。アラートと同じリソース範囲の関連シグナルを取得し、発火時間範囲とベースライン時間範囲を比較します。

1. ベースライン時間範囲を選択します。前日の同じ時間帯を使用します（fire_start - 24h, fire_start - 24h + fire_duration）。アラートが既知の異常発生時間（デプロイ、週次ジョブなど）に発火した場合は、出力にその旨を記載しますが、処理は続行します。

2. アラートのリソースタイプに応じて関連シグナルを調べます。対応表は references/neighbor-signals.md を参照してください。一般的なケース：

   • サービスレベルのアラート（service.name = X）：エラー率、p95／p99 レイテンシ、リクエストスループット、トレースデータが利用可能な場合は依存先のエラー率を取得します。
   • ホスト／VM のアラート（host.name = X）：CPU、メモリ、ディスク I/O、ネットワーク I/O を取得します。
   • K8s ポッド／名前空間のアラート：ポッドの再起動、コンテナの CPU／メモリ制限、ノードのプレッシャー、最近のロールアウトを確認します。

3. 関連シグナルごとに、次の処理を行います。

   • signoz_execute_builder_query または signoz_query_metrics を使って、両方の時間範囲（発火時とベースライン）をクエリします。
   • 差分（発火時間範囲とベースラインの変化率）を計算します。
   • 差分の絶対値で順位付けします。

4. 早期終了ゲート：ベースラインから25％以上の乖離を示す関連シグナルがない場合は、「孤立した発火：アラート自身のシグナルは変化したが、ほかのシグナルは変化していない」と分類します。これは通常とは異なるため、明示する価値があります。ティア 3 を省略し、ステップ 5 に進み、アラート自身のクエリに焦点を当てた仮説を立てます（原因として考えられるもの：データソースの変更、計装の変更、このメトリクスにしか現れない下流のサイレント障害）。

ステップ 4：Tier 3（障害発生時間帯のトレースとログ）

Tier 2 で関連する近隣の異常が見つかった場合にのみ実行し ます。具体的な失敗オペレーションを詳しく調べます。

1. トレース（アラートの対象がサービスで、トレースを 利用できる場合）：

   • 障害発生時間帯を対象に、フィルター service.name = <scope> AND has_error = true を指定して signoz_search_traces を呼び出します。上位 20 件までに制限します。
   • name と status_message でグループ化します。サンプル内の上位 3 件を、それぞれ 1 つの トレース ID とともに提示します。20 件のサンプル数を、全時間帯の頻度として扱わないでください。
   • 必要に応じて、スパン属性を確認するため signoz_get_trace_details を呼び出します。検索結果の trace_id を traceId として渡し、さらに同じ絶対時刻の障害発生時間帯の start と end も渡してください。そうしないと、6 時間のデフォルト期間では古いインシデントを取得できません。

2. 障害発生時間帯のログ：

   • フィルター <scope_filter> AND severity_text IN ('ERROR', 'FATAL') を指定して signoz_search_logs を呼び出します。最新の 20 件までに制限します。
   • body のパターン（または存在する場合は exception.type）でグループ化します。サンプル内の上位 3 件の異なるメッセージと、その件数を提示します。

3. 相互参照：トレースとログは、同じ 下流サービス、依存関係、またはコードパスを示していますか？示している場合、それが 最有力の仮説となります。

障害発生時間帯とベースライン期間の呼び出しを適切に組み合わせるクエリテンプレートについては、 references/baseline-comparison.md を参照してください。

Step 5: 構造化された出力を作成する

以下の順序を厳守してください。エンジニアは切迫した状況ではまず冒頭を読み、必要な情報が見つかるとそこで読むのをやめるため、TL;DRを先頭に置きます。すべての主張には、その根拠となったMCPクエリを示してください。「ログを確認する／接続を検証する」といった一般的な埋め草は入れないでください。

1. TL;DR：1～2文に収めてください。最も有力な仮説、全体的な確信度、影響範囲、最も有効な次のアクションを記載します。例：

「checkoutserviceのエラー率が14:32 UTCに8分間、12.4%（しきい値5%）に達しました。最も可能性の高い原因はpayments-apiのタイムアウトです（確信度：高）。トレース 7af3a09b… を開いて、失敗した呼び出しを確認してください。」

2. 発生したアラート アラート（ID、名前）、発生時間帯（UTCの絶対時刻＋相対時間）、ピーク値（「エラー率がしきい値5%に対して12.4%に達し、148%超過」）、発生継続時間、発生パターン（one-off ／ sustained ／ flapping ／ recurring ／ marginal）を記載します。

3. 調査の経緯 確認した内容を一覧でスキャンしやすく示します。確認できたシグナルには✅、否定できたものには❌を付け、それぞれに1行の所見を添えます。クエリが失敗またはタイムアウトした場合は、エラーとともに「未確認」とします。読者がAIの調査内容と判明したことを把握できるようにするのが目的です。 例：

• ✅ Tier 1：ピークエラー率は12.4%。アラートは実際の発生であり、境界的な発生ではありません。
• ✅ Tier 2：paymentsのエラー率は+8900%、p99は+1180%。下流への連鎖が見られます。
• ❌ CPU／メモリの負荷：発生時間帯を通して横ばいでした。
• ✅ Tier 3：エラートレース30件すべてがpayments-apiに到達し、同じメッセージを記録しています。

4. 可能性の高い原因（順位付け、最大3件） 各原因には、次の3つを含めます。

• 仮説：具体的な1文で記述します。悪い例：「サービスが不健全です」。良い例：「checkoutがpayments-apiへの呼び出しでタイムアウトしています」。
• 根拠：Tier 1／2／3の裏付けとなる数値を、再実行できるよう基となるクエリを文中に含めて示します。隣接するシグナル、ベースラインとの差分、仮説を裏付けるトレース／ログのパターンを明記します。
• 確信度：high とするには、次のうち2つ以上が必要です：時間的な先行、トポロジー／依存関係のエッジ、共通のサービスまたはエンティティ、相関するメトリクス／ログ／トレースの証拠、最近のデプロイまたは設定変更。少なくとも1つのシグナルを含む、あるTierの証拠が1つある場合は medium とします。裏付けのない単一のシグナルのみが変化した場合は low とし、その場合は原因ではなく「同時に発生したシグナル」と記載します。

Tier 1のみを実行した場合（境界的な発生、または隣接する異常がない場合）は、仮説の数を減らして確信度を low とし、調査上の制約を明示してください。

5. 否定された可能性 簡潔ながら明確に記載します。証拠によって排除された候補と、その理由を1行で列挙します。否定すべきものが特にない場合は、このセクションを省略してください。ただし、検討した候補を除外した場合は、ユーザーが再確認に時間を費やさないよう、ここに記載します。

6. 推奨する次のステップ ユーザーが実行できるアクションを記載します。ユーザーがすぐに行動できるよう、具体的な内容とSigNoz固有の操作方法を示してください。

• 開くべき具体的なトレース、ダッシュボード、またはアラート（例：「SigNoz UIでトレース 7af3a09b… を開く」）。
• signoz-generating-queries で実行する具体的なクエリ：フィルターと時間範囲を正確に指定します。
• 発生が境界的な場合は「このアラートを調整する」と記載し、signoz_update_alert で変更するフィールド（matchType、target、recoveryTarget）とその変更内容を明示します。
• 原因がサービス間にまたがる場合は、「インシデントを作成する」または「担当チームにページする」と記載します。

ナビゲーションチップとしてのミラーリング。 この「推奨する次のステップ」から、実行可能性が最も高く、アラートに関連するものを最大3件、ホストのフォローアップインテントとしてミラーリングします。残りは、ユーザーが全体像を把握できるようレポート本文に記載してください。チップの表示数には上限がありますが、本文にはありません。

対象外（v1）

• デプロイ／設定変更との相関：SigNoz MCP はデプロイ用ツールを公開していないため、そのようなツールをでっち上げてはいけません。ユーザーが最近のデプロイに言及した場合は、状況説明として示しますが、シグナルの証拠なしにそれが障害を引き起こしたと断定してはいけません。
• サービス間の影響範囲の追跡：アラート対象サービスの下流の呼び出し元を調査することです。コンテキストの範囲を抑えるため、対象外です。
• 長期的な過去のベースライン：Tier 2 では前日の同じ時間帯と比較しますが、週次／月次の季節性とは比較しません。ユーザーが「金曜日の午後としては通常の範囲ですか」と尋ねた場合は、異常アラート（anomaly_rule を指定した signoz-creating-alerts）を提案してください。

ガードレール

• 3 段階の早期終了は必須です。 ゲートを省略すると、静かなアラートでも数百件のトレース／ログを取得し、コンテキストが膨れ上がります。これらのゲートは任意の最適化ではありません。
• すべての主張を MCP クエリの結果に基づかせてください。 推測してはいけません。証拠が不足している場合は、確信度を下げ、その旨を伝えてください。
• 読み取りの失敗や一部取得では、何も否定できません。 エラーまたはタイムアウトになったクエリは「未確認」です。上限に達したトレースやログのサンプルが裏付けるのは、その行に関する主張のみです。対象時間帯について「なし」「すべて」、または合計を主張するには、完全な結果が必要です。
• 各仮説に、それを裏付けるクエリを示してください。 これによりユーザーは結果を再現し、さらに深く調査できます。
• 簡潔に、証拠に基づいて記述してください。 TL;DR は最大 1～2 文にします。完全なレポートは事後検証ではなく、トリアージカードです。プレッシャーのかかる状況でも、エンジニアが冒頭をざっと読んで行動できるようにしてください。各セクションには、アラートのペイロードですでに確認できる情報にはない証拠を加える役割が必要です。
• 相関は因果関係を意味しません。 次の項目のうち少なくとも 2 つが一致する場合に限り、原因と表現してください：時間的な先行（症状より先にシグナルが変化した）、トポロジー／依存関係のエッジ、共通のサービスまたはエンティティ、相関するメトリクス／ログ／トレースの証拠、最近のデプロイ／設定変更。時間が一致する異常が 1 つだけの場合は「同時に発生したシグナル」であり、原因ではありません。その旨を明示してください。
• アラートを言い換えたり、当たり前の提案をしたりしないでください。 「ログを確認してください」「接続を確認してください」「ダッシュボードを調査してください」などは、この出力を読む人もすでに必要だと分かっています。一般的な提案の代わりに、すぐに実行できる具体的なクエリ、トレース、またはフィルターを示してください。
• 識別子を捏造してはいけません。 トレース ID、スパン名、アラートルール ID、チャネル名、デプロイ ID など、出力内の識別子はすべて実際の MCP 応答から取得してください。もっともらしく見えるプレースホルダーを作ってはいけません。
• 不確実性を正直に報告してください。 確信度が中以上の仮説がない場合、回答は「明確な根本原因は見つかりませんでした。確認した内容と除外できた内容を以下に示します。」としてください。有用に見せるためだけに、確信度の低い推測を有力な仮説に格上げしてはいけません。誤検知は、誤検出がないことよりも、進行中のインシデント対応の時間を無駄にします。
• すべての詳細調査クエリで、リソース属性によるフィルターを優先してください。 これは SigNoz MCP のガイドラインであり、大規模環境でのクエリ速度に直接影響します。
• アラートを変更してはいけません。 調査は読み取り専用です。ユーザーが「ついでにこのアラートのしきい値を厳しくして」と言った場合は、次のステップとして提案してください。signoz_update_alert は呼び出してはいけません。
• 対象範囲を守ってください。 静的ルールの説明は signoz-explaining-alerts の対象です。アラートを起点としない原因分析は signoz-generating-queries の対象です。
• タイムゾーン。 自律型と対話型の利用者が同じ時間帯を参照できるよう、障害の発生時間帯は相対時間（「2 時間前」など）とともに、必ず UTC でも示してください（「14:32 UTC、2 時間前」）。

例

ユーザー：「チェックアウトのエラー率アラートが発火したのはなぜですか？」 エージェント：

1. アラート「High Error Rate - Checkout」を解決します（id 42）。

2. signoz_get_alert_history → 最も新しい発火は2時間前の14:32 UTCで、 8分間継続し、発火は1回のみです（フラッピングではありません）。

3. Tier 1：[14:02, 15:02] の範囲でエラー率の計算式を再実行します。ピーク エラー率は12.4%（しきい値5%に対して148%超過）です。発火前の ベースラインは0.3%です。実際の発火であり、境界的な値ではありません。

4. Tier 2：service.name = checkout の関連シグナルを取得します。

   • p99レイテンシ：4.1s、ベースライン320msに対して（+1180%）。
   • スループット：-42%（低下）。
   • 下流のpaymentsのエラー率：18%、ベースライン0.2%に対して（+8900%）。
   • CPU／メモリ：横ばい（リソース逼迫なし）。

5. Tier 3：発火時間帯のservice.name = checkout, has_error = trueの トレースを調べます。最も多い操作はPOST /checkout/submitで、最も多い エラーメッセージは「payments-api呼び出し中にコンテキストの期限を超過しました」です。 サンプリングしたエラートレース20件すべてが同じ下流URLに到達しています。サンプリングした エラーログ20件のうち17件に「payments client timeout」と記録されています。

6. 出力：

   要約：checkoutserviceのエラー率が14:32 UTCに8分間、 12.4%（しきい値5%）に達しました。最も可能性の高い原因はpayments-apiのタイムアウトです （確信度高：トレース、ログ、関連シグナルの証拠が一致しています）。 トレース7af3a09b…を開くと、失敗した呼び出しを確認できます。

   • 発火内容：アラート42は2時間前の14:32 UTCに発火し、8分間 継続しました。エラー率は12.4%でピークに達しました（しきい値を148%超過）。
   • 調査の経緯：
     • ✅ Tier 1：ピーク12.4%、しきい値5%、発火前のベースライン0.3%。 実際の発火です。
     • ✅ Tier 2：paymentsのエラー率+8900%、p99レイテンシ+1180%、 スループット−42%。
     • ❌ checkoutのCPU／メモリ逼迫：横ばいです。
     • ✅ Tier 3：サンプリングしたエラートレース20件すべてがpayments-apiに到達し、 context deadline exceededが発生しています。サンプリングしたログ20件のうち17件がタイムアウトです。
   • 考えられる原因（確信度高）：paymentsサービスのエラーが checkoutに波及しています。トポロジー（checkout → paymentsのエッジ）、 時間的な先行関係（paymentsのエラーがcheckoutのp99に先行）、 共通のエンティティ（サンプリングしたエラートレースすべてがpayments-apiのURLを対象）という 複数の証拠が一致しています。
   • 除外した原因：checkout側のリソース逼迫（CPU／メモリは 横ばい）、上流のトラフィック急増（スループットは急増せず、低下）。
   • 次のステップ：SigNoz UIでトレース7af3a09b…を開きます。paymentsに 独自のアラートがある場合は、そのアラートに対してsignoz-explaining-alertsを実行します。 ない場合は、signoz-generating-queriesを使って過去4時間のpaymentsのエラー率を調べます。

---

ユーザー：「prod-api-3でフラッピングしているCPUアラートを調査してください」

エージェント：

1. アラートを特定します（id 88、host.name = prod-api-3）。

2. 履歴：過去1時間に7回発火し、8～12分ごとに発火と解決を繰り返しています。 フラッピングのパターンです。

3. Tier 1：ピークは84%（しきい値80%をわずか5%超過）です。各発火は 2～4分間続きました。境界的な値で、しきい値付近を推移していました。 matchType = at_least_onceにより、短時間の変動が毎回トリガーになりました。

4. 早期停止が適用されます。Tier 2／3はスキップします。

5. 出力：

   要約：アラート88はprod-api-3でフラッピングしています。過去1時間に7回発火し、 各発火は2～4分間で、いずれもしきい値80%の5%以内です。 明確な根本原因はありません。これはインシデントではなく、しきい値の調整が必要な状態です。 ノイズを抑えるには、matchTypeをon_averageに変更するか、ヒステリシスを追加してください。

   • 発生した内容：アラート 88、ホスト prod-api-3、発生パターン flapping。過去 1 時間に 7 回発生し、それぞれ 2～4 分継続しました。ピークは 84%（80% のしきい値を 5% 超過）。
   • 調査の経緯：
     • ✅ Tier 1：すべての発生がしきい値の 5% 以内で、継続時間は短く、ベースラインはすでに 70～75% でした。軽微な発生のため、早期終了がトリガーされ、Tier 2／3 はスキップされました。
   • 考えられる原因（確度低／シグナルの併発のみ）：しきい値の設定が厳しすぎるか、matchType が敏感すぎます。根拠： すべての発生がしきい値の 5% 以内で、ベースラインはすでに 70～75% で推移しています。単一のシグナルで、裏付けがないため、「原因」とは判断していません。
   • 除外した原因：実際の CPU 飽和インシデント（ピークが小さく、継続時間も短い。ベースラインもすでにしきい値に近い状態）。
   • 次のステップ：matchType を on_average に変更する（一時的なスパイクを平滑化します）、またはヒステリシスを設定してしきい値を 85% に引き上げる （recoveryTarget: 75）。signoz_update_alert を使って適用してください。

---

ユーザー：「昨夜発生したログボリュームアラートの RCA」

エージェント：

1. アラートを特定します：「Error Log Volume Spike」（id 14、サービスフィルターなし。groupBy service.name）。

2. 履歴：03:12 UTC に発生し、22 分間継続しました。アラートの注釈でサービス別に分類されており、service.name = inventory が発生した時系列でした。

3. Tier 1：発生時間帯の inventory のログ件数を再実行します。ピークは毎分 3,400 件のエラーで、しきい値は毎分 1,000 件（240% 超過）でした。発生前のベースラインは毎分 12 件でした。実際に大規模なアラートが発生しています。

4. Tier 2：service.name = inventory の関連シグナル：

   • リクエストエラー率：+600%。
   • p99 レイテンシ：+30%（軽微）。
   • CPU：-80%（低下）。メモリ：-60%。
   • Pod の再起動（k8s）：発生時間帯に 4 回。

5. Tier 3：発生時間帯の inventory のログ。20 行のサンプルで最も多かったメッセージ：「OOMKilled restarting」（20 件中 14 件）。トレースエラーで最も多かったもの：グレースフルシャットダウンの例外。

6. 出力：

   要約：アラート 14 は 03:12 UTC に service.name = inventory で発生し、しきい値を 240% 超過した状態で 22 分間継続しました。 最も可能性の高い原因：inventory の Pod が OOM キルされ、4 回再起動しました（確度高）。inventory デプロイメントのコンテナメモリ制限を確認してください。

   • 発生した内容：アラート 14 は 03:12 UTC にサービス inventory で発生し、22 分間継続しました。しきい値を 240% 超過しています。
   • 調査の経緯：
     • ✅ Tier 1：ピークは毎分 3,400 件のエラーで、しきい値は毎分 1,000 件でした。発生前のベースラインは毎分 12 件。実際に発生しています。
     • ✅ Tier 2：リクエストエラー率は +600%。CPU／メモリは低下 （−80%／−60%）。時間帯中に Pod が 4 回再起動しました。
     • ❌ p99 レイテンシ：上昇は +30% のみで、レイテンシが原因のインシデントではありません。
     • ✅ Tier 3：サンプルログで最も多かったメッセージは「OOMKilled restarting」（20 件中 14 件）。トレースエラーで最も多かったものはグレースフルシャットダウンの例外です。
   • 考えられる原因（確度高）：時間帯中に inventory の Pod が OOM キルされ、4 回再起動しました。トポロジー（単一サービス）、時間的な先行関係（エラースパイクの前にメモリがゼロまで低下）、共通のエンティティ（すべてのログ行が service.name = inventory からのもの）、一貫した単一のパターン（OOM → 再起動 → グレースフルシャットダウンに伴うノイズ）の各観点で根拠が収束しています。
   • 除外した原因：上流のトラフィック急増（スループットに変化なし）。除外できていない原因：リクエストパスの障害（サンプルログ 20 件中 6 件は再起動に関するものではありません）。両者を切り分けるため、エラーログ全体に対する再起動関連ログの件数を確認してください。
   • 次のステップ：inventory の Pod のコンテナメモリ制限を確認し、最近のデプロイを調べてください。アラートから再起動関連のエラーパターンを除外すべきか、根本にある OOM が本当の懸念事項なのかを検討してください。

追加リソース

• references/neighbor-signals.md：リソースタイプ（service / host / k8s）と、Tier 2 で取得する近隣シグナルを対応付けるルックアップテーブルです。
• references/baseline-comparison.md：fire-window と baseline-window の呼び出しを適切に組み合わせるクエリテンプレートです。両方の signoz_execute_builder_query のフォーマット方法も含まれています。
• signoz-explaining-alerts スキル：アラートが監視する内容にユーザーが詳しくない場合、調査前にルールを解読するために使用します。
• signoz-generating-queries スキル：同じリソース範囲に対するアドホックな追加クエリに使用します。