signoz-creating-alerts

アラートの作成

自然言語の意図から SigNoz アラートを作成します。自律型エージェントと 対話型クライアントは、同じフローに従います。

前提条件

このスキルは SigNoz MCP ツール（signoz_create_alert、 signoz_list_alert_rules、signoz_get_field_keys など）を呼び出します。これらが 利用可能であることを確認してください。利用できない場合は signoz-mcp-setup を実行してください。 生の HTTP に切り替えたり、アラート設定を捏造したりしないでください。

使用する場面

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

• 新しいアラートルールを作成、設定、または構成する。
• メトリクス、ログ量、レイテンシ、またはエラー率がしきい値を 超えたときに、ページ通知または通知を受け取る。
• サービス、ホスト、またはシグナルの異常な動作を検出する。
• 気づかれないデータ損失を検出する（「X からデータが届かなくなったらアラートを出す」）。

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

• 既存のアラートが何を監視しているかを確認する → signoz-explaining-alerts。
• 既存のアラートが発火した理由を診断する → signoz-investigating-alerts。
• 既存のアラートのしきい値、クエリ、またはルーティングを変更する → 直接 signoz_update_alert を呼び出します。

必須入力（厳守）

アラートの作成は共有システムに書き込みます。厳格な入力要件を適用してください。 推測すると、誤ったサービスに対してノイズの多いアラートが作成されます。

入力	必須	不足している場合の情報源
アラートの意図（自然言語での目的）	はい	$ARGUMENTS または直近のユーザー発言
リソース属性フィルター（例：service.name、k8s.namespace.name、host.name）	はい	signoz_get_field_keys + signoz_get_field_values で検出
しきい値	しきい値／PromQL ルール	妥当なデフォルトを導き出してプレビューに表示します。ただし、値が指定されていないリクエストに値を補ってはいけません
重大度	意図から推定	ステップ 5 の 重大度のデフォルト値 に従って解決
通知ルーティング	はい	直接指定：確認済みのチャネル表示名。ポリシー：既存の組織ポリシーがこのルールに適用されることの確認

必須入力が不足しており、検出もできない場合は、書き込みを行う前に中止し、 ホストがサポートする確認 UI を通じて質問してください。

質問に含める内容：

• 不足している情報：具体的に示します（例：「使用するリソース属性 フィルター」）。
• 検出によって得られた候補リスト：属性ごとに具体的な値を示します。例： service.name → frontend、checkout、payments； host.name → prod-api-1、prod-db-1。
• ユーザーが見つからなかった値を指定できる自由入力欄。

自律モードでは、上位のコンテキストを使うか、上位にエスカレーションしてください。推測した値で signoz_create_alert を呼び出してはいけません。

ワークフロー

ステップ 1：意図を解析し、不足情報を確認する

ユーザーのリクエストから次の情報を抽出します。

1. 監視対象：シグナルの種類（メトリクス／ログ／トレース／例外） と具体的な条件（CPU、エラー率、p99 レイテンシ、ログ数など）。
2. リソースの範囲：対象のサービス、ホスト、名前空間、または環境。
3. しきい値：数値と比較条件（「80%を超える」、「100/sを下回る」）。
4. 重大度：ユーザーが指定した重大度と、緊急度を示す表現 （「ページ通知して」、「参考までに」）を記録します。最終値はステップ 5 で決定します。
5. ルーティング：直接指定されたチャネル名、または既存の組織通知ポリシーを 使用する明示的なリクエスト。

シグナルの表現をアラートタイプに対応付けます。

ユーザーの表現	alertType	シグナル
メトリクス、CPU、メモリ、レイテンシ、リクエストレート	METRIC_BASED_ALERT	メトリクス
ログ、エラーログ、ログ量、ログパターン	LOGS_BASED_ALERT	ログ
トレース、スパン、p99 レイテンシ、遅いリクエスト	TRACES_BASED_ALERT	トレース
例外、スタックトレース、クラッシュ	EXCEPTIONS_BASED_ALERT	（clickhouse_sql）

リソースの範囲が不足している場合は、検出を実行します（ステップ 2）。検出後も不足している場合は、 中止してユーザーに確認してください（上記の必須入力を参照）。

Step 2: リソース属性とメトリクス名を確認する

