signoz-setting-up-observability

取り込み後のオブザーバビリティの設定

「テレメトリが SigNoz に流れ込んでいる」状態から、「ダッシュボード、アラート、保存済みビューがあり、チューニングのループも回っている」状態まで、サービスを設定します。このスキルは単独で参照する資料ではなく、オーケストレーションレイヤーです。実作業は関連する SigNoz スキルが担い、MCP ツールとリソースには最新のペイロードスキーマが用意されています。このスキルでは、それらを順序立てて実行し、どのスキルも単独では扱わない判断（対象範囲、SLO、しきい値、何を省略するか）を行います。ペイロードスキーマやフィールドのルールをあえて繰り返していないため、ペイロードを作成する前に、該当する signoz://… リソースを確認してください。

トレース、ログ、メトリクスがすでに SigNoz に取り込まれており、SDK の接続をまだ設定している段階ではなく、SLO を考慮した方針のある設定をしたい場合に使用します。対象となる利用者は、自律的に動作し、人間が介入しない AI SRE エージェント（例：SigNoz 製品内のアシスタント）と、Claude Code / Codex / Cursor のプロンプトを使うエンジニアの2者です。どちらも同じ流れに従います。手順で人間の判断が必要な場合（フェーズ1のトリアージ、フェーズ5の承認）は、ホストがその判断をどう提示するかを決めます。自律型のホストは処理を止めずに、上流のコンテキストから判断を補います。

前提条件

このスキルは SigNoz MCP サーバーのツール（signoz_list_services、signoz_list_dashboards、signoz_get_field_keys、signoz_execute_builder_query、signoz_create_dashboard、signoz_create_alert、signoz_create_view など）を呼び出し、関連するスキルに処理を委譲します。ワークフローを実行する前に、signoz_* ツールが利用可能であることを確認してください。利用できない場合は、SigNoz MCP サーバーがインストールされていないか、設定されていません。まず signoz-mcp-setup を実行してください。生の HTTP 呼び出しに切り替えたり、ペイロードを捏造したりしないでください。

使用するタイミング

ユーザーが、SLI/SLO → 探索 → ダッシュボード → ビュー → アラート → チューニングを、成果物の組み合わせを問わず、1つのワークフローとして順序立てて進める取り込み後の設定全体を求めている場合に、このスキルを使用します。

ユーザーが単一の成果物を求めている場合は、このスキルを使用せず、直接引き継いでください。

• ダッシュボードのみ → signoz-creating-dashboards。
• 静的 / しきい値アラート1件、または通知ルールのみ → signoz-creating-alerts。（ただし、SLO / バーンレート / エラーバジェットのアラートは、ダッシュボードがなくてもこのスキルの対象です。以下のフェーズで SLI/SLO を記録し、バーンレートを判断する必要があるためです。）
• 保存済みの Explorer ビューのみ → signoz-managing-views。
• 1回限りの探索クエリ → signoz-generating-queries。
• 概念やドキュメントの確認（SRE の手法、OTel の規約、バーンレートの計算） → signoz-searching-docs / signoz_search_docs。

以下の各フェーズでは、実作業を行うスキルを案内します。このスキルが担うのは、その順序と判断です。

フェーズ 1：対象範囲のトリアージ（省略しないでください）

ツールを使う前に、以下の質問への回答を確認してください。各項目は後続のフェーズに進むために必要です。

