監視

Yagra は ICMP・SNMP・HTTP(S) でネットワーク機器やサーバーを能動的に監視し、数万規模のノードにわたって死活・性能・しきい値を見張ります。本ページでは、何が収集されるのか、ノードがどのようにチェックの集合へ解決されるのか、そしてポーリングエンジンがどう振る舞うのかを説明します。チェックが異常になったあと何が起きるかはアラートを参照してください。

監視の対象

Yagra が見張るものはすべてノードですが、すべてのノードがルータというわけではありません。ノードの種別は設定の仕方から決まります — 別途保守するラベルではなく、そのノードに紐づいた監視から導出されます。

種別	内容	付与されるチェック
Device	IP アドレスを持つネットワーク機器やサーバー	常に ICMP 死活監視。認証情報と収集セットが解決できれば SNMP 収集も
URL	HTTP(S) エンドポイントの監視	HTTP プローブ 1 本 — ICMP はなし（CDN の背後など、対象が ping に応答しないことがあるため）、SNMP もなし
DNS	名前解決の監視	DNS プローブ 1 本 — 名前はそれ自体のアドレスを持たないため
Meraki	Cisco Meraki 組織から取り込んだデバイス	組織単位で Meraki Dashboard API 経由で収集するため、ノードごとのポーリングジョブは発行しません

ノードが複数の形に当てはまる場合は、より具体的な種別が優先され、その順序は Meraki → URL → DNS → Device に固定されています。4 つの種別はいずれも同じインベントリツリーに属し、同じダッシュボードを共有し、同じアラートパイプラインへ流れ込みます。

種別は作業する画面上で見分けられます。インベントリツリーでは名前のうしろに、ノードのページではタイトルの横に、短い URL / DNS / Meraki バッジが付きます。通常のデバイスは無印なので、バッジは「これは別物として読む」という意味になります。ノードのページに並ぶタブも、その種別で中身を持ちうるものだけです — URL / DNS 監視に Interfaces・Neighbors・Flow はありません。SNMP を walk されることも、フローのエクスポーターになることもないからです。概要も、その種別が値を持ちうる項目だけを並べます（DNS 監視なら、メーカーやモデルの空欄 4 行ではなくリゾルバが出ます）。API も同じ値を返します — GET /api/v1/nodes の kind、および MCP のノード系ツールです。

ICMP

すべての Device ノードは ICMP 死活監視の対象になります — 常に有効で、認証情報も不要です。プローブは到達性とラウンドトリップ時間（icmp_rtt_ms）を記録し、これはノード詳細でグラフ化でき、しきい値ルール（たとえば RTT が 100 ms 超）でも使えます。応答しなくなったデバイスは unreachable 状態へ遷移して死活アラートを発報しますが、これはアラートで説明するヒステリシスと依存関係抑制のロジックに従います。

ICMP は raw ソケットを使うため、ポーラーコンテナには NET_RAW ケーパビリティが必要です — 同梱の Compose ファイルは（ポーラーにだけ）これをすでに付与しています。

SNMP

デバイス監視の深さは SNMP から来ます。Yagra が話せるのは次のとおりです。

SNMP v2c — コミュニティベース。
SNMP v3（USM） — 認証とプライバシー。

どちらのバージョンでもスカラーメトリクス（CPU、メモリ、セッション数など）を収集し、マルチインデックステーブルを含むテーブルをウォークします。インターフェースごとのメトリクスは GETBULK によるインターフェーステーブルのウォークから取得され、これは v2c ノードでも v3 ノードでも同じです。そのため v3 しか許可しない機器でもインターフェースごとのカウンタが収集できます。1 つのノードのテーブルウォークは 1 回のポーリングにつき 1 つの SNMP セッションにまとめられるため、ポート数の多いスイッチでもテーブルごとではなく 1 回の会話で済みます。

ノード詳細では、インターフェースごとのスループットと状態が、共通のレンジコントロール（1 時間〜 7 日間、およびカスタム）を持つスパークラインと時系列グラフとして表示され、インターフェースのグラフには設定帯域の基準線が描かれます。