ユーザーがサービス／ホスト／名前空間を指定していない場合は、SigNoz MCP のガイドラインに従い、必ずリソース属性フィルターを優先してください。推測するのではなく、候補を確認します。

1. 選択したシグナルのリソース属性を列挙するため、fieldContext=resource を指定して signoz_get_field_keys を呼び出します。
2. 最も可能性の高い属性（通常は service.name、次に host.name、その次に k8s.namespace.name）について signoz_get_field_values を呼び出し、具体的な値を取得します。
3. ユーザーがメトリクス名を指定した場合は、検索語を指定して signoz_list_metrics を呼び出し、正確な OTel メトリクス名を確認します。名前が間違っていると、アラートが一度も発火しません。

確認の依頼では候補を提示してください（上記の必須入力を参照）。候補を選ばないでください。

Step 3: 重複するアラートを確認する

対象範囲が確定したら（ユーザーから指定された場合も、Step 2 で確認した場合も）、データを調査したり新しい設定を作成したりする前に、既存のアラートを確認してください。ユーザーが既存のルールを更新したい場合は、どちらも無駄な作業になります。

signoz_list_alert_rules を呼び出し、すべてのページをページネーションで確認してください。全件を確認し終えるまでは、pagination.hasMore は true です。これは設定済みのアラートルール（永続的な状態）を一覧表示します。現在トリガー中／アクティブなアラートインスタンスを返す signoz_list_alerts は使用しないでください。これは、設定済みでも現在発火していないルールを見落とすためです。ユーザーの意図に合致する既存ルール（同じシグナル、同じ対象範囲、類似のしきい値）がないか確認します。重複の可能性が高いルールがある場合は、そのルールを提示し、新しいルールを作成するか、既存のルールを変更するか（ここでは対象外です。signoz_update_alert を使用してください）、またはキャンセルするかを尋ねてください。

Step 4: 選択したフィルターでデータの存在を確認する（早期に失敗させる）

アラート設定を作成する前に、アラートが監視する具体的な組み合わせ（メトリクス × サービス × その他のフィルター）で、実際にデータが出力されていることを確認してください。最もよくあるサイレント障害は、「メトリクスがカタログにあり、サービスもカタログにあるが、そのサービスはそのメトリクスを出力していない」というものです。それぞれを個別に確認すると問題がないためアラートは正常に保存されますが、サイレントに一度も発火しません。

アラートで使用するものと同じフィルターを使い、データが存在することを確認できる最も単純な集計で、過去 1 時間分のプローブを 1 回実行します。

• メトリクス：具体的な metricName とアラートの filter を指定して signoz_query_metrics を使用します。集計のデフォルト値は自動的に適用されます。完全な v5 ツールが必要な場合は、metricName、timeAggregation、spaceAggregation を含むメトリクス集計オブジェクトを使用します。メトリクスでは、count() などの式による集計や、フィルターのみのプローブは受け付けられません。
• ログ：aggregation: "count" とアラートのフィルターを指定して signoz_aggregate_logs を呼び出します。count() は Query Builder の式であり、ヘルパーツールの引数ではありません。
• トレース：aggregation: "count" とアラートのフィルターを指定して signoz_aggregate_traces を呼び出します。aggregation: "count()" は渡さないでください。

結果を確認します。

• プローブで行が返る → Step 5 に進みます。
• プローブで何も返らない → 中止します。ユーザーが後で破棄するよう求められるアラート設定を作成しないでください。中止してユーザーに確認し（上記の必須入力を参照）、不足している内容を説明したうえで、具体的な復旧方法を提示します。
  • サービスがそのメトリクスを出力していない → signoz_get_field_values signal=metrics name=service.name metricName=<metric> を呼び出して、そのメトリクスを実際に出力しているサービスを一覧表示します。ユーザーに別のサービスまたは別のメトリクスを選んでもらいます。
  • 属性名が誤っている（service ではなく service.name） → セマンティック規約に沿った名前を提案し、再度プローブします。
  • サービスはメトリクスを出力しているが、想定した時間範囲には出力していない → データがないと判断する前に、プローブの対象期間を一度だけ延長します（例：過去 24 時間）。