1. このサービスは何を行い、外部サービスを呼び出しますか？ 1〜2 文で回答してください。これは SLI（「正常に動作している」とはどういう状態か）の決定に役立ち、監視すべき下流の依存先を明らかにします。DB、キャッシュ、キュー、サードパーティ API を呼び出す場合は、それぞれの依存先に対するクライアントスパンのレイテンシとエラー率を監視する計画を立ててください。依存先に問題があれば、サービス自体が正常でもユーザーに障害が発生するためです。
2. 成果物は何ですか？ ダッシュボード／アラート／保存済みビューのいずれか、または組み合わせです。
3. インフラ監視も行いますか？（任意。質問してください） サービスが、同じリソース属性でテレメトリを送信する自社管理のインフラ（k8s ポッド、VM、コンテナ）上で動作している場合、追加の計装なしで USE／インフラパネル（CPU、メモリ、再起動、ネットワーク）を追加できます。フェーズ 3 を参照してください。プラットフォームチームがすでにホスト／クラスターのダッシュボードを管理している場合は省略してください。
4. どのシグナルが出力されていますか？ トレース／ログ／メトリクス。これにより、どの signoz_get_field_keys 呼び出しを行うかが決まります。
5. 標準のリソースフィルターは何ですか？ 通常は service.name です。クエリを実行する前に正確な値を確認してください。推測しないでください。
6. このサービスのユーザーにとって、成功とはどのような状態ですか？（フェーズ 2 の準備です。）「5xx がなく、リクエストが 1 秒未満」のように一行で十分です。これが SLI になります。
7. 担当者は誰で、ランブックはありますか？ 担当チーム、サービスティア、本番／ステージングの対象範囲を確認してください。これらはフェーズ 8 のアラートラベルと注釈になります。実在するランブック URL があれば記録してください。決して作り出さないでください。

「まずデータを調べる」ことを明示的な選択肢として提示してください。

フェーズ 1.5：既存のものを確認する

各作成サブスキルは、呼び出されたときに厳密な重複チェックを実施します（signoz-creating-dashboards はダッシュボードを一覧表示し、signoz-creating-alerts はアラートルールをページネーションします）。ここでこれを再実装する必要はありません。オーケストレーションの価値は、最初に一括確認を行い、構築途中で競合するのではなく、既存のものに合わせて順序を調整できることです。

• サービスからデータが送信されていますか？ 正確な名前は何ですか？ （signoz_list_services。）この名前は以降のすべてのフェーズで再利用するリソースフィルターです。ほかの作業に進む前に確定してください。
• そのサービスのダッシュボード／アラート／保存済みビューはすでにありますか？ ある場合は、並行して新規作成するのではなく、それを拡張する計画を立ててください（signoz-modifying-dashboards、signoz-managing-views、または signoz_update_alert に引き継ぎます）。signoz-explaining-dashboards／signoz-explaining-alerts で、引き継ぐ内容を要約できます。
• 再利用できる通知チャネルはありますか？（フェーズ 5 に引き継ぎます。）

一致するものが見つかるか、すべてのページを確認し終えるまで、一覧のページネーションを続けてください。ビューの source が不明な場合は、トレース、ログ、メトリクス、メーターを個別に検索してください。

各成果物について、拡張するか新規作成するかを判断するために必要な範囲だけを調べてください。網羅的な一覧表示はサブスキルに任せてください。

フェーズ 2：設計を始める前に SLI／SLO を確定する

これは必須の成果物です。これがないと、アラートが「メトリクスがしきい値を超えた」だけのものになり、「ユーザーに見えるエラーバジェットが、問題にすべき速度で消費されている」ことを示すものになりません。

以下を確認してください。

• SLI の計算式：正常なイベント / 有効なイベント。例：正常に完了したチェックアウトリクエスト / チェックアウトリクエストの総数（ヘルスチェック、合成プローブ、スキャナートラフィック、ユーザー向けではないロングポーリングエンドポイントを除く）。
• SLO の目標値：例：30 日間のローリングウィンドウで 99.5％。
• 除外項目：有効なイベントに含めないもの（合成プローブ、スキャナートラフィック、ストリーミングエンドポイント）。
• エラーバジェットの許容量：目標値から導出される 1 - SLO。残りのバジェットを算出するには、SLO の対象期間における観測済みの不良イベント／有効なイベントも必要です。

これらを以降のフェーズに引き継いでください。フェーズ 8 で直接使用します。（SLO／バーンレートの概要：signoz-searching-docs。）

フェーズ 3：実際に存在するものを調べる（RED + USE の網羅性）

