アラート

Yagra は、アラートの品質を最優先に設計しています。目的はアラートを送ることではありません。正しい アラートを送ることです。

目指しているのは、次の状態です。本当のインシデント 1 件につき、呼び出しは 1 回。拠点が落ちても、 アラートの洪水にはならない。メトリクスが 1 サンプルだけしきい値をかすめたくらいでは、午前 3 時に 鳴らない。

ヒステリシス、フラッピング検知、依存関係の抑制、重複の除去は、常に配信経路の中にあります。あとから 有効にする追加機能ではありません。「とにかくアラートを送る」ためにこれらを迂回する手段も、用意して いません。

エスカレーションとオンコールの当番表は、意図的に外部のツールに任せています（PagerDuty、Jira Service Management）。Yagra が出すのは、発報と解消というライフサイクルの信号だけです。自前の エスカレーションの仕組みは持ちません。

アラートのライフサイクル

アラートを発報させるものは 3 つあります。

• 死活の失敗 — デバイスが ICMP プローブに応答しなくなる（あるいは URL / DNS モニタが成功 しなくなる）。これは組み込みの挙動ではなく、初期投入されたアラートルールです。連続回数を 編集でき、プロファイル・グループ・ノード単位で上書きでき、削除するとノードダウンの通知が 止まります（監視を参照）。
• しきい値の超過 — ゲージメトリクスがルールの warning または critical の境界を越える（しきい値 のモデルは監視を参照）。
• イベントルールの一致 — パッシブイベント（syslog、トラップ、Webhook）がオペレーターの定義した ルールに一致する（後述のイベント由来のアラートを参照）。

きっかけが何であれ、すべてのノードのすべてのチェックは確定した状態を持ちます。

状態	意味
ok	チェックは正常です
warning	しきい値ルールの warning 境界を超えています
critical	しきい値ルールの critical 境界を超えています
unreachable	死活が失敗しています — ノードが応答しません
unknown	Yagra は現時点で判断を持っていません（直近のサンプルがない）
maintenance	ノードがメンテナンスウィンドウの中にあります

重大度を持ち、アラートを生むのは、問題を表す 3 つの状態だけです。warning、critical、 unreachable です。ok、unknown、maintenance からアラートは生まれません。まだ様子が 分からないノードや、計画作業中のノードは、インシデントではないからです。

新しく追加したノードや、コアを再起動した直後には、unknown が短い間だけ見えます。アラート エンジンが全ノードについて判断を作るまでの状態です。サンプルが届けば、自然に消えます。

アラートは、チェックが問題状態を確定したときに発報します（確定するまでの仕組みは、次の ヒステリシスです）。そして同じ経路を通って、チェックが回復したときに解消します。

解消のしかたは、ほかに 3 つあります。どれも「障害が直った」という意味ではありません。ノードが メンテナンス期間に入ると、そのノードで開いているアラートは解消します。閾値ルールを消すと、その ルールが上げていたアラートは解消します。そして、ノード自身は現に報告を続けているのに、その アラートの元になる系列だけ 6 時間 1 件もサンプルが無い場合も解消します。最後のものは「Yagra が もうこれを測れていない」と読んでください。回復したという意味ではありません。後ろの 2 つは 5 分ごとの定期処理が行います。どちらも通常の解消と同じくアラート履歴に記録されるので、PagerDuty や Jira Service Management のインシデントも一緒に閉じます。

インターフェースの利用率・通信量のアラートは、値が届かなくなっただけでは閉じません。値が 来なくなったポートのアラートは、開いたまま残ります。たとえば、ping には答えるのに SNMP の エージェントだけ止まった機器、途中で打ち切られた walk、Dashboard が埋めなかった Meraki の枠です。 どれも同じように見えるので、開いたアラートがそれを知らせます。アラートが閉じるのは、ポートが 上限の内側に戻ったことを示す値が届き、ルールの dwell（何回続いたら状態を変えるかの回数）を 通ったときです。消えたインターフェースのアラートは、ルールかノードを消すまで開いたままです。

同じ問題が繰り返し発報しても、まとめて 1 つのインシデントにします。重複が並ぶことはありません。

発報と解消は、すべて追記だけのアラート履歴に残ります。原因になった測定値も、発報した時点の値 のまま保存されます。