**例外：ログベースのクラッシュ／パニック／OOMKilled／FATAL アラート。**これらは正常なシステムでは意図的に一致が 0 件になります。プローブが空の結果を返すのは想定どおりです。中止せず、0 件だったことを示して、保存前にユーザーに確認を求めます。この例外は、「問題発生時に通知する」ログクエリに限定して適用してください。継続的なデータフローに依存するアラートには適用しません。

Step 5: アラート設定を作成する

アラート JSON スキーマ、しきい値コード、検証ルールの正規の情報源は MCP サーバーです。標準となる現行バージョンの形式を確認するため、signoz://alert/instructions および signoz://alert/examples の MCP リソースを読みます。

Threshold/PromQL の condition.thresholds には kind（"basic" を使用）と、空ではない spec[] が必要です。現行の v2 では、alertOnAbsent のみをトリガーとして表現することはできません。データ欠損のみを対象とするリクエストの場合は、書き込みを行う前に中止し、明示的な承認を得た場合にのみ、しきい値ルールとデータ欠損ルールを組み合わせる方法を提案します。異常検知ルールでは、しきい値を省略します。

ほとんどのユーザーの意図は、次のような少数のパターンに分類できます。

パターン	インテントの例
単一メトリクスのしきい値	「CPU が 80% を超えたらアラート」「p99 レイテンシが 2s を超えたら」
ログ量のしきい値	「エラーログが 1 分あたり N 件を超えたら」
トレースベースの件数またはパーセンタイル	「checkout のスパン時間の p99 が 2s を超えたら」
エラー率の式（A/B*100）：下記の「一般的なクエリ形式」を参照	「エラー率が 5% を超えたら」
異常検知（Z-score）	「異常なトラフィックを検知したらアラート」
しきい値とデータ欠損の組み合わせ（承認後のみ）	「データの到着が止まったらアラート」
ClickHouse SQL アラート：signoz://alert/examples のスキーマを使って SQL を作成	複雑な結合、ビルダーでは表現できないカスタム集計
PromQL アラート：クエリを signoz-generating-queries に依頼してから、ここに戻る	ユーザーがすでに PromQL を持っている場合
しきい値の op と matchType の値。 次の op の語を使用します：above、
below、equal、not_equal、above_or_equal、below_or_equal、および
outside_bounds。equals は無効です。異常検知ルールには above を使用します。絶対スコアによって急増と急減の両方を捉えられます。

比較	op	評価の動作	matchType
above / exceeds / >	"above"	いずれかの時点でしきい値を超過	"at_least_once"
below / under / <	"below"	ウィンドウ全体でしきい値を超過	"all_the_times"
equal / =	"equal"	平均値がしきい値を超過	"on_average"
not equal / !=	"not_equal"	合計値がしきい値を超過	"in_total"
		最後の値がしきい値を超過	"last"

スキルが適用するデフォルト値（プレビューにも表示）：

• evalWindow: 5m0s、frequency: 1m0s：意図からより遅い、または速い間隔が示される場合のみ変更します。
• CPU／メモリ／レイテンシの matchType: "on_average"：一時的な急増を平滑化します。
• エラーカウント／エラー率の matchType: "at_least_once"：あらゆるしきい値超過を検出します。

重大度のデフォルト値。 各しきい値レベルの重大度は、次の順序で決定します。

1. 以下の表で最初に一致する行を使用します（手がかりがなければ、該当するものを使用）。一致する行がなければ warning を使用します。
2. ユーザーの手がかりがデフォルト値を上書きします。名前付きの重大度（「critical」、「80% で warning」）は緊急度を示す手がかりより優先されます。「ページャーで通知して」「起こして」「緊急」は critical に設定します。「参考情報のみ」「ページャー通知なし」「優先度低」はデフォルト値を1段階下げます（critical は warning、warning は info、info は info のまま）。特定のしきい値に紐づく手がかり（「90% でページャー通知」）は、そのレベルのみに適用されます。同じレベルで緊急度を示す手がかりが矛盾する場合は、質問してください。
3. 各しきい値レベルの名前には重大度を使用し、labels.severity は最も高いレベルに設定します。SigNoz のアラートルール一覧では、この値で並べ替えや絞り込みが行われます。発火するすべてのアラートにこのラベルが付くため、複数レベルのルールでは、どのレベルが発火したかを示すのは threshold.name のみです。異常検知ルールにはレベルがありません。SigNoz では、ラベルがレベル名として使われます。ステップ8のプレビューには、各レベルの重大度とその理由が表示されます。