signoz-generating-queries が担うのは、探索そのものです。クエリの前に探索するルール、すべての探索呼び出し（signoz_list_metrics、signoz_get_field_keys、signoz_get_field_values、signoz_get_service_top_operations）、ツールの選択、データがない場合の区別が含まれます。データを一覧化するために活用してください。ここではクエリの仕組みを繰り返さないでください。（RED／USE の手法や SigNoz のフィールドの意味を確認する必要がある場合は、signoz-searching-docs を参照してください。）

オーケストレーションでは、見つかった内容を RED（リクエストレート、エラー、継続時間）と USE（使用率、飽和度、エラー）に対応付け、抜けを見つけ、generating-queries だけでは行わない判断をします。

カバレッジチェックリスト（サービスには RED、インフラ／リソースには USE）：

• Rate（レート）：操作ごとのリクエスト／呼び出しレート
• Errors（エラー）：操作ごとのエラー数またはエラーレート
• Duration（継続時間）：スパンまたはヒストグラムから得られる p50／p95／p99 レイテンシ
• Utilization（使用率）：CPU、メモリ、ディスク、キューの深さ、プールの占有率（インフラを自分で管理している場合のみ）
• Saturation（飽和度）：リクエストキュー、GC の一時停止、コネクションプールの待ち時間
• Errors（エラー）、リソースレイヤー：ディスク障害、エビクション、OOM によるプロセス強制終了

シグナルが不足している場合（例：エラー数がない場合）は、インストルメンテーションの不足です。存在するデータをもとに構築する前に、その不足を指摘してください。

スパンメトリクスは、パネルだけでなくアラートにも使います。 generating-queries が SigNoz のトレース→メトリクス出力（signoz_calls_total、signoz_latency_*、DB／外部呼び出しのスパンメトリクス）を見つけた場合は、ダッシュボードとバーンレートアラートの両方で、RED のデータソースとして優先してください。事前に集計されているため低コストです。一方、長いアラートウィンドウでの生トレース集計はコストが高く、アラートのデータソースとして不安定です。（正確なメトリクス名とラベル名は探索で確認してください。ハードコードしないでください。）

カウンターは、反射的にではなく、直前に測定したボリュームに応じて表示します。 これはスループットに限った話ではありません。グラフにするすべてのカウンター（リクエストレート、エラー数、再起動、OOM によるプロセス強制終了、エビクション）に当てはまります。被害を受けやすいのは、リクエストだけでなく、低ボリュームのエラーやリソースレイヤーのイベントです。毎秒レートは、安定した高ボリュームのシグナルに適しています。Phase 3 でカウントが少ない、断続的、または人間の作業ペースであると分かった場合、/sec のグラフは判読できないほど小さな小数（0.03/s）になります。固定のしきい値ではなく、症状を基準にしてください。毎秒レートが小数になる場合は、その意図を Phase 6 に伝え、レートではなく、より広い期間（24h～7d）での区間ごとの 増加数 として表示します。（CPU、メモリ、キューの深さなどのゲージは、すでに絶対値です。これはカウンターに関する注意点です。）これは意図的なトレードオフです（increase は選択した範囲に応じて y 軸をスケーリングし直します）。どちらかに一律で決めず、意識して判断してください。 signoz-creating-dashboards がレートと増加数の仕組みを担います。

インフラからサービスへの結合（USE の部分）を確認します。 ホスト／コンテナ／k8s のメトリクスに service.name が含まれているとは限りません。多くの場合、含まれるのは host.name／k8s.pod.name／k8s.node.name だけであり、k8s.deployment.name は service.name と異なる場合があります。generating-queries に、インフラメトリクスとこのワークロードを実際に結合する ID 属性を確認させ、その確認済み属性で USE パネルを絞り込みます。結合できる属性がなければ推測せず、ワークロードセレクターをユーザーに尋ねてください。

人の記憶ではなく、トレースから下流のトポロジーを探索します（Phase 1 Q1）。覚えておくべき注意点として、SigNoz v5 スキーマではクライアントスパンは kind でも SPAN_KIND_CLIENT でもなく、kind_string = 'Client' です。したがって、フィールドと値を確認したうえで、signoz_get_field_keys を使って値が設定されている依存関係属性を探索してください。現在の例には http_url、server.address、db.system、db.operation があります。テナントから実際に返されるフィールドだけを使ってください。