生カウンタとクエリ時レート

Yagra はインターフェースやエラーのカウンタを生のまま保存します — 前回サンプルとの差分をポーラー側でレートに変換することは一切ありません。レートや使用率はクエリ時・評価時に時系列ストア側で導出され、そこでカウンタのラップやリセットが自動的に検出されます。実運用では、これが 2 つの効果を生みます。

ポーラーはステートレスです。前回値の管理が不要で、ポーラーの再起動やフェイルオーバーのあとに誤ったレートが出ることもありません。
カウンタのラップ（32 ビット）や機器の再起動が幻のトラフィックスパイクを生むことはありません。ラップ／リセットの処理は手書きの引き算ではなく、ストアのレート関数の中にあるからです。

そしてこの設計上、しきい値ルールは生カウンタではなくゲージに掛けることになります — 後述のしきい値を参照してください。

認証情報

SNMP のコミュニティと v3 認証情報は保存時に暗号化され、ログにも API のレスポンスにも出ず、メトリクスのラベルにも使われません。認証情報が紐づいていないノードは、YAGRA_SNMP_COMMUNITY によるデプロイ全体の v2c コミュニティへフォールバックできます — 設定リファレンスを参照してください。

URL 監視

URL ノードは、手作業で確認するときと同じやり方で HTTP(S) エンドポイントを定期的に監視します。

死活とステータス — 期待どおりの HTTP ステータスが返ってきたときにプローブは成功します。期待値は設定可能で、任意の 2xx、明示的なコードのリスト、あるいは範囲を指定できます。
応答時間 — http_response_time_ms としてエンドポイントの応答時間を記録するので、「上がっているか」と「遅いか」を別々に扱えます。計測するのは応答ヘッダまでの時間です。応答が無かったときは何も記録しません — そうしないと障害中ずっと「遅い応答」が平坦に並んでしまうためです。既定のしきい値は種まきしていません。応答時間は環境差が大きすぎて、既定値が正しくなりようがないからです。
応答本文のキーワード照合 — 本文にキーワードが含まれること、または含まれないことを条件にできます。これは死活監視では構造的に見えない障害を捕まえるためのものです — 200 を返しながら、本文には障害を示しているエンドポイントです。照合は正規表現ではなく、大文字小文字を区別する単純な文字列一致で、本文が読み取り上限を超えた場合は「満たさない」と報告します（誤って「正常」と言わないためです）。
JSON 本文からの数値取り出し — 1 監視あたり 8 個まで、任意のメトリクス名で記録できます（キュー長、レプリケーション遅延、ワーカー数など）。指定はドット区切りでちょうど 1 か所を指します（data.queue.depth）。数値でない値はその回に何も記録しません（0 にはしません） — 0 は「値が本当に 0 だった」と区別できないためです。
TLS 証明書の有効期限 — HTTPS 対象では証明書の有効期限を追跡するため、証明書は突然切れるのではなくグラフ上で残りが減っていきます。
TLS 検証は既定で有効です。 無効化はモニタごとの明示的なオプトインです。

プローブは SSRF に対して堅牢化されています。最初の対象およびすべてのリダイレクト先について、フィルタ付きリゾルバ経由でのみ名前解決と接続を行い、ループバック・リンクローカル・クラウドメタデータ宛の接続を（DNS リバインディングの小細工も含めて）拒否します。プライベートや内部のレンジは許可されたままです — NMS がそれらを監視するのは正当な用途だからです。

URL モニタの設定は作成後も完全に編集できます。ノードの URL ヘルスカードにはオーバーフロー（⋮）メニューがあり、Edit と Remove monitoring を選べます。エディタは期待ステータスを含むすべてのフィールドを扱います。監視を削除してもノードはインベントリに残り、記録済みの履歴もそのまま維持されます — プローブが止まるだけです。モニタの変更には、他の監視設定の変更と同じ権限（Admin）が必要です。

DNS 監視