アラートの意図	デフォルトの重大度
単発のクラッシュイベント（OOMKilled / CrashLoopBackOff / panic / FATAL ログ行）	critical
本番サービスの停止／データなし	critical
SLO バーンレート	14.4×以上：critical、6×以上14.4×未満：warning、6×未満（例：チケットレベルの1×）：info
しきい値が1%を超えるエラー率	critical
件数のしきい値を超えるエラーログまたは例外の件数	warning
レイテンシの悪化（p95／p99 が目標を超過）	warning
CPU／メモリ／ディスクの負荷	warning
リクエスト率／トラフィックの異常	warning

例：「チェックアウトのエラー率が2%を超えたらアラートを出して」は、（エラー率の行により）critical です。同じリクエストに「参考情報のみ」を加えた場合は warning です。

属性名：signoz_get_field_keys が返す正確なキーを使用します。通常、利用可能な場合は service ではなく service.name などの OTel 名を使用します。

アノテーションのテンプレート：変動する値を含めます。オンコール担当者が見るのは通知であり、設定ではありません。

• summary：1行の見出しです。リソースの対象範囲と数値を含めます："checkoutservice error rate {{$value}}% above 3%"。
• description：より詳しいメッセージです。{{$value}}、{{$threshold}}、groupBy の値（例：{{$labels.service_name}}）と、何をすべきか、またはどこを確認すべきかを示す文を含めます。件数ベースのアラートには、件数を明記します："{{$value}} crash log lines in the last 5 minutes from service {{$labels.service_name}}"。

しきい値を超えた値には {{$value}}、目標値には {{$threshold}}、groupBy の値には {{$labels.<key>}} を使用します（SigNoz ではドットを含む属性名がアンダースコアに置き換えられます：service.name → service_name）。

一般的なクエリ形式：規約

すべてのパターン（エラー率、p99 レイテンシ、ログ量、データ欠損、異常、PromQL、ClickHouse SQL）の正規 JSON については、signoz://alert/examples を参照してください。スキーマに含まれていない規約は次のとおりです。

• エラー率の計算式： コンポーネントクエリ A と B に disabled: true を設定し、アラートのグラフと通知には計算式 F1 だけが表示されるようにします。生のカウント値は中間値であり、アラートのシグナルではありません。設定し忘れると、プレビューに 3 つの系列が表示されて煩雑になり、通知を読むオンコール担当者を混乱させます。
• p99 レイテンシ： クエリの出力単位はナノ秒ですが、しきい値はユーザーの単位で指定します（例：target: 2、targetUnit: "s"）。SigNoz は評価時に単位を変換します。
• 低トラフィック時のパーセンタイルガード： パーセンタイルクエリの having.expression に count() > N を設定し、stepInterval は要求されたバケットサイズにします（例：「1 分ごと」の場合は 60）。A * (B >= N) のような計算式の中に比較演算子を含めないでください。
• ログ量の急増： ユーザーが「任意のサービス」と指定した場合、ハードフィルターよりも groupBy: service.name を優先します。groupBy は対象範囲を設定し、サービスごとに有用な通知を維持します。

ステップ 6：クエリ全体をドライランし、しきい値を検証する

ステップ 4 ではデータが流れていることを確認しました。ステップ 6 では次の 2 点を行います。

1. クエリ形式を検証します。 完全なビルダー仕様（groupBy、計算式、無効化されたコンポーネントクエリ、文字列以外のフィルターを含む）を実行します。ステップ 4 の単純な count() プローブでは、これらを検証できません。create-alert スキーマは、評価時にエラーになるクエリ（数値の groupBy、引用符で囲まれていない bool フィルター、集計の不一致）も受け入れます。HTTP 5xx または「filter type mismatch」が発生した場合は、(2) に進む前に設定を修正してください。計算式のコンポーネントクエリ（A * 100 / B の A、B）に disabled: true を設定するのは、失敗ではなく推奨されるパターンです（ステップ 5 を参照）。
2. しきい値を調整します。 検証済みのクエリを使った場合、過去 1 時間に妥当な回数だけアラートが発火するでしょうか。