マルチテナントに関する注意：サービスが複数のテナント／リージョンに対応している場合は、安定した非 PII のテナント／リージョン属性（例：tenant.id、region、deployment.environment）を探し、生の URL やユーザー識別子は避けてください。テナントごとの内訳はダッシュボードに表示します。集計のみのビューでは、単一テナントの障害が隠れてしまいます。 SLI の衛生管理：SLI がカウントするイベントに適切なラベルが付いていることを確認します。広い分母（「サービスへのすべてのリクエスト」）では、/.env* や /.git* に対するスキャナーのトラフィックも実際に存在しますが、ユーザーのトラフィックではないため、除外する必要があります。除外条件はスキャナーのトラフィックだけを差し引き、それ以外には影響しないようにします。そのため、EXISTS AND … ではなく、単独の否定条件を使います。 <url_or_route_field> NOT REGEXP '/\\.(env|git|aws|ssh|well-known)' SigNoz の否定演算子は、フィールドが存在しない行にも一致します。そのため、フィールドのない有効なイベント（HTTP 以外のスパン、内部オペレーション）もカウントされます。イベントの対象範囲はスキャナーの条件ではなく、SLI 自体のスコープフィルター（service.name、http.route）で定義します。EXISTS と否定条件を組み合わせるのは、反対の意図、つまりフィールドが存在する行のうち特定の値を除外する場合に限ります（例：service.name EXISTS AND service.name != 'redis'）。適切にスコープ設定された SLI ではスキャナーのパスはすでに除外されるため、この問題が主に影響するのはサービス全体の比率です。スキャナーを確認したい場合は、別途セキュリティビューを用意してください。

フェーズ 4：カーディナリティとコストでラベルを分類する

ラベルをクエリに組み込む前に、それぞれを分類します。誤った分類は、メトリクス料金の急増とダッシュボードの可読性低下の最大の原因です。

クラス	カーディナリティ	使用先
ルーティング	<20	アラートラベル、抑制ルール、通知ポリシー（例：severity、team）
可変	<100、人が読みやすい値	ダッシュボード変数（例：environment、tenant）
内訳	通常は <500	グラフ／テーブルの groupBy（例：gen_ai.tool.name）
トレース／ログ専用	上限なし	トレースまたはログのみ。メトリクス系列には使わない

生の URL、クエリ文字列、ユーザー ID、セッション ID、リクエスト ID をメトリクスラベルに含めないでください。カーディナリティが急増し、料金も跳ね上がります。これらはトレース／ログに含めます。

カーディナリティは、表示パフォーマンスよりもコストに大きく影響します。SigNoz／ClickHouse は可変値を数百件扱っても問題ありません。制限となるのは、ドロップダウンの人間にとっての読みやすさです。

フェーズ 5：通知チャネル、バーンレートのウィンドウ、復旧しきい値を確定する

アラートを作成する前に、次の項目を確定します。

1. 通知ルーティング。 重大度ごとに、どのチャネルへ通知するかを決めます（例：critical → PagerDuty、warning → Slack）。適切な既存チャネルがある場合は、signoz_list_notification_channels のチャネルを再利用します。名前を決して作り出してはいけません。実際のチャネルの解決・作成とシークレットの取り扱いは signoz-creating-alerts（フェーズ 8）の担当です。ここでは、重大度からチャネルへの対応関係のみを確定します。

2. バーンレートのウィンドウ。 30 日間の予算に対する 99.9% の SLO では、一般的な初期値は次のとおりです。

   重大度	バーンレート	長いウィンドウ	短いウィンドウ	通知先
   即時ページング・クリティカル	14.4×	1h	5m	PagerDuty
   緩やかな消費・警告	6×	6h	30m	Slack
   チケットレベル・低	1×	3d	6h	チケットキュー

   バーンレートの倍率は SLO に依存しないため、目標値が異なる場合は、次の式を使って各絶対しきい値をその場で計算します。 error-rate = burn rate × (1 − SLO)（例：99.9% では 14.4× → 1.44%）。 signoz-searching-docs ではバーンレートの手法を説明していますが、数値の計算はできません。

   アラートが発火するには、両方のウィンドウで同時に条件を満たす必要があります。長いウィンドウは短時間の急増を抑え、短いウィンドウは迅速な復旧を可能にし、インシデントが解決したらページングをすぐに停止します。（標準的な SRE の表では 6× の行もページング対象のため、ここで Slack にルーティングするのは意図的な重大度の引き下げです。オンコールの基準に合わせて調整してください。）