ドウェル時間によるヒステリシス

生のサンプルがしきい値を越えても、それだけで確定した状態は切り替わりません。状態が確定してアラート が発報するには、超過が決められた回数だけ連続する必要があります。この回数をドウェルと呼びます。

途中で正常な値のサンプルが 1 つでも入れば、そこでリセットされます。連続の数え直しです。

これが、境界を一度かすめただけのメトリクスや、1 回の ping 欠落で誰かを呼び出さずに済む仕組みです。 たとえばドウェルが 3 なら、そのノードのポーリング間隔で、超過のサンプルが 3 回続く必要があります。 途中に回復のサンプルが 1 つ入れば、カウントはやり直しです。

インターフェース使用率のアラートと、計算で出すメトリクス（メモリやディスクの使用率）のアラートは、 1 分に 1 回評価します。ポーリング間隔が 1 分より長いノードでは、この回数は分の数ではなく、 ポーリングの回数です。1 分より速いノードは、これまでどおり分の数を数えます。

実時間ではなくサンプルの数で数えることには、設計上の帰結があります。アラートの評価は、常に今 流れているサンプルに対して行われます。あとから埋め戻された過去のデータが、アラートとして評価し 直されることはありません。たとえばリモートポーラーがつながり直してバッファを送り直した場合です。

理由は単純で、ためこんだものを再生すると、すでに解消したインシデントの遷移を作り出してしまうから です。ですからメトリクスは埋まりますが、アラートは現在から再開します。

フラッピング検知

数分おきに上下するリンクは、そのたびに技術的には正しいアラートを生みます。そしてその 1 本 1 本が ノイズです。

Yagra は、一定の時間幅の中で、チェックごとに確定状態が何回変わったかを数えます。その回数がしきい値 に達したチェックには、その遷移についてフラッピングの印を付けます。

時間幅は、ノードのポーリング間隔に合わせて決まります。長さはポーリング 20 回分で、10 分より短く はなりません。その中で状態が 5 回変わると、フラッピングとみなします。10 分固定の幅では、5 分間隔の ノードに 5 回の変化が収まらないからです。

フラッピングしているチェックは、ダッシュボードウィジェットの Flapping watchlist に出ます。 ノードの名前（id はホバーで見られます）と、そのチェックが何を測っているかが分かります。

おかげで不安定なリンクは、上下のたびに切り分けをやり直すのではなく、1 つの問題としてまとめて 直せます。

もっと深く調べたいときは、Troubleshoot のカタログを使ってください。フラップ分析が、ノード・ グループ・フリート全体を対象に、到達性とリンク状態の揺れを調べます。対になる分析もあり、そちらは 同じノードで発報と解消を繰り返しているイベントルールを見つけます。

依存関係抑制

拠点のルータが死ぬと、その背後にあるものはすべて見えなくなります。抑制の仕組みがなければ、その ノードの 1 台 1 台があなたを呼び出します。

Yagra は、依存関係グラフをもとに抑制します。各ノードには自分の上流を設定でき、グラフは Network map 上で見られます。

あるノードが unreachable になり、その上流もダウンしている場合、アラートはダウンしている中で いちばん上の祖先に帰属します。つまり根本原因です。子のアラートは、その親のインシデントに まとめられます。

子のアラート自体は発報しますし、UI にも履歴にも残ります。止まるのは、重複した通知だけです。 トポロジのビューと、依存関係・根本原因のダッシュボードウィジェットにはこの帰属が表示されます。 ですから 1 つのインシデントを、影響範囲つきの 1 件として読めます。

抑制は、親の状態が変わるたびに評価し直されます。定期的にではなく、変化をきっかけに動きます。 しかも両方向に働きます。

• 子がすでにアラートを上げたあとで親がダウンした場合、その既存のアラートを親のインシデントの 下へまとめ直します。子の単独の呼び出しは閉じられます。
• 子がまだダウンしているうちに親が回復した場合、その子を単独で呼び出し直します。もう親では説明が つかないからです。

抑制が嘘をつかないよう、意図的な制限を 2 つ設けています。