過去 1 時間を対象に、主要なクエリ全体（または計算式）を実行します。

• すべてのビルダー、計算式、PromQL クエリには signoz_execute_builder_query を使用します。適切な値（builder_query／builder_formula／promql）を compositeQuery.queries[].type に設定してください。アラート用 PromQL 仕様には name／query／legend／disabled のみを指定します。ドライラン実行用 PromQL 仕様には step／stats も指定できます。それでもビルダー専用の stepInterval は省略してください。 文字列を spec.query に設定し、SigNoz が要求する UTF-8 の引用符付きセレクター形式（アンダースコア形式や引用符なしのドット形式ではなく、{"metric.name.with.dots"}）については signoz://promql/instructions を参照してください。また、アラート用 PromQL は完全にリテラルにし、$var、$__rate_interval などのダッシュボード変数が評価されないようにします。
• アラート仕様では時間範囲を省略しますが、このドライランでは指定が必要です。外側のクエリの start／end に絶対 Unix ミリ秒の JSON 整数を設定してください（例：現在時刻−3600000 → 現在時刻）。設定しないと signoz_execute_builder_query は missing start or end timestamp で失敗します。
• 意図したディメンションでグループ化する場合、各実行時の groupBy[].name にはステップ 2 のキー（例：k8s.pod.name）を正確に指定し、空欄にしないでください。それ以外の場合は groupBy を省略します。
• より適している場合は、signoz_aggregate_logs／signoz_aggregate_traces を使用します。
• アラートクエリが metricName で指定された既知の単一メトリクスを対象とする場合は、signoz_query_metrics を使用します。このツールは集計のデフォルトを自動適用し、filter、groupBy、formula も併用できます。ここでは PromQL はサポートされていません。その場合は signoz_execute_builder_query を使用してください。 永続化するすべてのアラートとドライラン対象のビルダークエリまたは数式には、正の値の limitと、空でないQuery Builder v5のorderが必要です。単独のクエリと数式の結果には100を使用します。数式の各入力には、評価前に適用されるため10000を使用します。無効な数式を含むすべての数式式から入力を見つけ、すべてのビルダークエリのリーフまで参照をたどります。この探索で設定するのは上限であり、数式の評価順序ではないため、複合クエリ全体をドライランしてください。同じ仕様を維持し、入力のカーディナリティが10000を超える可能性がある場合は、フィルターやグループ化を絞り込みます。

提案されたしきい値に違反した評価ポイントの数を計算します。プレビューには**「過去1時間にN回発火する可能性があります」**と表示します。 1時間のウィンドウではほとんどのアラートを評価するには短すぎます。対応が必要なのは極端なケースだけです：

• Nが大きい（例：> 30） → アラートストームの可能性があります。表示し、しきい値を厳しくするか、ヒステリシス（recoveryTarget）を追加することを推奨します。
• N = 0 → 正常なシステムでは想定内です。しきい値を緩めるよう促してはいけません。ユーザーが、たとえば進行中のインシデント中に、今すぐアラートが発火すると予想していると言った場合にのみ通知します。
• Nが小さく、ゼロではない → 回数を報告し、しきい値が適切かどうかはユーザーに判断してもらいます。1時間では「適切に調整されている」か「一時的な事象をかろうじて捉えた」かを区別できません。

3. 例外：
   • 異常検知アラート：異常検知のfunctions変換を適用せず、基になるメトリクスクエリを実行してデータの形状と内容を確認し、その後、違反回数のカウントは省略します（Zスコアは生の値と直接比較できません）。異常検知スコアではなく、基になるクエリを検証したことを明示してください。
   • ログベースのクラッシュ／パニック／OOMKilled／FATALアラート：正常なシステムでは、これらの一致件数がゼロになるのが意図された動作です。ステップ4ですでに一致件数ゼロを提示し、ユーザーの確認を得ています。違反回数のカウントは省略してください。

何らかの理由でステップ4が省略された場合（例：下流のスキルがこのフローの途中から呼び出す場合）も、ここではデータなしの場合の停止ルールが適用されます。結果が空なら停止してユーザーに確認し、発火しないアラートを保存するのは避けてください（上記の必要な入力を参照）。