3. 復旧しきい値（ヒステリシス）。すべての数値アラートについて、発火対象より低い値で復旧するように決めます（例：80% で発火し、70% で復旧）。これにより、境界付近で状態が頻繁に切り替わるのを防ぎます。signoz-creating-alerts では、この値を recoveryTarget フィールドに反映します。

具体的な提案値を添えて、ホストアプリケーションの質問／UI の仕組み（構造化された確認ツール、インラインタグ、対話型プロンプトなど。ホストのルールに従ってください）を使い、これらの項目を確認事項として提示します。「どのしきい値にしますか？」のような自由回答形式の質問は避けてください。値を提案し、ユーザーが調整できるようにします。 構築前に、対象範囲としきい値について明示的な承認を得ます。しきい値に影響するベースラインがあれば明示します（「現在のエラー率は 5.1% なので、固定の 5% アラートでは誤検知が多くなるため、代わりにバーンレートアラートを提案します」など）。

フェーズ 6：ダッシュボードを作成する

signoz-creating-dashboards に引き継ぎます。このスキルはテンプレート、レイアウト／変数／OTel の命名規則のデフォルト、v6 スキーマとその注意点、データなしの確認、必須のパネルごとのドライランを担当します（後から編集する場合は signoz-modifying-dashboards を使用します）。ここでパネル JSON やグリッドの仕組みを繰り返し説明しないでください。意図を伝え、ダッシュボードの作成はそのスキルに任せます。

大きなダッシュボードを 1 つ作るより、目的を絞ったダッシュボードを複数作成してください。 signoz-creating-dashboards は呼び出しごとにダッシュボードを 1 つ作成し、テンプレートカタログもテクノロジーごとにすでに整理されているため、オーケストレーションで判断するのは どのダッシュボードを組み合わせるか です。通常はカテゴリ／対象者ごとに分け、ダッシュボードごとにサブスキルを 1 回呼び出します。

• サービス／RED（APM）： KPI タイルに加え、リクエストレート、エラー、p50／p95／p99。オンコール担当者が最初に確認するダッシュボードです。
• インフラ／USE： インフラ監視が有効になっている場合（フェーズ 1 の Q3 の回答）のみ、CPU、メモリ、再起動、ネットワークを表示します。フェーズ 3 で確認した属性で絞り込みます。通常は既成のテンプレート（hostmetrics、k8s）を独立したダッシュボードとしてインポートします。
• 下流の依存関係： サービスに外部依存関係がある場合（フェーズ 1 の Q1 の回答）のみ、依存関係ごとのクライアントスパン p99 とエラーレートを表示します。フェーズ 3 で見つけた依存関係属性でグループ化します。
• ビジネス／SLO： SLI 比率とエラーバジェットを表示し、マルチテナントの場合はテナントごとの内訳も表示します（フェーズ 3）。集計値だけのパネルでは、単一テナントでの障害が見えなくなります。

分割することで、各ダッシュボードの表示が速く、目的が明確になり、適切な対象者（SRE、アプリ開発者、プラットフォーム担当者）が管理できるようになります。**分割すると中身がほとんどないダッシュボードがいくつもできてしまう場合に限り、1 つにまとめてください。**小規模なサービスなら、数個のパネルを 4 つの 2 パネルダッシュボードに分けるより、1 つのダッシュボード上の行としてまとめた方が見やすくなります。各ダッシュボードでフェーズ 1.5 の「既存のものを拡張するか、新規作成するか」の確認は引き続き行い、並行するダッシュボードを追加するのではなく、既存のものを再利用します。