• 抑制するのは、死活のアラートだけです。しきい値のアラートは抑制しません。到達できるノードで 本当にしきい値を超えているなら、それは呼び出されるに値するからです。
• パッシブイベントから上がったアラートも、抑制しません。イベントを送ってきたばかりのデバイスは、 明らかに到達できているからです。

依存関係の線は、WebUI から編集できます。ノード詳細のヘッダーにある Dependency… から、その ノードの上流を設定したり外したりできます。

トポロジ ▸ 依存関係では、すべてのノードを一覧できます。上流、現在の状態、現在の根本原因の 帰属が並び、その場で編集できます。自分自身への依存と、循環する依存は拒否されます。

Yagra にグラフを導出させる

ノードごとに上流を手入力していく方式は、規模が大きくなると続きません。そして誰も保守しなくなった グラフは、間違ったものを抑制します。

そこで Yagra は、依存関係グラフを ネットワークマップから導き出せます。向きは、 各ノードがポーラーからどれだけ離れているかで決まります。1 ホップ近いほうが上流です。

トポロジ ▸ 依存関係に、3 段のモードスイッチがあります。位置が勝手に動くことはありません。 アップグレードしても、今のモードのままです。

• 手動作成のグラフ — 既定です。既存のデプロイはすべてここに留まります。

• 比較 — アラートの挙動は何も変えません。導き出したグラフと手動のグラフが、どのノードで食い 違うかを表示します。

  あわせて、切り替えて安全かを判断するための数値を 2 つ出します。導出グラフにすると新たに抑制 されるようになるアクティブアラートの数と、逆に抑制されなくなる数です。前者が危険な方向で、 1 件ごとに「上がらなくなるアラート」を意味します。

• 導出したグラフ — 抑制の判断を、導出したグラフに任せます。

導出グラフにできて、手入力の parent_id にはできないことが 2 つあります。

1 つは、複数の親を持てることです。ノードには、ポーラーに 1 ホップ近い隣接がすべて親として付き ます。ですから冗長なルータ 2 台を経由して届くサーバーは、両方を親に持ちます。どちらかが生きて いる限り、アラートは上がり続けます。「すべての親が落ちたときだけ抑制する」という規則は、 もともとこのために書かれたものです。

もう 1 つは、抑制しないという設定です。これを付けると、その 1 台を導出による抑制から完全に 外せます。グラフが何と言おうと、そのノードのアラートは単独で立ちます。この設定は抑制を外す方向 にしか働かないので、障害が報告されなくなる原因にはなりません。

導出が間違ったリンクを作ったときは、回避策ではなく判断を記録してください。リンクをピン留めして 存在させる、非表示にする、どちらが上流かを宣言する、のいずれもできます。これらは再計算のたびに、 導出結果より優先されます。

配置できないポーラーがあると、切り替えは拒否されます

向きを決めるには、各ポーラーがどこにいるかを知る必要があります。ところがコンテナの中で動く ポーラーは、どの監視対象ノードとも一致しないコンテナネットワークのアドレスを報告します。これは 例外ではなく、普通に起きる状態です。

対処として、設定 ▸ ポーラーでアンカーノードを指定してください。

ノードを持つプールに、配置できないポーラーが 1 台でもある間は、導出グラフへの切り替えを拒否 します。そのプールには根が 1 つも無いので、画面上は機能が有効に見えたまま、実際には何も抑制され ない状態になってしまうからです。

メンテナンスウィンドウとミュート

どちらも呼び出しを止めます。似ているのは、そこまでです。2 つはパイプラインの別々の場所で 止めており、あとに残る記録を書き換えるのは片方だけです。

• メンテナンスウィンドウは、アラートそのものを止めます。開いているウィンドウの中にある ノードは、maintenance の状態になります。この状態は重大度を持たないので、何も発生しません。 すでに上がっていたアラートは解決します。

  これは「これは障害ではありません」と言うための手段です。計画作業、予定された再起動、配線の やり直しなどに使います。ウィンドウの開閉は Operator 以上の操作です（メンテナンス管理の権限）。

• ミュートは、配送だけを止めます。アラートは普通に発生します。Active alerts に並び、 ノードの状態も変わり、確認（ACK）もでき、アラート履歴にも書かれます。起きないのは通知だけです。

  これは「障害だと分かっています。ただし誰も起こさないでください」と言うための手段です。すでに 誰かが対応している機器や、しきい値の見直し待ちでうるさいチェックに使います。ミュートは確認 （ACK）と同じく、Operator ロールのインシデント対応の権限に含まれます。

	メンテナンスウィンドウ	ミュート