DNS ノードは、URL ノードがエンドポイントを監視するのと同じように名前を監視します。ノードを組み込みの DNS name resolution プロファイルへ紐づけると、Yagra は次を記録します。

名前が解決できるかどうか、そして解決にかかった時間。
dig のような再帰的な CNAME チェーン（その名前が解決されていく経路）。

チェーンの履歴はチェーンが実際に変化したときにだけ追記されます — TTL のカウントダウンやラウンドロビンの並び替えは変化とみなしません — そのため履歴はノイズではなく変更ログとして読めます。数値サマリはグラフ化もアラート化もできます: dns_up、dns_resolve_ms、 dns_chain_length、dns_answer_count です。既定の dns_up しきい値が初期投入されるため、新しい DNS モニタは設定なしでアラートを上げます。

解決に失敗した場合、その理由は内部のエラートークンではなく、英語と日本語の読める文章（たとえば「該当する名前がありません（NXDOMAIN）」）で表示されます。

URL モニタと同じく、DNS モニタもノードの DNS ヘルスカードから作成後に編集・削除できます — リゾルバ、レコードタイプ、その他すべて — 削除してもノードとその履歴は保持されます。

Cisco Meraki

Yagra は読み取り専用の Dashboard API 経由で Cisco Meraki の環境を監視します。 設定 ▸ 連携 ▸ Cisco Meraki で読み取り専用 API キーを使って組織を追加すると、インポートウィザードが組織のネットワークとデバイスを列挙し、何を監視するかを選ばせてくれます。

取り込まれたデバイスは通常のノードになります — Organization → Network のグループツリー下に自動配置され、インベントリでは Meraki バッジが付きます。
収集は組織単位で行われます。ページングされた組織横断の API 呼び出し 1 本で多数のデバイスを賄うため、大規模な環境でも組織の API レート制限に引っかかりません。
収集されるメトリクスには、デバイスの可用性、WAN アップリンクのロス／レイテンシ／状態、クライアント数、トラフィック使用量が含まれ、ノード詳細の Cisco Meraki カードに表示されます。
組織ごとのコントロールで、収集の一時停止と再開、ティアごとのポーリング間隔とリクエストレートの予算の調整、対象ネットワークの編集ができます。グローバルなキルスイッチはすべての Meraki 収集を即座に停止します。

この統合は設計として読み取り専用です。発行するのは HTTP の GET のみで、すべてのリクエストは許可リストされた Meraki API ホストに限定され、API キーは保存時に暗号化されて返却もログ出力もされません。

分散構成では、Meraki のクラウドポーリングジョブは YAGRA_MERAKI_POOL（既定 default）で指定したポーラープールへルーティングされます — 一部の拠点にしかインターネットへの出口がない場合に便利です。分散ポーリングを参照してください。

プロファイルと収集セット

デバイスからどの SNMP データを取るかは、ノードごとにではなく宣言的に決まります。

デバイスプロファイルは「役割 × ネットワーク OS」の分類体系を成します（コアスイッチはファイアウォールではなく、Linux ホストでもありません）。
各プロファイルは編集可能な収集テンプレートを持ち、テンプレートは整備済みで検索可能な MIB/OID カタログを参照します。
プロファイルに紐づいたノードは、そのテンプレートと認証情報を通じて具体的な収集セット — その機器で実際にポーリングされるスカラーとテーブル — へ解決されます。

組み込みのプロファイルとテンプレートは、よくあるベンダーを最初からカバーします — Cisco、Huawei （USG のファイアウォールセッション数やメモリを含む）、Meraki MX/MS、A10 — に加えて標準のホスト MIB とインターフェース MIB も揃っています。いずれも編集・検索が可能なので、新しい機器ファミリへ対応を広げるにはカタログエントリとテンプレートを追加すればよく、コードを書く必要はありません。