品質基準（作成するすべてのダッシュボード）： 午前 3 時に対応する担当者が使う本番環境向けの設定とし、各パネルに「何に注意すべきか」の説明と詳細へのドリルダウンを付け、各ダッシュボードのページ上部に「ここから始める」を用意します。この意図を伝え、signoz-creating-dashboards に適用させてください。

フェーズ 7：保存済み Explorer ビュー

作成手順については signoz-managing-views に引き継ぎます（ビューのペイロードと extraData／selectColumns の形式はこのスキルが担当します）。オーケストレーションで判断するのは、どのビューを用意するかです。ビューはパネルより手軽で、インシデント対応中に最もすばやく確認できる画面です。

• サービスの ERROR／FATAL ログ。
• API リクエストの一覧：サーバースパンに対する Traces の リスト ビュー（kind_string = 'Server'。フェーズ 3 に従って確認）。サービス／オペレーション（または http.route）／http.response.status_code／所要時間／trace_id を表示するリクエストごとのテーブルです。これは「エンドポイントが今どうなっているか」を最もすばやく確認できる画面です。レイテンシまたはステータスで並べ替えられ、ワンクリックでトレース全体を表示できるうえ、以下の失敗スパン／低速スパンの各ビューを絞り込む前の広範なビューとなります。
• 正規のオペレーションにおける失敗スパン（has_error = true）。
• 低速スパン（duration_nano > <threshold>）。
• 失敗したサブフロー（エラーのある OAuth リクエストなど）。
• 相関ドリルダウン：trace_id を含むエラーログ（ログの急増から直接トレースに移動）と、ログに戻るリンクがある低速／エラーのトレース。

引き継ぐ際に伝える、フェーズをまたぐ制約は 2 つあります。すべてのビューにダッシュボードと同じ環境／テナントのフィルターを適用し、prod と staging の行が混在しないようにすること。また、選択する列について、フェーズ 4 と同じ PII／識別子を含めないための基準を満たすことです。

Phase 8: アラート

signoz-creating-alerts は、アラートごとの仕組みすべてを担います。チャネルの解決（displayName によるルーティング、オプトイン形式のテスト通知、シークレットの取り扱い）、重大度のデフォルト、op／matchType、単位、注釈、evalWindow／recoveryTarget、異常検知ルールの形式、必須のドライランが含まれます。アラートごとに一度だけ使用し、ここではその内容を繰り返さないでください。 （signoz-explaining-alerts はルールを読み返し、signoz-investigating-alerts はアラート発火後に根本原因分析を行います。）

このオーケストレーションレイヤーが、そのスキルに追加する内容は次のとおりです。