アラートが発生するか	しない	する
ノードの表示状態	maintenance	変わらない — 落ちていれば落ちたまま
Active alerts に出るか	出ない	出る
アラート履歴に残るか	残らない	残る
確認（ACK）できるか	対象がない	できる
通知が配送されるか	されない	されない
適用範囲	ノード / デバイスプロファイル / タググループ / フォルダグループ（再帰）	ノード / フォルダグループ（再帰）
ノードより細かく指定できるか	—	できる — そのノードのチェック 1 本単位
時間の指定	予定として作成。名前・開始・終了を持ち、先の日時を登録できる	今から、指定した時刻まで

この選び方がいちばん効いてくるのは、1 か月後です。稼働率の集計もアラート履歴も、「記録されたもの」 から作られるからです。

メンテナンスウィンドウは、計画作業をインシデントの記録から丸ごと外します。ミュートは経緯をすべて 残します。そのとき誰にも知らせなかった、という事実も含めてです。

使い分けはこうです。止まると分かっていて、記録に数えたくないならウィンドウ。本当に落ちていて、 電話だけ止めたいならミュートです。

補足が 2 つあります。

• ミュートは、解決の通知までは止めません。 アラートが発生したあとにミュートを掛け、そのあと 復旧した場合、解決の通知は配送されます。そうしないと、対応中に掛けたミュートが、PagerDuty や Jira Service Management のインシデントを閉じる手段まで奪ってしまうからです。
• メンテナンスは、イベント由来のアラートも黙らせます。 開いているウィンドウの中にあるノード から届いた syslog や trap は、ポーリング結果と同じく何も発生させません。

どちらも専用の設定ページを持ち（Alerts ▸ Maintenance windows / Alerts ▸ Mutes）、監査の対象に なる正式な機能です。あとから通知に取って付けたフィルタではありません。

ツリーからの設定と解除

どちらも、インベントリから直接設定できます。Nodes ▸ All nodes でノードまたはフォルダグループ を右クリックし、期間を選んでください。細かく決めたいときは Custom… でフォームを開きます。

止められている行には、マーカーが付きます。メンテナンスは 🔧、ミュートは 🔕 です。このマーカーは ボタンでもあります。

クリックすると、その行を黙らせているものがパネルに出ます。ウィンドウの名前、それがその行自身の ものか上位のフォルダグループから受け継いだものか、そしていつ終わるかです。1 つの行が複数のものに 同時に覆われることもあり、その場合はそれぞれ別に並びます。

パネルが出す操作は、止めている元がどこかで変わります。次の 3 つは、それぞれ別の行為だからです。

• その行自身を名指しているウィンドウは、削除ではなく今すぐ終了します。終了時刻が今の時刻に 移るだけです。ですから Maintenance windows のページには「実際に行われた作業の記録」として残り、 あとから「clear ended」ボタンでまとめて片付けられます。その行を名指しているミュートのほうは、 そのまま解除されます。

• 受け継いでいるだけのウィンドウやミュートは、その行から終了させると、同じグループの他のノード まで解除してしまいます。そこでノードには、代わりに除外を出します。「このノードをメンテナンス対象 から外す」「このノードをミュート対象から外す」です。

  そのノードだけが通常のアラートに戻り、グループの残りは止まったままになります。除外は、元になった 抑止が終わると自動的に切れます。抑止が予定より早く終わった場合も同じです。ですから除外が元の理由 より長生きして、次のウィンドウからそのノードが黙って抜け落ちることはありません。

• 上位グループのウィンドウで覆われているグループでは、原因を読み取り専用で表示し、どのグループ 側で解除すればよいかを示します。子の行から上位のウィンドウを終了できてしまうと、そこからは見え ない範囲まで抑止が解けてしまうからです。

マーカーは、2 つの状態を描き分けます。抑止が効いている行は、塗りつぶしのチップです（メンテ ナンスは青、ミュートは黄）。そこから外れている行は、色が抜けて破線の枠になります。