収集しているものは、UI が想定したものだけでなくすべて見えます。 ノードの収集タブは、そのノードに届いたメトリクスを全件一覧し、どれでもグラフ化します。これがいちばん効くのは自分で足したカバレッジです — ベンダー固有のテーブル列は収集に成功していても、その名前を知っている画面が書かれていない、という状態でした。各項目は「設定済みでデータあり」「設定済みだがまだ届いていない」「収集項目は無いがデータが届いている」のどれかを示します。最後のものは異常ではありません。到達性、 URL 監視と DNS 監視、隣接数、監視対象の JSON 本文から取り出した値は、収集セットではなくチェック側が生成するためです。カウンタは毎秒レートとしてグラフ化できます — 保存値は積算計の読みであって、それをそのまま描くとトラフィックのように見えて実際は違う上昇線になるからです。

ディスカバリと分類

ノードを 1 台ずつ追加する必要はありません。

ディスカバリは IP レンジやアドレスリストをスイープします。使用する認証情報は保存済みのものから選びます。
Credential Finder は、保存済みの認証情報を値ではなく参照として発見済みデバイスに試し、応答するものを探します — デバイスごとにレート制限され、試した値がログに出ることはありません。
分類ルールは sysObjectID / sysDescr に一致したら該当するデバイスプロファイルを自動適用するため、発見されたデバイスは正しい収集セットが付いた状態で登録されます。
結果はインポートグリッドに並びます。スイープが裏で勝手にノードを追加するのではなく、何をインベントリに入れるかを確認して選べます。

分類ルールはコードではなくデータです — プロファイルの隣に置かれ、同じ場所で編集できます。

ネットワークマップ

ネットワークマップは、機器自身の報告から Yagra が導出した接続関係を描きます — リンクを手で入力する人はいません。各辺は根拠を保持し、マップ上でも凡例でも区別して表示されます:

CDP / LLDP の隣接情報。対向の管理アドレスによって監視対象ノードに突き合わせます。
同一 IP サブネットの共有。同じプレフィクスにインターフェースアドレスを持つ 2 ノードは、事実として隣接しています。
OSPF 隣接、BGP ピア、直結経路。これがサブネットを共有しないリンク — 点対点の /32 （PPPoE の Dialer、トンネル端点）、アンナンバードの OSPF リンク、アドレス情報を収集できていないセグメント越しのピアリング — をマップが見つけられる理由です。

複数の経路で同じリンクが見えた場合も、リンクは 1 本のまま根拠が積み上がります。冗長経路は畳まずに保持するため、2 台のルータ経由で到達するサーバーには 2 本のリンクが出ます。

これらを支える走査は既定で 1 時間周期で動き、設定 ▸ システム設定 ▸ ネットワーク探索の走査に個別のスイッチがあります（隣接情報 CDP/LLDP、インターフェースアドレス、ルーティング隣接 OSPF/BGP、 ARP キャッシュ）。読む表の大きさは機器自身のピア数に比例し、ネットワークの規模には比例しません — ルーティングテーブルを表として歩くことはありません。フルルートを持つルータでは数十万行になるため、Yagra は宛先を 1 件ずつ、しかも自分自身がホストアドレスを持つ機器にだけ、上限 64 宛先で問い合わせます。通常の機器しかないフリートでは経路の問い合わせは 1 件も発生しません。

知っておく価値のある挙動が 2 つあります。セッションが落ちていてもリンクは描かれます — active の BGP セッションは「障害のあるリンク」であり、まさにそれが調査対象だからです。そして ループバック同士の iBGP はリンクになりません。ピアが隣接とみなされるのは、報告した機器が終端しているネットワーク上にピアのアドレスがあるときだけなので、ルートリフレクタが全クライアントへの偽の star を獲得することはありません。

曖昧にせず挙げておく既知の制限: BGP4-MIB は IPv4 専用のため IPv6 の BGP ピアは対象外、OSPF の収集は OSPFv2、仮想リンクは読みません。またメンバーが 3 つ以上あり、どれがルータか特定できないセグメントは、推測でリンクを作らず何も出さずにマップの集計に計上します。

このグラフは、依存関係抑制の切り替え先でもあります。

監視していないホスト