• SLI に紐づくアラートは、固定しきい値ではなくバーンレートのペアです。 比率に対する固定しきい値は頻繁に発報するため、Phase 2 の SLO に紐づくものにはバーンレートのペアをデフォルトとして使用します。
• バーンレートのレシピ（SLO がなければ signoz-creating-alerts が導き出せない唯一のものです）。ルールの形式ではなく、入力値を渡します。不良／全体イベントの定義（生のトレース集計より、Phase 3 の signoz_calls_total によるエラー／全体の分割を優先）、Phase 5 の長期＋短期ウィンドウの長さ、発火目標の burnRate × (1 − SLO) です。これらの入力値に加えて、判断すべきことが 2 つあります。長期と短期のウィンドウは、両方に AND を適用する1 つのルールとして評価する必要があります（独立した 2 つのルールでは、短期的なスパイクのたびに通知されます。SigNoz のバージョンで短期ウィンドウによる確認を 1 つのルール内で表現できない場合は、長期ウィンドウだけを設定し、その旨を明記してください）。また、取り込まれたデータに明確な不良／全体の分割が存在しない場合、バーンレートはまだ構築できないため、壊れたルールを出力するのではなく、ベースラインに合わせて調整したしきい値に切り替えてください。バージョンに適したルールの形式は signoz-creating-alerts と signoz://alert/* に任せてください。creating-alerts の「過去 1h に N 回発火するはずです」という較正では 6h／3d のバーンレートウィンドウを評価できないため、そこで「発火回数 0 回」と表示されても、調整済みと判断しないでください。実際の較正は Phase 9 の「1 週間後に再調整する」ループで行います。
• バーンレートでカバーできるのは比率 SLI だけなので、比率以外の障害モードにも対応してください。 サービスがテレメトリの出力を停止した場合や、トラフィックが急減した場合は、エラーバジェットが消費されません（ボリュームがゼロだと SLI 比率は未定義です）。そのため、バーンレートのペアでは通知されません。完全な構成には、主要シグナルに対するテレメトリの存在確認／データ欠落アラートと、独立したシグナルとしてのトラフィック／スループットを追加します。これらの意図を signoz-creating-alerts に渡してください。ルールの形式（データ欠落、異常検知、しきい値）と正常なゼロ値の扱いはこのスキルが担います。オーケストレーションで判断するのは、これらを一式に含めることだけです。
• まとめて作成し、順序を守る。 ルールからチャネルを参照する前に、チャネルを解決／確認します（Phase 5 のマッピング）。その後、メトリクスごとに 1 つずつルールを作成するのではなく、ルーティング階層ごとにまとめてアラートを作成します。
• 手動 TODO の範囲。 抑制ルール、組織レベルの通知ポリシー（usePolicy: true はポリシーをオプトインするだけです）、メンテナンスウィンドウは SigNoz UI／Terraform で設定します。これらのツールでは作成できません。TODO として記載し、完了したと報告しないでください。

Phase 9: 引き継ぎ

次の情報を人間に引き継ぎます。

• ダッシュボード ID、ビュー ID、アラート ID。webUrl は、その値が MCP ツールから正確に返された場合のみ含めてください。それ以外は ID を返してください。ID やテナントのホスト名からフロントエンド URL を組み立ててはいけません。
• 解決できなかった未解決の質問。明示的な TODO として引き継いでください。
• 調整が必要になる可能性のあるベースライン（例：「今日のツールエラー率は 5.1% です。99% SLO 向けに調整したバーンレートアラートは時折発火するため、データを 1 週間蓄積してから再調整してください」）。

避けるべきこと

• チャンネル名やWebhook URLをでっち上げること。 代わりにユーザーに確認してください。
• SLIに紐づくアラートに固定のしきい値を設定すること。 現在の標準はバーンレートの組み合わせです。比率に固定しきい値を設定すると、アラートが頻繁に発生・解除を繰り返します。
• ダッシュボードのサイズを適切に調整しないこと。 12個で足りるのに18個のパネルを詰め込んだり、1つにまとめたほうが見やすいのに2パネルのボードを4つに分けたりしないでください。まずカテゴリ別に分けてから、それぞれのサイズを適切に調整してください。
• 時間を節約するためにドライランを省略すること。 作成時の500エラーは、ドライラン時よりもデバッグが困難です。
• メトリクスごとにアラートを1つずつ作ること。 メトリクスごとではなく、ルーティング層ごとにグループ化してください。
• メトリクス系列にカーディナリティの高いラベルを付けること。 メトリクスのコストが増大します。トレースやログに移してください。
• フロントエンドURLを合成すること。 MCPからwebUrlが提供されている場合はそれを返し、提供されていない場合はリソースIDのみを返してください。
• SLIの分母にスキャナーのトラフィックを含めること。 スキャナーのトラフィックは実際のものですが、ユーザーのトラフィックではないため、除外してください。
• 調査で得た知見を使い捨てにすること。 ベースライン、カーディナリティ、エラー数はしきい値と調整のベースラインを決めるため、破棄しないでください。どのホストでも失われない形で保持してください。数値を成果物（パネルやダッシュボードの説明、アラートの注釈）とフェーズ9の引き継ぎ資料に組み込みます。これらはすべてSigNozに保存してください。ローカルのメモファイルに頼らないでください。
• AIが作成した計装を監査せずにリリースすること。 実際に何が出力されているかを抜き取り確認してから、それを前提にダッシュボードを設計してください。