つまり除外中のノードは、「抑止が何も無いノード」とは見た目から違います。まだウィンドウの範囲内に いて、1 クリックで戻せます。

通知の配信

アラートがヒステリシス・抑制・メンテナンスの各チェックを生き延びると、通知の配信がその行き先 を決めます。Yagra が配信できるのは次のとおりです。

チャネル	備考
Webhook	汎用の HTTP Webhook。リトライあり
Email（SMTP）	リトライあり。リレー、送信者、認証情報を設定可能
PagerDuty	Events API v2
Jira Service Management	Alerts API

すべてのチャネルが、発報と解消の両方を受け取ります。ですから Yagra 側でアラートが解消すれば、 外部ツール側のインシデントも閉じます。古いインシデントが残って、手で片付ける羽目にはなりません。

外部ツールで行われた確認（ACK）は、読み取り専用で Yagra に反映されます。どのチャネルへ通知するか はルーティングルールが選び、「通知の配信」の設定ページで管理します。

配信は、結果を取り込む経路から切り離して動きます。遅い通知先や応答しない通知先は、自分の通知を 遅らせることはあります（再試行します）。しかしその裏で、メトリクスの取り込みやアラートの評価を 止めてしまうことはありません。

外向きの Webhook は、監視プローブと同じように SSRF から守られています。ループバック、リンク ローカル、クラウドメタデータ宛の対象は拒否されます。

ノードのタグはアラートと一緒に出ていき、各ベンダーが元々用意している欄に入ります。PagerDuty は payload.custom_details.yagra_tags（リスト）、Jira Service Management は自前の tags です。 「JAPAN の付いたものは日本の当番を呼ぶ」は、Yagra 側で二重に書くのではなく、それらのツール 自身のルーティングルールに一度書けば済みます。送られるのはノードが 実効的に 持つタグで、 そのノード自身のものとインベントリフォルダの連なりが与えるものの合計です。Webhook とメールは テンプレートが求めたときだけ載せます。下を参照してください。

Jira Service Management が受け取るタグは、アラート 1 件につき最大 20 個、1 個 50 文字までです。 Yagra はこの上限の中で送ります。長いタグは短くせず、送らずに外します。短くしたタグが、別の ルールに当たってしまうことがあるためです。残りのタグは先頭の 20 個を送ります。並びはノード自身の タグが先で、フォルダから受け継いだタグが後です。JSM のルールで振り分けに使うタグは、短く、数を 少なくしておいてください。

通知テンプレート

チャネルごとに、送信する件名と本文を上書きできます。アラートの決まった変数集合（ノード名、 アドレス、グループ、プロファイル、重大度、メトリクス、しきい値、観測値、ノードの実効タグ tags、アラートが指す表の行の名前 row_name（メモリプールなど）、発報か復旧か）に対する Jinja2 テンプレートとして書きます。 人が読むための変数も 4 つあります。title はアラートの名前です（snmp_up ではなく SNMP not responding）。if_name は、ポートのアラートが指すポートの名前です。node_label は ノード名で、アドレスと違うときはアドレスを括弧で添えます。alert_label はアラートの名前に、 ポートまたは行を続けたものです。条件分岐が使えるので、 重大度やライフサイクルイベント、タグごとに文面を変えられます:

{% if event == 'resolve' %}復旧{% else %}{{ severity | upper }}{% endif %}: {{ node_name }} ({{ group }})
{% if 'JAPAN' in tags %}[JP rota]{% endif %} tags: {{ tags | join(', ') }}

テンプレートを設定していないチャネルは、Yagra の組み込みの文面をそのまま送ります。タイトルは どの種類のチャネルでも同じです。機器の名前とアラートの名前を出します。たとえば core-sw-01 (192.0.2.11) is critical: SNMP not responding です。ポートのアラートは、ポートの 名前も出します（… : Inbound utilization on GigabitEthernet0/7）。それ以外は、誰が読むかで変わります。

• Webhook と PagerDuty はプログラムが読むので、本文はアラートの JSON です。タイトルは PagerDuty の要約（summary）になります。
• メールと Jira Service Management は人が読むので、本文は文章です。本文はタイトルを繰り返し、 そのあとに 1 行に 1 つずつ中身を並べます。ノード、フォルダ、プロファイル、アラートの名前、 メトリクスとその値・しきい値、ポートまたは行、重大度、状態、いつからか、タグ、アラートのキーです。