ステップ7：通知ルーティングを解決する

ドライランと最終的な重大度の確定後、直接ルーティングか組織ポリシーによるルーティングかを選択します。チャンネルがないからといって、ポリシーによるルーティングが許可されるわけではありません。

しきい値ルール／PromQLルールに対する既存の組織ポリシーが確認済みの場合は、notificationSettings.usePolicy: trueを設定し、確認済みのマッチャーラベルとしきい値ティアを維持し、しきい値のチャンネルとpreferredChannelsは省略します。このスキルではポリシーを作成しません。ポリシーまたは一致条件が確認されていない場合は、停止してユーザーに確認します。異常検知ルールは直接ルーティングのみです。一致条件がseverityでティアを振り分ける場合は、停止してユーザーに確認します（ステップ5）。すべてのティアが最上位として一致します。threshold.nameマッチャー、ティアごとのルール、または直接ルーティングを提案してください。

直接ルーティングの場合は、同じ操作で完全にページネーション済みのチャンネル結果を再利用するか、hasMore=falseになるまでsignoz_list_notification_channelsをページングします。totalはフィルター適用後の一致件数です。機械向けのnameではなく、変更されないdisplayNameを使って一致させ、ルーティングします。ユーザーに選択を求める際は、displayNameとkindを提示してください。作成を提案する場合は、ユーザーが提供した設定だけを使用し、自動作成は決して行いません。signoz_create_notification_channelの引数は、サポートされるプロバイダー種別と識別フィールドを定義する現在の入力スキーマに基づいて構成します。プロバイダーの設定はconfig内に指定し、フラットなフィールドにはしません。テスト通知を希望するかユーザーに尋ね、同意した場合にのみtest: trueを送信します。PERMISSION_DENIEDが返された場合は、管理者が作成したチャンネルを使用するか、ホストのシークレットストアにある、存続期間が短く最小限のロールを持つ認証情報を使用します。ルーティングを解決できない場合は、停止してユーザーに確認します。

各しきい値のchannelsには、返された表示名を正確に指定します。異常検知ルールではトップレベルのpreferredChannelsを使用します。一方のルーティングフィールドを他方の代わりに使用してはいけません。

シークレットを含むチャネル設定の更新または取り扱い

signoz_update_notification_channel は完全置換です。id を解決し、チャネルを取得して、config 全体をコピーし、要求されたフィールドを変更してから、id と完全な config を送信します。name や displayName は送信も変更もしないでください。認証情報と実効値の sendResolved は、値をそのまま返さずに保持してください。種類を変更する場合は、新しいプロバイダー設定全体が必要です。更新テストには明示的なオプトインが必要です。

書き込み成功後に要求されたテストが失敗した場合は、変更の実行状況とテストの状態を分けて報告してください。書き込み後に mutationCommitted: true を伴う認証エラーが発生した場合は、id を保持し、認証後に確認してください。変更やテストを再実行しないでください。トランスポートの成功だけでは、プロバイダーへの最終配信が成功した証拠にはなりません。

Slack の webhook URL、PagerDuty のインテグレーションキー、および同様の webhook トークンはシークレットです。ユーザーがこれらをメッセージに直接記載した場合は、不透明な入力として扱い、次のルールに従ってください。

• シークレットをそのまま返さないでください。 チャット出力、プレビュー、確認メッセージ、要約、または <navigation_suggestions> ペイロードに、webhook URL、インテグレーションキー、パスワードに類するトークンを決して含めないでください。チャネルは displayName だけで示し（「Slack チャネル Platform Alerts を作成しました」など）、値は完全に省略してください。
• シークレットを確認用のコンテキストに保存しないでください。 ユーザーがシークレットを貼り付けた後で追加の質問が必要になった場合、ホストが再開時に保存する可能性のある確認用の message、discovered_context、その他のフィールドにシークレットの値を含めないでください。記号的に言及してください（例：「先ほど提供された webhook」）。
• 一度だけ渡してください。 シークレットを signoz_create_notification_channel に直接渡し、中間の文章に保持しないでください。作成呼び出しが成功したらチャネルを表示名で示し、失敗した場合は、ユーザーが送信した値をそのまま返さず、再入力を依頼してください。
• ユーザーが代わりに「Slack チャネルの設定方法を教えて」と尋ねた場合： これはチャネル作成の依頼ではなく、ドキュメントについての質問です。SigNoz UI の Notification Channels ページを使う手順を案内し、チャットでシークレットを求めないでください。トークンを公開することにユーザーが不安を感じている場合は、UI の手順を優先してください。