ARP / IPv6 近隣キャッシュの走査を有効にすると、監視中のルータが実際に通信した相手のホストを報告します。在庫に無いアドレスはノード ▸ ディスカバリ ▸ ネットワーク上で観測された端点に、アドレス・MAC・どの機器のどのポートで見えたかとともに一覧され、監視を開始ボタンでサブネットスキャンと同じインポート経路を通ってノードになります。スキャンは不要で、既存のポーリングの副産物として得られます。

発見された端点は意図的にネットワークマップに描きません。監視外のホストは表示すべき状態を持たず、状態の無い箱を数千個描けば状態を持つノードが埋もれるためです。インポートすればノードになり、そこからは通常の導出が拾います。

しきい値

しきい値は、測定値を warning または critical の状態へ変えるメトリクスごとのルールです。境界値、方向（上回る／下回る）、そしてアラートエンジンが評価するドウェルの挙動（アラートを参照）から成ります。

ルールを書く前に知っておく価値のある、モデル上の決まりが 2 つあります。

しきい値はゲージメトリクスにのみ適用できます。 カウンタメトリクス（if_hc_in_octets、エラーや破棄のカウンタ — 収集カタログがカウンタと宣言しているもの）にしきい値を置くと、単調増加する生の累計を境界値と比較することになります。上回るルールはカウンタが境界を越えた時点で永久にラッチし、下回るルールは再起動によるカウンタのリセットのたびに幻のアラートを発報します。そのため Yagra は作成そのものを拒否します（カウンタメトリクスに対する POST /api/v1/thresholds は 400 counter_metric を返します）。すでにあるカウンタのサンプルは OK として読むので、古いルールがラッチさせていたアラートも通常の復旧経路を通って解消されます。カウンタをレートで見たいときは、クエリ側で扱ってください。しきい値はゲージに設定するものです。
しきい値一覧の閲覧には設定管理権限（Admin）が必要です。 単なる閲覧権限では足りません — しきい値の集合は「Yagra がいつ誰を呼び出すか」を記述するものなので、公開ダッシュボードでも閉じたままにします。匿名リクエストには 401 を返します。

自動化向けに、GET /api/v1/thresholds はエンベロープ — { "items": [...], "total": <n>, "truncated": <bool> } — を返し、1 リクエストあたり 500 ルールで上限が掛かります。?limit= はこれを狭められますが広げることはできず、上限に当たったかどうかは truncated で分かります。

ノード種別によっては、作成時に妥当な既定ルールが初期投入されます（たとえば DNS モニタの dns_up）。そのため新しいモニタは設定なしでアラートを上げます。

ポーリング動作

ポーリングエンジンは、フリート規模でも予測可能であるように作られています。

間隔 — 既定のポーリング間隔は 30 秒で、10〜3600 秒にクランプされます。 YAGRA_POLL_INTERVAL_SECS 環境変数が値を投入するのは初回起動時だけで、それ以降はデータベースに保存された設定（WebUI で編集可能）が正となります。デバイスプロファイルごとの間隔でグローバル既定を上書きできます。
ジッタ — 数万のノードが同じティックで一斉に発火してネットワーク（やポーラー）を圧迫しないよう、ポーリング間隔にはジッタが掛かります。
1 デバイスにつき同時に 1 プローブ — 遅いデバイスに対して同時プローブが積み上がることはありません。次のプローブは前のプローブを待ちます。（DNS モニタは意図的な例外です。設計上リゾルバという対象を共有するため、対象ごとの上限ではなくグローバルな上限で制御されます。）
グローバル同時実行数の上限 — YAGRA_MAX_CONCURRENT_POLLS（既定 64）が 1 ポーラーの同時プローブ総数を制限します。これに加えてデバイスごとのレート制限とバックプレッシャーも働きます。

1 台のノードだけを、次のティックを待たずにその場でポーリングさせることもできます。設定レベル（Admin）の操作で、Yagra の MCP ツール経由なら AI や自動化クライアントからも実行できます。

ポーラーはステートレスで水平スケールします。作業がプールや拠点をまたいでどう分散されるか、そしてリモートポーラーがネットワーク分断をどう乗り切るかは分散ポーリングで扱います。

監視