Jira Service Management には、同じ中身を追加プロパティ（details）としても送ります。テンプレートの 有無には関係ありません。JSM はこれを表で見せ、JSM のルールはこれで条件を書けます。

テンプレートを書く前に知っておくとよい性質が 2 つあります。

• テンプレートが壊れていても、通知は失われません。 アラートの発報時に組み立てられなかった場合、 そのフィールドは組み込みの文面に戻り、通知そのものは送られます。組み立てに失敗する原因は、たと えば不正なフィルタ、出力が大きすぎる、JSON を送るチャネルで本文が正しい JSON でなくなった、 などです。

  戻すときの処理は単純な文字列置換です。たった今失敗したエンジンを、もう一度通すことはしません。

  テンプレートの結果が空、または空白だけになったフィールドも、組み込みの文面のままになります。 そのため、復旧のときだけ自分の文面にして、発報のときは Yagra の文面を使う、という書き方ができます。

• テンプレートは隔離された場所で動きます。 テンプレートが触れるのは、渡された変数だけです。 ファイルも、include も、他のテンプレートも参照できません。実行するステップ数にも上限があるので、 暴走したループが通知の処理を止めてしまうことはありません。

編集画面は、アラート ▸ 通知の配信 ▸ チャネル ▸ 通知テンプレートを編集にあります。 欄は、そのチャネルが送るものに合わせて並びます。Jira Service Management はタイトルと本文、 メールは件名と本文、PagerDuty は要約（summary）と custom_details、Webhook は JSON の本文 1 つだけで、 件名はありません。

テンプレートの無いチャネルは、Yagra の組み込みの文面を読み取り専用で開きます。今届いている文面を そのまま見られます。この文面をもとに書き換える を押すと、その文面から書き始めます。空の欄から書く を 押すと、何もない状態から書き始めます。テンプレートを持つチャネルは、画面の上でそう示します。 組み込みの文面に戻す… は、確認のあとでテンプレートを消します。

メールと Jira Service Management では、見たまま編集する画面になります。変数は文中の札になり、 日本語の名前と説明が付きます。発報・復旧・上流の障害にまとめたとき、の 3 つはタブで書き分けます。 書かなかったタブには、発報の文面が届きます。札で表せないテンプレートは、理由を添えてコードの 編集画面で開きます。Webhook と PagerDuty は本文が JSON でなければならないので、いつもコードの 編集画面です。コードの編集画面で 改行と字下げを送らない をオンにすると、改行と字下げは読むためだけのものに なり、送られません。どちらの画面でも、4 種類の見本アラートでその場のプレビューを見られます。 画面の大きさは、端をドラッグして変えられます。

チャネルが本当に届くかを確かめるには、同じ画面のチャネルの操作 テスト通知を送る を使います。 Yagra は見本のアラートを 1 回だけそのチャネルで送ります。件名の頭には [TEST] が付きます。 届いたかどうかは画面に出ます。PagerDuty と Jira Service Management では本物のインシデントが開くので、 当番に 1 回通知が届きます。そのインシデントは数秒後に Yagra が閉じます。テスト送信は再送しません。 無効にしたチャネルでも送れます。

ルーティングルールは、作ったあとで直せます。ルールの操作 ルールを編集 で名前・重大度・チャネルを 変えられます。有効か無効かは、そのまま残ります。

配信ログ

同じ画面に 配信ログ があります。チャネルへ送った通知 1 件ごとに 1 行です。対象は発報・復旧・ 巻き上げ・テスト送信です。行ごとに、届いたかどうかが分かります。届かなかったときは、どこで 失敗したかも分かります。

失敗した場所	意味
Yagra 側	何も送る前に止まった。たとえば、送り先のアドレスを断った。
経路	送ったが、何も答えなかった。タイムアウト、接続の拒否、DNS、TLS など。
相手側	相手のサービスが答え、受け取りを断った。

失敗した行には、相手が返したステータスと、返答の先頭 512 文字が残ります。チャネルの URL・ ホスト・キーは <redacted> に置き換わります。行を開くと、再送のすべてが見られます。