ステップ 8：準備した設定をプレビューする

作成される内容を、平易な言葉で一段落にまとめて出力します。生の JSON ダンプは出力しません。ユーザー向けに、何が、どの範囲で、どのしきい値で発火し、どこに通知されるかという情報を要約に記載します。JSON を確認してもクエリ形式の誤りは見つかりません（ステップ 6 のドライランで確認します）。

要約：[リソースの範囲]について[条件]を満たしたとき、このアラートが発火します。[頻度]ごとに、直近[ウィンドウ]を対象として評価されます。重要度：[ティア]。その理由：[テーブルの行またはユーザーの意図]。しきい値： 警告は X、重大は Y です。通知先：[直接指定したチャネル／確認済みの組織ポリシー]。直近 1 時間のドライラン：N 回発火する見込みです。

ステップ 9：保存して報告する

1. ステップ 8 の設定を使って signoz_create_alert を呼び出します。
2. 名前の競合：signoz_create_alert が重複名エラーを返した場合、名前に接尾辞を追加したり、signoz_update_alert を呼び出したりしないでください。 停止し、既存のアラートが作成を妨げたことをユーザーに伝え、別の名前を使うか、既存のアラートを変更する方法を提案してください（既存アラートの変更はこのスキルの対象外です）。
3. 成功したら、次の内容を報告します。
   • アラート ID と名前。
   • 監視対象、しきい値、重要度。
   • 通知先（直接指定したチャネル、または確認済みの組織ポリシー）。
   • ドライランの要約（「直近 1 時間に N 回発火する見込み」）。

ガードレール

• 推測より厳密な入力を優先 リソース属性と通知ルーティングは必須です。直接ルーティングにはチャネルが必要です。ポリシールーティングでは、既存の一致が確認済みであれば、直接チャネルは不要です。
• signoz_list_alert_rules は必ずページネーションする 1ページ目で止めると重複を見落とし、ノイズが発生します。
• ドライランは必須 signoz_create_alert の前にステップ 4 と 6 を完了してください。一度も発火しないアラートは誤った安心感を与えます。
• しきい値演算子には正規の語句を使用する equals ではなく、ステップ 5 の op と matchType の語句を使用してください。
• シグナルは alertType と一致させる signal: "logs" には LOGS_BASED_ALERT が必要です。一致しない場合、検証に失敗します。
• 異常検知ルールはメトリクスのみ anomaly_rule とメトリクス以外の alertType の組み合わせは拒否されます。
• ルーティングは確認必須です。 直接ルートでは、ページネーションを完了した signoz_list_notification_channels から返された正確な displayName 値を使用します。しきい値／PromQL ルールではしきい値ごとの channels に、異常検知ルールではトップレベルの preferredChannels に設定してください。確認済みのポリシールートでは notificationSettings.usePolicy を設定し、直接チャネルのフィールドは省略します。
• チャネルのシークレットを絶対に再掲しないでください。 Slack の Webhook URL、PagerDuty のインテグレーションキーなどの Webhook トークンはシークレットです。これらは signoz_create_notification_channel に一度だけ渡し、チャットの出力、プレビュー、確認、要約、確認用ペイロード、ナビゲーションの提案では値を再掲しないでください。作成後はチャネルを表示名のみで参照してください。失敗した場合は、ユーザーに再入力を依頼し、送信された値を再掲しないでください。

例

4 つの標準的なアラートフロー（複数の重要度に対応したメトリクスしきい値、エラー率の数式、groupBy を使用したログ量、異常検知）は、references/examples.md にあります。

追加リソース

• MCP リソースの signoz://alert/instructions と signoz://alert/examples：完全なアラート設定 JSON スキーマ、しきい値コード、フィルター式の構文、現行バージョンのパターン例が含まれています。転記したものより、常にこちらを優先してください。
• signoz-generating-queries スキル：PromQL の作成や、アラートに組み込む前のクエリのテストに使用します。