チャネル・種類・結果・失敗した場所・時刻で絞り込めます。環境変数で決める既定の送り先にも、 絞り込みの項目があります。チャネルの行メニューの 配信ログを見る は、そのチャネルで絞った 配信ログを開きます。

配信ログを読むには 「デプロイの管理」 が必要で、これは管理者だけが持ちます。同じ行は GET /api/v1/notification-deliveries と、MCP のツール get_notification_deliveries からも 読めます。行は、アラート履歴と同じ保持期間だけ残ります。設定は 設定 ▸ 監視の既定値 ▸ データ保持期間 の「通知の配信ログ」です。

記録のせいで通知が待たされることはありません。PostgreSQL の書き込みが追いつかないときは、行を 捨てて yagra_notification_delivery_log_dropped_total に数えます。重複として送らなかった通知は、 何も送っていないので記録しません。

UI を触らずに、デプロイ全体で固定の送り先を持たせたいこともあります。そのために、環境変数で決める チャネルが 2 つあります。

YAGRA_WEBHOOK_URL は、常に有効な既定の Webhook を決めます。設定済みのチャネルと並んで、すべての アラートで発火します。YAGRA_SMTP_* 系の変数は、既定のメール経路を決めます。詳しくは 設定リファレンスを見てください。

イベント由来のアラート

アラートは、ポーリングだけから来るわけではありません。パッシブイベント — syslog メッセージ、SNMP トラップ、受信 Webhook — も、運用担当が決めたイベントルール（部分一致または正規表現）で判定 され、一致したルールはアラートを上げられます。

受信した SNMP トラップは、トラップの OID が人の読める名前に変換されます。組み込みのトラップ用 イベントルールも最初から入っているので、よくあるトラップは設定なしで、名前の付いたアラート可能な イベントとして届きます。取り込み側はパッシブイベントで 扱っています。

イベント由来のアラートは、ポーリング由来のものと 2 つの点で違います。

• TTL（有効期間）で解消します。 単発のイベントには、見るべき「回復のサンプル」がありません。 ですから各ルールが、自動で解消するまでの時間を持ちます。アラートは、その時間が過ぎたときに 閉じます。手動で閉じることはできません。
• 依存関係の抑制を通りません。 イベントを送ってきたばかりのデバイスは到達できているので、 「ダウンしている」親の下でそのアラートを抑えるのは、誤りだからです。

1 つのイベントストリームに限定したルールは、その限定を守ります。このバージョンのコアが知らない ソース種別のルールは、黙ってすべてのストリームへ広がることはありません。照合の対象から外され、 ログに記録されます。

監視自身が暗くなったとき

ここまでのアラートはすべて、ポーリングの結果が届くことを前提にしています。ですからポーラーが いなくなることは、アラートエンジンが判断できない唯一の障害です。

ポーラープールが最後の生きたポーラーを失うと、そのジョブ は誰も聞いていないサブジェクトへ流れて消えます。ノードは down ではなく unknown へ流れていきます。 拠点がまるごと監視から外れているのに、どのダッシュボードも平穏に見えます。

Yagra は、この状態を直接監視します。ノードを抱えたまま生きたポーラーが 0 台になったプールは、それ 自体が critical のアラートを上げます。配信は他のアラートと同じ通知チャネルとルーティングルール を通り、ポーラーが戻れば自動的に閉じます。

• 通知だけでなく、通常のアラートとして扱います。 Active alerts とアラート履歴に出て、ライブの ストリームに流れ、通知テンプレートで描かれます。

• 既定では 5 分待ちます。 ポーラーは終了するときに自分から離脱を伝えるので、普通のローリング 再起動でも条件はすぐ成立してしまいます。この待ち時間は、そのたびに誰かを呼び出さないためのもの です。YAGRA_POOL_COVERAGE_ALERT_AFTER_SECS で調整でき、無効にもできます （設定）。

• 主体はノードではなく、プールです。 どの機器のものでもない唯一のアラートなので、ノードの表示 状態には丸め込まれません。ミュートもできません。ミュートはノードを名指しする機能だからです。

  API を使うクライアントは、アラートの node フィールドをノード ID として読む前に、subject_kind で分岐してください。

• Meraki 管理のノードは対象外です。プールのリングに割り当てるのではなく組織の単位で収集するので、 プールに依存しません。これを受け持つのは、下のアラートです。

アラートを有効にしていてもいなくても、ゲージは 2 本とも出ます。yagra_pools_without_live_poller （ラベル無し。アラートや増設のきっかけにするのはこちらです）と、 yagra_pool_nodes_without_live_poller{pool} です。後者は健全なプールでも系列が消えず、0 を 報告します。

Cisco Meraki の組織にも、理由は違いますが同じ問題があります。 Meraki のデバイスには ping を打ちません。Dashboard API が報告する内容が、Yagra の知るすべてです。 収集が失敗したとき——キーの失効、Dashboard の停止、レート制限、外に出られないポーラー——以前は 結果が 1 つも publish されず、その組織のデバイスは全部が最後の状態のまま残り、何も鳴りませんでした。

ここも Yagra が直接見張ります。可用性の収集が 3 回続けて答えを得られなかったとき、その組織に ついて critical のアラートが 1 つ上がります。

• デバイスごとではなく、1 つだけです。 主体は組織なので、これもどのノードのものでもありません。
• 閉じるのは証拠が届いたときだけで、沈黙では閉じません。 収集が答えれば閉じますが、報告が来なく なっただけでは閉じません。再起動の直後は何も分かっておらず、何も分からないことは何も閉じません。
• デバイスは最後に収集できた状態のままです。壊れたわけではないからです。該当するノードの Overview に、Meraki API が応答していないこと、その理由、画面の状態をいつ取得したかが出ます。
• 上がるのは可用性の段だけです。 可用性が答えているのにアップリンクやトラフィックだけが失敗して いる状態で失うのは値であって死活ではないので、組織のページに出るだけで、アラートにはしません。
• グループを限定したアカウントには、その組織のノードが見えるグループに 1 台でも在れば見えます。

つまり API を使うクライアントが subject_kind で出会う値は 3 つになります——ノード、プール、そして Meraki の組織です。

アラートの扱い

• Active alerts は、いま何が起きているかを見て振り分けるための画面です。発報中のアラートを 新しい順に並べます。1 行に、重大度、ノードの名前（id はホバーで見られます）、アラートの名前と どう超過したか、そして経過時間が出ます。たとえば「ping の応答時間」の後ろに、しきい値と実測値が続きます。 Yagra が知っているメトリクスには、すべて英語と日本語の名前があります。行の最後には元のメトリクス名を 小さく残すので、ルールと突き合わせられます。0 か 1 で読むチェックは異常そのものを名前にし （SNMP が応答しない）、条件は出しません。ポートのアラートは、ポートの名前も出します。

  一覧は必要な行だけを描くので、大きな障害で数千件が同時に上がっていても、滑らかに動きます。 トップバーの通知ベルにはアクティブな件数が出て、押すとこの画面が開きます。各ノードの詳細ページ にも、そのノードのアラートが出ます。

• アラートの**確認（ACK）**は、対応中であることを示す運用担当の操作です（インシデント対応の権限、 Operator 以上）。確認は取り消せます。ロールと権限は ユーザーと SSOで扱います。

• アラート履歴は、すべての発報と解消を追記だけで残した記録です。

  各行の「What」列には、発報した時点で捉えたメトリクスと条件が入っています。ですから発報の元に なったしきい値ルールをあとから編集しても、削除しても、履歴は本当のことを言い続けます。

  アクティブアラートと履歴は、同じ整形処理を通して測定値を描きます。ですから 2 つの画面が食い違う ことはありません。

運用担当の操作 — 確認、ミュート、メンテナンスウィンドウの開始 — は、他の状態を変える操作と同じ ように監査ログに残ります。ですから「誰が、何を、いつ黙らせたか」には、いつでも答えられます。

同じ操作は、Yagra の MCP ツール経由で AI や自動化のクライアントからも実行できます。権限の確認も 監査の記録も、人が操作した場合とまったく同じです。

関連ページ

• 監視 — このパイプラインへ流れ込むチェックとしきい値。
• パッシブイベント — syslog、SNMP トラップ、Webhook と、 アラートを発報させるイベントルール。
• ユーザーと SSO — 本ページのオペレーター操作の背後にある ロール。