監視

Yagra は、ICMP・SNMP・HTTP(S) を使ってネットワーク機器やサーバーを自分から監視しに行きます。数万規模のノードにわたって、死活・性能・しきい値を見張ります。

このページで説明するのは 3 つです。何が集まるのか、1 つのノードからどんなチェックが決まるのか、そしてポーリングのエンジンがどう動くのかです。チェックが異常になったあと何が起きるかは、アラートで扱います。

監視の対象

Yagra が見張るものは、すべてノードです。ただし、すべてのノードがルータというわけではありません。

ノードの種別は、設定の仕方から決まります。別に管理するラベルではありません。そのノードに紐づいた監視から、自動的に決まります。

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

1 つのノードが複数の形に当てはまる場合は、より具体的な種別が勝ちます。順序は Wireless AP → Meraki → URL → DNS → Device に固定されています。

5 つの種別は、いずれも同じインベントリツリーに属します。同じダッシュボードを共有し、同じアラートパイプラインへ流れ込みます。

種別は、作業する画面の上で見分けられます。インベントリツリーでは名前のうしろに、ノードのページではタイトルの横に、短い AP / URL / DNS / Meraki のバッジが付きます。通常のデバイスには何も付きません。ですからバッジは「これは別物として読んでください」という合図になります。

ノードのページに並ぶタブも、中身を持ちうるものだけです。URL 監視と DNS 監視には、 Interfaces・Neighbors・Flow がありません。SNMP で walk されることも、フローのエクスポーターになることもないからです。

決まり手は種別だけではありません。SNMP を設定していない Device —— 認証情報が紐付いておらず、デプロイ全体の YAGRA_SNMP_COMMUNITY も無いノード —— にも、Interfaces と Neighbors は出ません。どちらも SNMP の walk から作るタブで、そのノードでは walk が 1 度も走らないからです。Events と Flow は残ります。syslog・SNMP トラップ・NetFlow は機器自身のアドレスで結び付くので、ping だけで見ている機器にも実際に行が入りうるからです。

概要の欄も同じで、その種別が値を持ちうる項目だけを並べます。たとえば DNS 監視なら、メーカーやモデルの空欄が 4 行並ぶのではなく、リゾルバが出ます。

SNMP で監視している機器では、概要に OS バージョン も出ます。ポーラーが 1 時間ごとに読み直します。読み取り先はメーカーによって違い、独自 MIB・ENTITY-MIB・sysDescr のどれかです。対応表に無い機器は — と出ます。

その横に シリアル番号 も出ます。同じ 1 時間ごとの読み取りで、ENTITY-MIB の筐体の行から読みます。スタックは、全メンバーの番号を順に並べます。Huawei のスタックは筐体の行がスタック全体で 1 行しかないため、各メンバーのメインボードから読みます。 Juniper の機器は、先に Juniper 自社の MIB から読みます。 Meraki の機器は、取り込んだときのシリアル番号を出します。どちらにも番号が無い機器は — と出ます。

この 2 つは、ふだんは 1 時間ごとの読み取りを待ちます。ノードで 今すぐポーリング を押すと、そのポーリングで読みます。画面にはおよそ 30 秒後に出ます。

メーカーがまだ分からない機器は、最初のポーリングで全部読みます。そのため、バージョンとシリアル番号はすぐに出ます。その後は、ほかの機器と同じく 1 時間に 1 回、全部読みます。その間のポーリングでは、sysDescr と sysObjectID だけを聞きます。メーカーを決めるにはこれで足ります。モデルは、全部読んだときの値だけを使います。

API も同じ値を返します。GET /api/v1/nodes の kind と、MCP のノード系ツールです。

ノードをフォルダに振り分ける

ノードはフォルダのツリーに置かれ、まとめて移せます。インベントリツリーで Ctrl クリック（macOS は ⌘）は 1 台ずつ、Shift クリックは範囲で選びます。選ぶとツリーの上にバーが出て、何台選んでいるかを示し、**移動…**を出します。同じ項目はノードの右クリックメニューにもあるので、この操作を知らなくてもたどり着けます。選択に入っているノードをドラッグすると選択全体が動き、入っていないノードをドラッグするとそのノードだけが動きます。行と行のあいだに落とすと、選んだ順のままその位置に入ります。フォルダの上に落とすと、末尾に付きます。

ツリーはキーボードでも操作できます。ツリー全体で、Tab の止まる所は 1 つです。↑ / ↓ で選択が移ります。右の詳細は、キーを止めた時点で追いかけます。→ は閉じたフォルダを開き、開いたフォルダでは中へ入ります。← は開いたフォルダを閉じ、それ以外では上のフォルダへ移ります。 Enter はフォルダを開閉し、ノードでは詳細ページを開きます。Home・End・Page Up・ Page Down で、長いツリーを飛べます。Space は、今のノードを選択に入れる・外すを切り替えます。 Shift+↑ / ↓ は、Shift クリックと同じように選択を広げます。アプリケーションキーか Shift+F10 で、その行の右クリックメニューが開きます。メニューの中も矢印キーで動けます。

削除も、同じように選択全体に効きます。選択バーの 削除… か、右クリックメニューの 選択した N 件を削除… を使います。確認ダイアログには、消すノードの名前が出ます。見えないフォルダにあるノードは消えません。何台のうち何台を消したかは、ダイアログが示します。

同じ選択で、さらに 4 つの操作ができます。ポーラープール・メンテナンス・ミュート・ 今すぐポーリング は、右クリックした行が選択に入っていれば、選んだノードすべてに効きます。見出しに何台に効くかが出ます。選択バーでは その他… の中にあり、タグ… も同じ場所にあります。どれも、何台のうち何台に効いたかを返します。ページを開いたあとに消えたノードや、見えないフォルダにあるノードは数えません。メンテナンス窓とミュートはノードごとに 1 件ずつ作られるので、1 台だけ解除できます。プールのチップが「選択済み」に見えるのは、選んだノード全部が同じプールのときだけです。まとめて実行できない項目が 2 つあります。ノードを編集… は 1 台の設定を丸ごと開くもの、ピンは自分のアカウントの見え方です。この 2 つは、複数を選んでいるあいだは対象の名前を出します。

Nodes ▸ 重複ノード は、2 回以上登録した機器を見つける画面です。同じアドレスの重複も、別のアドレスの重複も見つけます。たとえば、1 台のルータをループバックと LAN 側のアドレスで 2 回登録した場合です。アドレス・シリアル番号・ARP 表の MAC アドレス・LLDP の筐体 ID のどれかが同じノードは、 重複の可能性が高い 組になります。弱い手がかりでしかつながらない組と、シリアル番号や機種が食い違う組は 要確認 です。各組で 1 台を残す候補として示しますが、最初から選ばれているノードはありません。組のノードをすべて消す削除は受け付けません。この画面には構成の管理の権限が要ります。

Nodes ▸ 重複サブネット は、複数の拠点で使われている IP 範囲を一覧にする画面です。拠点とは、機器から上にたどって最初の種類「サイト」のフォルダです。無ければ、機器のフォルダそのものです。機器がすでに答えているインターフェースのアドレスを比べるので、追加で何かを取りには行きません。出すのは次の 3 種類です。

同じアドレス。 2 つの拠点が同じ IP アドレスを設定しています。ほぼ確実に使い回しです。
入れ子。 ある拠点の範囲が、別の拠点の範囲の中に入っています。
同じ範囲。 2 つの拠点が同じ範囲を使い、アドレスはすべて違います。使い回しか、拠点どうしが同じ回線にいるかのどちらかなので、人に聞きます。

拠点間リンク（機器 2 台だけの /30・/31）は、要確認に出しません。わざと重ねている範囲は、2 つの方法で一覧から外せます。除外ルール は、範囲・ポートの名前か説明にある単語・その両方で書きます。通信会社の CGNAT（100.64.0.0/10）は組み込みのルールで、止めることもできます。意図的な重複にする は重なりを 1 件ずつ外すもので、別の拠点が使い始めるまで続きます。「WAN らしい」などの見立てはルールを提案するだけで、自動では当てません。ルールと印の変更には構成の管理の権限が要ります。一部のフォルダに限られたアカウントでは変えられません。

選択は、詳細を開いている行とは別物です。1 台を読みながら、別の何台かを集められます。URL には意図的に入れていません。再読み込みしたときに、もう画面に無い行の選択が復活しないようにするためです。

ツリーの絞り込みは、すべて検索欄の横にある漏斗のボタン 1 つにまとまっています。押すとパネルが開きます。上に切り替えが 3 つあります。ピン留めのみ・要対応・空のフォルダを隠す です。その下に、状態・種類・プールの絞り込みがチェックボックスで並びます。漏斗のボタンには、有効な絞り込みの数が出ます。有効な絞り込みは、インベントリの見出しの下にもチップとして並びます。チップの ✕ で 1 つずつ外せます。横の すべての絞り込みを解除 で全部外れます。

ノードやフォルダは、右クリックメニューか詳細ペインから ピン留め できます。ピン留めのみ を入れると、ツリーはピン留めしたものだけになります。ピン留めしたノード、ピン留めしたフォルダとその中身すべて、その上のフォルダです。ピンはアカウントに保存されるので、別のブラウザでも同じピンが出ます。

空のフォルダを隠す は、中にもその下にもノードが無いフォルダを隠します。ピン留めのみと同じく、アカウントに保存されます。要対応 は、ツリーを warning・critical・unreachable のノードだけに絞ります。これは状態の絞り込みでその 3 つの状態にチェックを入れる操作です。なので、何をしたかが見え、一部だけ手で外すこともできます。ほかの絞り込みと同じく URL にも残ります。

ツリーで閉じたフォルダも、アカウントに保存されます。別のブラウザでも、同じ開き方でツリーが出ます。検索語や状態・種類・プールで絞り込んでいる間は、全部のフォルダが開いた状態から始まります。前に閉じたフォルダが、一致したノードを隠さないためです。絞り込み中に閉じたフォルダは、絞り込みを外しても閉じたままです。

フォルダを選ぶ場所はすべて — 移動、ノードの追加、グループの親、ミュート、メンテナンス期間、探索の拠点 — フォルダが 8 個以上あると入力で絞り込めます。パス全体に対して照合するので、拠点名を打てばその下のラックが残ります。

フォルダには、そこで使っている IP レンジを持たせられます。 フォルダの編集ダイアログの IP レンジ 欄に手で入れるか、NetBox 同期に付けさせます。ホスト部が立っていても構いません。 192.168.1.5/24 は 192.168.1.0/24 として保存します。IPv4 と IPv6 のどちらも入れられます。同期が管理しているレンジも同じ欄に出ますが、同期由来 と印が付き、手では編集も削除もできません。

フォルダは、機器が使っているのにレンジに無いサブネットも出します。 フォルダを開くと、レンジの下に IP プレフィックスに無いサブネット が出ます。そのフォルダと下のフォルダの機器が報告したアドレスを、それらのフォルダのレンジと比べます。出てくるサブネットには、それぞれ理由が付きます。

どのレンジにも入っていない。
レンジが一部しか覆っていない。
別のフォルダのレンジに入っている。レンジを付けるフォルダを間違えたか、2 つの拠点が同じプライベートのレンジを使い回しています。
上のフォルダのレンジにだけ入っている。

何台の機器からアドレスを読めたかも出ます。SNMP でアドレスを読んでいない機器は、比べる材料になりません。機器が 2,000 台を超えるフォルダは比べません。下のフォルダを開くか、次の画面を使ってください。見えるフォルダを限られたアカウントには、別のフォルダがそのサブネットを持っていることだけを伝えます。どのフォルダの、どのレンジかは伝えません。

Nodes ▸ IP プレフィックスに無いサブネットは、同じ比較を全サイトについて一度に行います。 サイトは、機器から上にたどって最初の種類「サイト」のフォルダです。画面はサイトごとに開きます。タブは「抜けあり」「抜けなし」「比べていない」に分かれます。「比べていない」は、どの機器からもアドレスが取れていないサイトです。行を開くと、抜けたサブネットと、それを持つ機器・ポート・アドレスが並びます。 サブネットの一覧 に切り替えると抜けを 1 行ずつ並べ、CSV に書き出す でその一覧を保存できます。並べる抜けは 2,000 件までです。この 2,000 件はサイトの間で分け、総数も一緒に出します。

確かめたうえで残しておく抜けには、印を付けられます。行の右端の 意図的にする を押します。メモも残せます。印を付けた抜けは 意図的 タブに移ります。要確認に戻す で取り消せます。抜けがすべて意図的なサイトは、「抜けなし」ではなく「意図的」に出ます。サブネットの理由が変わると（例：一部だけ登録された）、印は効かなくなり、要確認に戻ります。

フォルダにレンジが付いている場合、右クリックメニューと選択バーに「アドレスで振り分ける」も出ます。これは提案するだけで、実行はしません。何がどこへ移るのか、どれがどのレンジにも入らないのか、どれを 2 つのフォルダが等しく主張しているのかをダイアログが示し、ボタンを押すまで何も書きません。 2 つのフォルダが主張するノードが、自動で移ることはありません。

ディスカバリの取り込みも同じレンジを使います。 レンジを持つフォルダがあるときは既定でオンです。機器は全部が 1 つのフォルダに着地する代わりに、アドレスを含むレンジを持つフォルダへ入ります。候補一覧には フォルダー 列があり、取り込みボタンを押す前に 1 台ずつの行き先が読めます。この列は選択欄なので、別の場所に属する機器は 1 クリックで行き先を変えられます（ツリー直下も選べます）。どのレンジにも入らない機器と、2 つのフォルダが同じ強さで主張している機器は、掃引時に選んだフォルダへ入ります。アドレスのせいで取り込みが失敗することはありません。

ノードに名前を付け、ラベルを貼る

ノードの名前は自分で決められます。製品内のどれもそれを上書きしません。ポーリングも、ディスカバリの掃引も、分類器もです。打ち間違いは ノードを編集 で直せます。以前のようにノードを消して作り直す必要はなく、作り直せばメトリクスとアラートの履歴は置き去りになります。

Notes は同じダイアログの自由記述です。次にその機器に触る人へ宛てたもの、たとえば「東側廊下の天井裏。脚立が要る」といった内容です。ノードの Overview タブの先頭に出ます。 /mcp 越しに読む AI クライアントからは get_node_status で見えます。

タグは単一のラベルです。JAPAN、core、松山本社 のようなもので、key=value の組ではありません。インベントリフォルダはちょうど 1 つですが、タグは必要なだけ付けられます。ノード単位の編集は ノードを編集 から、まとめて付けるならインベントリツリーの右クリックメニューの 選択した N 件にタグを付ける… からです。後者は置き換えではなく、各ノードが既に持っているものに 足します。

フォルダに付けたタグは、その下の全部に届きます。 日本拠点に JAPAN を付ければ、その下の機器はすべてそれを持ちます。来月見つかる機器も含めてです。一度きりの一括編集ではこれはできません。各ノードに写しを作るのではなく読むたびに解決するので、フォルダを動かしても親を編集してもすぐ効き、古い写しが残りません。例外にしたい機器は、自分の ノードを編集 から継承したタグを拒めます。フォルダ側で拒めば、そのフォルダの配下全体から外れます。ノードの Overview タブとフォルダの詳細ペインのどちらでも、そのもの自身のタグと上から来たタグが区別して表示されます。

ICMP

すべての Device ノードが、ICMP 死活監視の対象になります。常に有効で、認証情報も要りません。

プローブは、届くかどうかと往復時間（icmp_rtt_ms）を記録します。この値はノード詳細でグラフにできますし、しきい値ルールにも使えます（たとえば RTT が 100 ms を超えたら）。

応答しなくなったデバイスは unreachable の状態へ移り、死活アラートを上げます。ただしこれは、アラートで説明するヒステリシスと依存関係の抑制に従います。

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

SNMP

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

SNMP v2c — コミュニティを使う方式。
SNMP v3（USM） — 認証と暗号化に対応した方式。

どちらのバージョンでも、スカラーのメトリクス（CPU、メモリ、セッション数など）を集め、 テーブルを walk します。複数のインデックスを持つテーブルにも対応します。

インターフェースごとのメトリクスは、GETBULK でインターフェーステーブルを walk して取ります。これは v2c のノードでも v3 のノードでも同じです。ですから v3 しか許可しない機器でも、インターフェースごとのカウンタが集まります。

1 つのノードのテーブル walk は、1 回のポーリングにつき 1 つの SNMP セッションにまとめます。ですからポート数の多いスイッチでも、テーブルごとに会話するのではなく、1 回で済みます。

ノード詳細では、インターフェースごとのスループットと状態を表示します。表示は小さなスパークラインと時系列グラフで、期間の切り替え（1 時間〜7 日、およびカスタム）は共通です。インターフェースのグラフには、設定した帯域の基準線が引かれます。

ポートが自分について語ること

インターフェースタブは、ポートごとに速度・デュプレックス・メディア種別を並べます。 3 つとも列フィルタで絞り込めます。ここが要点です。「100 Mbps のポートだけ出す」という操作が、本来ギガで上がるはずのリンクが落ちて上がっていることに気づく手順になります。

トラフィックは 1 つの列ではなく、受信と送信の 2 列で出します。背景は、リンクがどれくらい埋まっているかで塗り分けます。基準はそのポート自身が申告した速度です。同じ 900 Mbps でも、1G のポートなら赤、10G のポートなら緑になります。速度を申告しないポートは塗りません。割る相手が無いからです。停止中のポートも塗りません。セルにマウスを乗せると、実測値とリンクに対する割合が出ます。

IP アドレス列には、各ポートに設定されたアドレスが 192.168.0.1/24 の形で出ます。機器が知らせてきたアドレスは、セカンダリ（同じポートに追加で設定したアドレス）も含めて全部出ます。 1 本目を表示し、+N を押すと残りが開きます。この列の絞り込みは、ポートのどのアドレスにも一致します。 10.221. と入れれば、その範囲をセカンダリで持つポートも見つかります。/30 と入れれば、点対点のリンクが見つかります。アドレスは、ネットワークマップが使っている 1 時間ごとの読み取りから取ります。そのため、変更は 1 時間以内に反映されます。機器がマスクを読める形で知らせなかったアドレスは、プレフィクス無しで出ます。スマートフォンでは、この列は出ません。代わりに、ポートを開くと全部のアドレスが出ます。

隣接列には、各ポートが CDP または LLDP で見ている相手の機器名が出ます。相手が複数いるときは、 +1 のように残りの数が付きます。名前を押すと、そのポートの隣接機器がすべて開きます。相手のポート、機能、管理アドレスが、一覧を離れずに分かります。

CDP の隣接機器は、ポートのインデックスで行に割り当てます。
LLDP の隣接機器は、機器がポートを一覧と同じ名前で呼ぶときだけ割り当てます。ポートを別の形で報告する機器（たとえば番号で報告する Junos のスイッチ）では、隣接機器は Neighbors タブにだけ出ます。

スマートフォンでは、この列は出ません。

この一覧に限らず、Yagra のどの一覧でも、列の幅は自分で変えられます。列見出しの右端にある帯をドラッグしてください。その帯にフォーカスして矢印キーを押しても変わります。幅はサインインしているアカウントに保存されます。別のマシンでサインインしても、同じ幅になります。

速度とデュプレックスは、ポーラーがすでに行っているインターフェースの walk に相乗りするので、 SNMP のやり取りは増えません。メディア種別だけは別に、1 時間に 1 回読みます。メディアが変わるのは誰かがモジュールを挿し替えたときだけだからです。最初に標準の MAU テーブルを読みます。そこが答えなかったポートは、次に Cisco 独自のポート表、最後にトランシーバの型番から補います。Huawei の YunShan OS はこの 3 つをどれも実装していません。そのため Huawei のポートは、インターフェースの walk のほうで媒体を返します。銅ポートの IEEE 呼称は、実際にネゴシエートした速度から決まります。

空欄は「機器が答えなかった」という意味で、異常ではありません。デュプレックスは銅線向けの診断項目です。IEEE 802.3 は 1 Gbit/s を超える半二重を定義していないので、光ポートには交渉する対象がなく「不明」と答えます。MAU テーブルを実装していない機器も多くあります。

1 本のポートのグラフ

ポートを選ぶと、一覧の下にグラフのドックが開きます。カーソルは共有です。どれか 1 枚にカーソルを乗せると、すべてのグラフの縦線と凡例が同じ時刻に揃うので、「トラフィックが跳ねた。そのとき破棄も跳ねたか」を 1 回の読み取りで確かめられます。

スループット。bps と pps を切り替えられます。 機器の転送性能の上限は、ビット数ではなくパケット数で先に来ることがあります。帯域には余裕があるのに詰まっている、という状況です。
エラーと破棄を同じ軸に。この 2 つは別の故障を意味します。エラーは壊れた状態で届いたフレーム（配線・光・NIC）、破棄は壊れてはいないが機器が捨てたフレーム（輻輳・キュー溢れ・ ACL）です。
光レベル（受光 / 発光, dBm）。トランシーバの挿さっているポートで表示します。ベンダーが申告している場合は、モジュール自身の使用可能範囲を帯として重ねます。光ファイバは徐々に劣化します。受光レベルが -7 dBm から -18 dBm へ落ちてきているのは、切れかけているリンクの姿です。 5 種類のベンダー方言（ENTITY-SENSOR-MIB、Cisco 独自の CISCO-ENTITY-SENSOR-MIB、Huawei、 Juniper、H3C）を読みます。値はすべて dBm に正規化するので、どのベンダーでも同じ意味の数値になります。Cisco はベンダー非依存のほうの表を実装していないため、独自の表も並べて読みます。使用可能範囲でアラートは上がりません。 Yagra で設定したしきい値ではなく、モジュール側が公表している値だからです。

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

Yagra は、インターフェースやエラーのカウンタを生のまま保存します。前回のサンプルとの差をポーラー側でレートに直すことは、一切ありません。

レートや使用率は、問い合わせたときと評価するときに、時系列ストア側で計算します。カウンタが一周したり、リセットされたりしたことも、そこで自動的に検出されます。

この作りが、運用上 2 つの効果を生みます。

ポーラーが状態を持たずに済みます。前回値を覚えておく必要がなく、ポーラーの再起動や引き継ぎのあとに、おかしなレートが出ることもありません。
32 ビットのカウンタが一周しても、機器が再起動しても、幻のトラフィックスパイクは出ません。一周やリセットの処理は、手書きの引き算ではなく、ストアのレート関数の中にあるからです。

レートを出すには、サンプルが 2 つ以上要ります。ですからレートを計算する時間幅は、ポーリング間隔に合わせて広がります。時間幅には、そのノードのポーリングが必ず 2 回以上入ります。対象は、Interfaces タブ、ノードのレートのグラフ、使用率のヒートマップ、Top interfaces、フリートのスループット、トラフィックの急増と急減、インターフェース使用率のアラートです。

API では、GET /api/v1/metrics/interface-delta の window と、MCP ツール top_interfaces の window_secs を、フリートでいちばん長いポーリング間隔の 2 倍以上に広げます。それより短い幅では、比べる相手が無いからです。

この作りから 1 つ帰結があります。しきい値ルールは、生のカウンタではなくゲージに掛けてください。詳しくは後述のしきい値にあります。

認証情報

SNMP のコミュニティと v3 の認証情報は、保存するときに暗号化されます。ログにも API のレスポンスにも出ません。メトリクスのラベルにも使いません。

認証情報を紐づけていないノードには、デプロイ全体で使う v2c コミュニティを当てることもできます。指定は YAGRA_SNMP_COMMUNITY です。詳しくは設定リファレンスを見てください。

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 の 4 つです。作成時に dns_up の既定しきい値が入るので、新しい DNS 監視は設定しなくてもアラートを上げます。

解決に失敗したときは、理由が読める文章で出ます。内部のエラーコードではありません。日本語と英語の両方で、たとえば「該当する名前がありません（NXDOMAIN）」のように表示されます。

URL 監視と同じく、DNS 監視も作ったあとで編集・削除できます。場所はノードの DNS ヘルスカードです。リゾルバ、レコードタイプ、その他すべてを変えられます。削除しても、ノードとその履歴は残ります。

Cisco Meraki

Yagra は、読み取り専用の Dashboard API を通じて Cisco Meraki の環境を監視します。

設定 ▸ 連携 ▸ Cisco Meraki で組織を追加してください。読み取り専用の API キーを入力するか、 設定 ▸ 資格情報 に保存済みのキーを選びます。追加すると Yagra は、その組織が持っているもの ——ネットワークとデバイス——を 5 分ごとに読みます。組織ごとに専用のページがあり、その在庫と、各デバイスがどのフォルダに入るか、直近の同期がどう終わったかが出ます。

デバイスは自分で取り込まれます。 監視対象のネットワークに在り、Meraki が一度でもオンラインと報告したデバイスが、ノードになります。箱に入ったままの予備機は、最初にオンラインになるまで放っておかれるので、いきなり障害として現れません。消したデバイスは消えたままで、戻したければ組織のページから手で戻します。これから追加する組織は、自動の取り込みが入った状態で始まります。すでに在る組織は切れた状態で始まります——その機器は 1 台ずつ人が選んだものだからです。
フォルダへの振り分けは IP 範囲で決まります。 ちょうど 1 つのフォルダの IP 範囲に収まるアドレスのデバイスは、そのフォルダに入ります。範囲が重なるときは、狭いほうが勝ちます。つまり Meraki の機器も、他の機器と同じ拠点のツリーに並びます。アドレスが無いデバイスや、2 つのフォルダが同じ強さで主張するデバイスは、これまで通り Organization → Network のフォルダに入ります。拠点が同じプライベート範囲を使い回している組織では、IP 範囲で振り分けるを切ってください。連携が作ったフォルダには Meraki バッジが付きます。 IP 範囲で振り分けるが ON のとき、まだアドレスの無いアクセスポイントとスイッチは取り込みません。取り込まずに待ち、台数の上限の中の順番は取っておきます。Meraki がアドレスを報告すると、そのアドレスを範囲に持つフォルダへ取り込みます。メッシュ中継の AP はアドレスを報告しないので、自動では取り込まれません。Organization のページから手で取り込んでください。その場合はネットワークのフォルダに入ります。
MX のアドレスは LAN 側から取ります。WAN のアドレスは使いません。 MX は Dashboard に LAN のアドレスを出しません。WAN のアドレスは、ふつうどのフォルダの IP 範囲にも入りません。そこで Yagra は、MX のいるネットワークの VLAN を 1 つずつ読み、MX 自身の VLAN のアドレスを使います。まず、組織のほかのネットワークでも使われているアドレスを外します。残りのうち、フォルダの IP 範囲に入る VLAN で番号が一番小さいものを選びます。どれも入らなければ、番号が一番小さい VLAN を選びます。組織の最初の同期は、MX のいる全ネットワークの VLAN を一度に読みます。既定の速さで 350 ネットワークなら約 3 分です。デバイスを取り込むのは、読み終えてからです。読み取りが途中で切れた同期では、MX を 1 台も取り込みません。まだ読んでいない拠点と同じアドレスを MX が取ってしまわないようにするためです。すでにノードになっている MX は新しいアドレスになりますが、フォルダは動きません。Nodes で選び、IP レンジで移動を使ってください。 warm spare（予備機が待機する冗長構成）の 2 台は、同じアドレスになります。
収集は、組織の単位で行います。 ページをめくりながら組織全体を 1 本の API 呼び出しで取るので、大きな環境でも組織の API レート制限に引っかかりません。問い合わせは組織全体に向けて出し、監視対象のネットワークの行だけを手元に残します。なので、ネットワークが増えても要求は長くなりません。対象外になってしまった監視中のデバイスは、黙って取り残されるのではなく、組織のページで指摘されます。
遅い読み取りが、可用性の収集を待たせません。 組織ごとの収集は 2 列で走ります。速い列は、可用性・アップリンク・トラフィックと、アクセスポイントの端末数と使用率です。遅い列は、スイッチのポート・SSID の読み取り・定期の在庫の同期です。設定するリクエストレートは組織の合計で、2 列が半分ずつ使います。
機器が動いているかを決めるのは、可用性の段だけです。 Dashboard がオフラインと報告したデバイスは「停止」になり、他のノードと同じようにアラートを出します。ほかの収集は値を記録するだけで（ノード詳細の Cisco Meraki カードに出ます）、死活については何も言いません。
MX には、WAN 回線・Auto VPN・warm spare の組が出ます。 WAN 回線ごとに、状態・ロス・レイテンシ・通信量が出ます。通信量は回線ごとにグラフになります。組み込みの MX のプロファイルには、既定のルールが 2 つ付きます。1 つは、回線が障害になったときの警告です。もう 1 つは Auto VPN のアラートです。拠点がハブの 1 つに届かなくなると警告になり、どのハブにも届かなくなると重大（critical）に上がります。カードには、組の主と控え、拠点が控えで動いているかも出ます。
スイッチには、ポートが出ます。 Meraki MS には、SNMP のスイッチと同じ Interfaces タブが付きます。ポートごとの状態・速度・二重・通信量が出ます。ポートは SNMP のポートと並んでランキングに載り、同じ利用率のアラートが付きます。通信量は Dashboard の 5 分平均なので、実際より 12〜17 分遅れて描かれます。エラーと破棄の数は取りません。
アクセスポイントには、端末と電波が出ます。 Meraki MR は、接続中の端末数・発信中の SSID・電波ごとのチャネル使用率とそのうち Wi-Fi 以外の割合を出します。名前は、無線コントローラ配下のアクセスポイントと同じです。チャネルと送信電力は 20 分ごとに読みます。電波が動いているかは Dashboard が答えないので、電波には up/down がありません。
API が応答しなくなったら、アラートが 1 つ出ます。 可用性の収集が 3 回続けて答えを得られなかったとき——キーの失効、Dashboard の停止、レート制限——組織について critical のアラートが 1 つ出ます。デバイスごとには出ません。閉じるのは収集が再び答えたときだけで、報告が来なくなっただけでは閉じません。デバイスは最後に収集できた状態のまま残り、その理由は各ノードの Overview に出ます。
組織ごとの操作として、収集の一時停止と再開、ティアごとのポーリング間隔とリクエストレートの上限の調整、対象ネットワークの編集ができます。スイッチのポートと無線のティアの間隔は 300〜600 秒です。この 2 つは、プールのポーラーが全部対応しているときだけ送ります。集め始めるには、Meraki のプールのポーラーを上げてください。可用性の段だけは外せません——機器が動いているかを言えるのが、この段だけだからです。全体を止めるスイッチもあり、押せばすべての Meraki 収集がその場で止まります。新しく足した組織は、10,000 台まで取り込み、MX の回線の通信量を 5 分ごとに取ります。どちらも組織のページで変えられます。
今すぐ同期は、組織全体を裏で読み直します。 在庫、MX のいる全ネットワークの VLAN、warm spare の役割を読み、組織の設定どおりに取り込みます。遅い列だけを使うので、可用性の収集は止まりません。スイッチのポートと SSID の読み取りは、終わるまで待ちます（既定の速さで 350 ネットワークなら約 6 分）。組織のページには読み取りの進み具合が出て、走っている間は自動で更新されます。組織どうしの同期は並べて走るので、ある組織の長い読み取りが、ほかの組織を待たせることはありません。

この連携は、設計として読み取り専用です。発行するのは HTTP の GET だけです。すべてのリクエストは、許可リストに載せた Meraki の API ホストに限られます。API キーは保存するときに暗号化され、返却もログ出力もされません。Yagra 側では、Meraki に対する書き込みはすべて、見える範囲をグループに限定したアカウントを断ります——組織は丸ごと監視するものであり、そのキーは組織内のすべてのデバイスを見られますし、まだ取り込んでいないデバイスはどのグループにも属していないからです。

分散構成では、Meraki のクラウドポーリングのジョブを、YAGRA_MERAKI_POOL（既定は default）で指定したプールへ回します。一部の拠点にしかインターネットへの出口が無いときに役立ちます。詳しくは分散ポーリングを見てください。

無線コントローラ

無線コントローラ（アクセスポイントをまとめて管理する機器）は、2 つの系統を監視できます。どちらも、それぞれの組み込みプロファイルを付けた、ふつうの SNMP 機器として監視します。

Huawei の無線コントローラ（AC）。プロファイルは Huawei wireless controller です。
Cisco の無線 LAN コントローラ。プロファイルは Cisco wireless controller です。AireOS のコントローラと Catalyst 9800 は同じ表（AIRESPACE-WIRELESS-MIB）に答えます。そのため、1 組のテンプレートで両方を読みます。このプロファイルが付いたコントローラのノードは、更新後の最初のポーリングから読み始めます。

この 1 台のノードから、配下の無線の様子をまとめて読みます。

コントローラ全体の数。 接続している AP の台数と、接続端末数です。Huawei の AC は、登録・ライセンスされている AP の台数、正常に動いている AP の割合、帯域ごとの接続端末数、ローミングの成功回数も返します。Cisco のコントローラには、AireOS と 9800 の両方が答える合計の値がありません。そのため、接続している AP の台数と接続端末数は、Yagra がコントローラの表から数えます。
SSID。 SSID ごとに 1 行です。行の名前は SSID そのものです。接続端末数を取ります。Huawei の AC では、帯域ごとの接続端末数、その SSID を出している AP の台数、通信量のカウンタも取ります。 SSID ごとに履歴のグラフが描け、しきい値ルールも付けられます。
アクセスポイント。 コントローラが報告する AP をすべて、状態・アドレス・機種・シリアル番号・ソフトウェアの版・CPU・メモリ・接続端末数と一緒に並べます。コントローラのノードの AP タブ、 GET /api/v1/wireless/aps、MCP ツール list_wireless_aps で見られます。ノードとして監視しているかどうかには関係ありません。

AP は、次の 2 つのどちらかで、種別 Wireless AP（バッジ AP）のノードになります。

コントローラの AP タブの アクセスポイントを自動で監視に入れる を、オンのままにします。これは既定でオンです。Yagra が新しく読み始めたコントローラでも、すでに登録済みのコントローラでも同じです。1 分以内に、一度でも稼働したことのある AP がすべてノードになります。上限はそのコントローラの AP 上限（指定しなければ 1024 台）です。あるコントローラの AP を対象から外したいときは、これをオフにしてください。すでに作られた AP のノードは残るので、消すかどうかはこちらで決められます。消した AP のノードが、ひとりでに作り直されることはありません。
同じタブで、1 台の AP の 監視する を押します。

どちらも「設定の管理」権限が要ります。AP のノードは、取り込み設定で別のフォルダを指定しないかぎり、コントローラと同じフォルダに入ります。

AP のノードそのものは、ポーリングしません。コントローラのポーリングが代わりに答えます。答えるのは、稼働しているか、接続端末数、CPU、メモリ、温度、そして電波です。電波は 1 本ずつ、AP の Interfaces タブに 1 行で並びます（スロット 1 が 2.4 GHz、2 が 5 GHz、3 が 6 GHz）。そのため、しきい値ルールで「この AP のこの電波だけ」を指定できます。Cisco のコントローラが電波ごとに返すのは、接続端末数・チャネル・チャネル使用率です。Huawei の AC は、干渉・ノイズフロア・端末の平均の電波の強さ・送信電力も返します。

HA ペア（2 台 1 組で片方が待機する構成）のコントローラでは、その AP を受け持っている側が AP の値を決めます。待機側の見え方も AP の一覧には残ります。ただし、稼働側の値を上書きすることはなく、待機側の報告で AP が落ちることもありません。ペアが切り替わっても、AP のノードと履歴はそのままです。

コントローラが応答しなくなると、AP の結果は 1 つも作りません。そのため、コントローラ 1 台の障害で AP の台数ぶんのアラートが上がることはありません。代わりに、コントローラの wlan_ap_walk_complete が warning を出します。どのコントローラからも 10 分報告が無い AP は、unknown になります（コントローラのポーリング間隔の 3 倍のほうが長ければ、そちらを待ちます）。AP の概要には、いつから報告が無いかが出ます。最後の報告で停止していた AP は、停止のままです。AP に開いているアラートがあれば、それもそのまま出ます。

Cisco のコントローラには、AP の「停止」を表す状態がありません。失った AP は、表から消します。そこで Cisco のコントローラに限り、次のように扱います。そのコントローラが最後に担当していた取り込み済みの AP が、表を最後まで読んだ結果から消えていれば、その AP を「停止」として記録し、死活のアラートを上げます。コントローラが再び表に載せれば、元に戻ります。コントローラの起動から 15 分は、AP が戻ってくる途中なので、消えていても数えません。コントローラの wlan_controller_aps_missing は、担当している AP のうち接続していない台数です。Cisco のプロファイルには、これが 1 以上で 3 回続くと warning を出す組み込みルールが付いています。

このリリースで分かっている制限は次のとおりです。

コントローラの AP の一覧は、1,024 台で切られます。
確かめたのは、AP 38 台までのコントローラです。計算上、AP がおよそ 800〜1,200 台を超えるコントローラでは、AP の表を時間内に読み終えず、一覧が更新されなくなる恐れがあります。
Catalyst 9800 は、1 台分の記録（録音したデータ）で確かめただけです。動いている実機では確かめていません。
Cisco のコントローラから、Yagra が監視していないコントローラへ移った AP は、「停止」と読みます。

NetBox

Yagra は NetBox（ネットワーク構成の正本となる台帳）からフォルダーツリーを作れます。同じ拠点の一覧を 2 か所で手入力し続ける必要がなくなります。

設定 ▸ 連携 ▸ NetBox を開きます。
NetBox のベース URL と API トークンを入力して、登録します。
同期を待ちます。既定では 1 時間ごとに動きます。行の 今すぐ同期 を押すと、すぐに同期を依頼できます。行の表示は「同期を依頼しました」から「同期中…」に変わります。ページを離れても、同期は最後まで走ります。

同期は NetBox の Region と Site を読み取り、ノードのフォルダーツリーに反映します。Site の緯度経度もそのまま入ります。Geo マップのピンは、誰も置かなくても表示されます。

同期は読み取り専用の一方向です。Yagra が NetBox に書き込むことはありません。使うのは HTTP の GET だけで、リダイレクトには従いません。API トークンは暗号化して保存します。画面にもログにも出しません。
所有権は列ごとに分かれています。フォルダーの名前・親・地図上の位置は、同期が持ちます。オペレーターがフォルダーに設定したポーラープールには触れません。インベントリのツリーでフォルダーが並ぶ位置を同期が決めるのは、そのフォルダーを最初に作るときだけです。そのあとは、ドラッグで置いた場所から動きません。
フォルダーになるのは Active のサイトだけです。 Status が計画中・準備中・撤去中・撤去済みの Site は取り込まず、その Prefix も取り込みません。あとで Active でなくなった Site のフォルダーは、中のノードごと残ります。そして「NetBox から同期されなくなったフォルダー」に数えられます。
NetBox 側で削除された Site は、消さずに印を付けるだけです。フォルダーを削除すると、その下のフォルダーとノードがすべて消えます。外部システムの 1 回の誤操作で、そこまで起きてはいけないからです。
サイト ID フィールド。 自分たちの拠点コードが入っている NetBox のフィールドを選べます。 slug・facility・description・カスタムフィールドのいずれかです。選ぶと、Site のフォルダー名が Matsuyama Home ではなく JPMYJ01 Matsuyama Home になります。既定では付きません。フィールドが空だった Site の数は、同期結果に出ます。選び間違えても、黙って何も起きないということはありません。
サブネット。 同期は NetBox の IP プレフィックスも読みます。それぞれを、紐づく Site または Region のフォルダーに付けます。プレフィックスを持つフォルダーを右クリックして ここで機器探索を実行… を選ぶか、Discovery 画面でサイトを選びます。範囲が 1 本ずつのチェックボックスで並び、行ごとのアドレス数と合計が出ます。その探索で取り込んだ機器は、そのフォルダーに入ります。IPv6 のプレフィックスは保存して表示しますが、探索の対象からは外します。プレフィックスを読めないトークンでは何も変わりません。フォルダーツリーの同期はそのまま動きます。

ベース URL はオペレーターが入力するため、トークンを送る前に検査します。ループバック・リンクローカル・マルチキャスト・未指定のアドレスは拒否します。プライベートアドレスは許可します。NetBox は通常そこにあるためです。プライベート CA（社内で発行した認証局）を使う NetBox は、同じ画面にその CA の証明書を貼り付ければ接続できます。信頼するのはその接続だけです。証明書の検証を切ることはありません。動作を確認したのは NetBox 4.6 で、3.x は未検証です。NetBox からのノード割り当てとノード作成は、この連携にはまだ入っていません。

GET /api/v1/netbox/servers は、MCP からも get_config(kind=netbox_servers) で読めます。どちらにも API トークンは含まれません。

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

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

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

組み込みのプロファイルとテンプレートは、よくあるベンダーを最初からカバーしています。Cisco、 Huawei（USG のファイアウォールセッション数やメモリを含みます）、Meraki MX/MS、A10 です。標準のホスト MIB とインターフェース MIB も揃っています。

これらはすべて編集・検索できます。ですから新しい機器へ対応を広げるには、カタログの項目とテンプレートを足すだけで済みます。コードを書く必要はありません。

収集しているものは、UI が想定したものだけでなく全部見えます。 ノードの収集タブは、そのノードに届いたメトリクスをすべて並べ、どれでもグラフにできます。

これがいちばん効くのは、自分で足したカバレッジです。以前は、ベンダー固有のテーブル列を収集できていても、その名前を知っている画面が書かれていない、ということが起きていました。

各項目には状態が付きます。「設定済みでデータあり」「設定済みだがまだ届いていない」「収集項目は無いがデータが届いている」の 3 つです。

最後の状態は異常ではありません。到達性、URL 監視と DNS 監視、隣接の数、監視対象の JSON 本文から取り出した値は、収集セットではなくチェック側が生み出すものだからです。

カウンタは、毎秒のレートとしてグラフにできます。保存してあるのは積算計の読みなので、そのまま描くと、トラフィックのように見えて実は違う右肩上がりの線になってしまいます。

ディスカバリと分類

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

ディスカバリは、IP の範囲やアドレスの一覧をまとめて調べます。使う認証情報は、保存済みのものから選びます。
Credential Finder は、保存済みの認証情報を、見つかったデバイスに順に試します。渡すのは 値ではなく参照です。デバイスごとにレート制限がかかり、試した値がログに出ることはありません。
分類ルールは、sysObjectID や sysDescr に一致したときに、対応するデバイスプロファイルを自動で当てます。ですから見つかったデバイスは、正しい収集セットが付いた状態で登録されます。
結果はインポートグリッドに並びます。調べた結果が裏で勝手にノードになることはありません。何をインベントリに入れるか、確認して選べます。
住所が既に機器ノードになっている行は、薄字になり 登録済み のバッジが付きます。チェックは入れられません。同じ掃引を 2 回取り込んでも、ノードは重複しません。
別のアドレスで監視中の機器ノードと同じ機器らしい行も、薄字になります。そのノードのインターフェースにスキャンしたアドレスがあり、機種（sysObjectID）も同じなら、 同じ機器の可能性が高い のバッジが付きます。インターフェースにアドレスはあるが片方が機種を返していないときや、名前と機種が同じときは 同じ機器かもしれない です。機種が違う 2 台には印を付けません。行には、そのノードへのリンクと根拠が出ます。チェックは入れられます。拠点ごとに同じ私設アドレスを使う構成では、推測が外れることがあるからです。

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

分類ルールを直しても、登録済みのノードは自動では動きません。ノード ▸ 分類のかけ直し には、今のルールが選ぶプロファイルと、実際のプロファイルが違う機器ノードが並びます。当たったルールと、判定に使った sysObjectID と sysDescr も出ます。選んだノードに当てる で、チェックしたノードを移します。今のプロファイルで固定 したノードは、以後この一覧に出ません。

1 台だけを読み直すときは、ノードを右クリックして 再検出… を選びます。SNMP の community を変えたあとなどに使います。Yagra は、そのノードの認証情報で、そのノードのポーラープールから機器に問い合わせ直します。そして、ノードのプロファイル・メーカー・モデルを、機器が今答えた値と並べて見せます。書き込むのは、行にチェックを入れて適用を押したときだけです。固定したプロファイルは変えません。まだどのポーラーも拾っていないときや、ping には答えても SNMP に答えないときは、「変化なし」と見せずにそう言います。

掃引を実行する

掃引は、画面の前に座って待つものではなく、操作できるジョブです。

画面を離れて、戻ってこられます。 ノード ▸ ディスカバリに core が保持している掃引の一覧が出て、選んだものへつなぎ直します。スキャン ID は URL に載るので、再読み込みや共有リンクでも同じ掃引が開きます。
どの拠点から実行するか選べます。 ポーラープールを指定しないと、最初に応答したポーラーが掃引します。複数拠点の構成では、リモート拠点のポーラーが本社のレンジを掃引し、どこにも届かないまま「成功・候補 0 件」で終わることがあります。
途中で止められます。 ポーラー側の探索そのものが止まるので、ICMP と SNMP のトラフィックが実際に止まります。それまでに見つかったデバイスは画面に残り、そのままインポートできます。実行中の探索は接続を切らずタイムアウトを待つため停止には数秒かかり、ポーラーが確認するまで画面は 停止中… のままです。まだ見えていない停止を「済んだ」とは言いません。
どのポーラーも受け持っていない掃引は、そう言います。 掃引は「ポーラー待ち」から始まり、ポーラーが報告して初めて「実行中」になります。生きたポーラーが 1 台も居ないプールへ投げた掃引と、実行中だが何も見つからない掃引とを、区別できます。

既定では、掃引は ping に応答しないアドレスを飛ばします。速いのはこれが理由です。テスト環境で機器 8 台の /24 を掃引すると、すべてのアドレスへ候補の認証情報を 1 つずつ試していたころは 5 分 21 秒かかり、そのほとんどが何も無い 246 個のアドレスに費やされていました。

引き換えに失うものは明示しておきます。ディスカバリの ping は 1 回だけです。ICMP を遮断していて SNMP には応答する機器は取りこぼしますし、パケットが 1 つ失われると何も無いアドレスと区別が付きません。すべてのアドレスを調べたい場合は、スキャンのフォームのチェックボックスを戻すか、 POST /api/v1/discovery/scan に "snmp_when_unreachable": true を送ってください。死活監視には影響しません。こちらは 3 回連続の失敗を待ってから「停止」と判断します。

完了した掃引は 6 時間（最大 20 件）保持され、その後破棄されます。

ネットワークマップ

ネットワークマップは、機器自身の報告から Yagra が組み立てた接続関係を描きます。リンクを手で入力する人はいません。それぞれの線は根拠を持っていて、マップ上でも凡例でも区別して表示されます。根拠は次の 3 種類です。

CDP / LLDP の隣接情報。対向の管理アドレスを手がかりに、監視対象のノードと突き合わせます。使えるアドレスを名乗らない対向（Meraki MX など）は、MAC で突き合わせます。Meraki の組織がその MAC で機器を載せていて、その機器がここのノードであるときです。
同じ IP サブネットの共有。同じプレフィクスにインターフェースアドレスを持つ 2 ノードは、事実として隣り合っています。
OSPF 隣接、BGP ピア、直結経路。これがあるおかげで、サブネットを共有しないリンクも見つかります。点対点の /32（PPPoE の Dialer、トンネルの端点）、番号を振っていない OSPF リンク、アドレス情報を集められていないセグメント越しのピアリングなどです。

同じリンクが複数の経路から見えても、線は 1 本のままです。根拠のほうが積み上がります。冗長な経路はまとめずに残すので、2 台のルータ経由で届くサーバーには線が 2 本出ます。

マップはフォルダを 1 つずつ描きます。1 つの階は次のように描きます。

フォルダ直下の、リンクを持つノードを 1 台ずつ描きます。
サブフォルダは 1 つの箱です。中の台数と、止まっている台数を出します。箱を押すと中に入ります。見出しのパンくずで上に戻れます。
同じ 2 つを結ぶリンクは、1 本の線にまとめて本数を出します。線を押すと、両端のポートの一覧が出ます。
フォルダの外へ出るリンクは、点線の箱で終わります。押すと、両端が見える階が開きます。

拠点（種類が Site のフォルダ）と、その下のフォルダは、箱にせず並べて描きます。拠点の中でリンクを持つ機器を全部描き、名前の下に、その機器のフォルダまでの道筋を書きます。同じ拠点の別のフロアへ出る線の先には、相手の機器の点線の箱を描きます。

機器は、ネットワークの中での役割ごとに段に分けて積みます。

ルーターとファイアウォール。
ルーティングするスイッチ。
ルーティングしないスイッチ。
その他すべて。

役割は、Yagra が既に集めている情報から決めます。Meraki の製品種別、ルーターかファイアウォールのデバイスプロファイル、拠点の外へ向いた既定経路、OSPF か BGP の隣接、2 つ以上のサブネットにアドレスを持つこと、です。ノードを選ぶと、役割とその理由が出ます。ルーターもスイッチも無い階は、リンクだけを見て並べます。

ルーティングしていて、IPv4 の既定経路が拠点の外を向いている機器は、拠点の出口とみなします。拠点の外とは、次の 2 つのどちらかです。

行き先が、拠点のどの機器のアドレスでもなく、拠点の別の機器が使っているサブネットの中でもない。
ゲートウェイを持たずに、インターフェースへ向いている。

出口の機器は、プロファイルがルーターと言っていなくても最上段に置きます。サブネットの条件があるので、ルーターの HSRP や VRRP のアドレスへ向いたコアスイッチは上がりません。Yagra が監視していないファイアウォールの内側にある機器は、Yagra から見えるいちばん外側なので、出口とみなします。

Wi-Fi のアクセスポイントは、箱ではなく小さな丸い記号で描きます。縁の色が状態です。同じ機器に 2 台以上つながっているときは、1 つの束にまとめて描きます。

束には台数を書き、縁を状態ごとの台数の割合で塗り分けます。
束の下に、台数と、正常でない台数を書きます。
束を選ぶと、右の欄に中のアクセスポイントが、機器のどのポートにつながっているかごとに並びます。 1 つのポートに何台もいるときは、間に Yagra が監視していないスイッチがあることが多いです。

1 台だけのアクセスポイントは、名前つきで 1 台ずつ描きます。その機器の下の段にスイッチもつながっているときは、アクセスポイントを機器の下ではなく横に描きます。下へ向かう線と重ならないようにするためです。

階の中で機器を探すには、地図の上の検索欄に入力します。ホスト名で探し、一覧の列フィルタと同じく正規表現と NOT も使えます。当たった機器は枠で目立ち、それ以外は薄くなります。配置は動きません。束は、中の 1 台でも当たれば目立ちます。Enter で次の一致を地図の中央へ寄せます（Shift+Enter で前の一致）。

Nodes 画面でフォルダを選んだときに出る地図にも、同じ検索欄があります。地図の見出しの行にあります。フォルダを移っても、検索は消えません。大きく開く を押すと、検索ごと全画面の地図へ渡します。

リンクのあるノードが 2,000 台、または線が 4,000 本を超える階は描きません。サブフォルダだけを出し、そのことを知らせます。右の欄には、その階にあるものの数と、リンクに解決できなかった観測の数を出します。

これらを支える走査は、既定で 1 時間ごとに動きます。設定 ▸ 監視の既定値 ▸ ネットワーク探索の走査 に、種類ごとのスイッチがあります（隣接情報 CDP/LLDP、インターフェースアドレス、ルーティング隣接 OSPF/BGP、ARP キャッシュ）。同じ画面には 5 本目のスイッチとしてインターフェースのメディア種別 の走査もあります。こちらはマップではなく、ノードの Interfaces タブのメディア列を埋めるものです。

読む表の大きさは、機器自身が持つピアの数に比例します。ネットワーク全体の規模には比例しません。 ルーティングテーブルを表として歩くことはありません。 フルルートを持つルータでは数十万行になってしまうからです。

代わりに Yagra は、宛先を 1 件ずつ問い合わせます。しかも相手は、自分自身がホストアドレスを持っている機器だけで、上限は 64 宛先です。通常の機器しかないフリートでは、この問い合わせは 1 件も発生しません。

すべての機器に問い合わせる経路は、既定経路の 1 つだけです。拠点の出口を見分けるためです（上を参照）。機器 1 台あたり 1 時間に 1〜2 回の短い読み取りで、約 2 KB です。

知っておくと役に立つ挙動が 2 つあります。

セッションが落ちていても、リンクは描かれます。 active の BGP セッションは「障害のあるリンク」であり、まさにそれが調べたい対象だからです。

ループバック同士の iBGP は、リンクになりません。 ピアを隣接とみなすのは、報告した機器が終端しているネットワークの上に、ピアのアドレスがあるときだけです。ですからルートリフレクタが、全クライアントへ伸びる偽の star を持ってしまうことはありません。

既知の制限も、ぼかさずに挙げておきます。BGP4-MIB は IPv4 専用なので、IPv6 の BGP ピアは対象外です。OSPF の収集は OSPFv2 で、仮想リンクは読みません。

またメンバーが 3 つ以上あり、どれがルータか特定できないセグメントでは、推測でリンクを作りません。 何も描かず、マップの集計にだけ数えます。

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

監視していないホスト

監視中の機器は、インベントリに無い機器をすでに見ています。Yagra はそれを ノード ▸ ディスカバリ ▸ 未登録の機器に並べます。範囲の指定は要りません。一覧のもとになるのは、次の 4 種類です。

管理アドレスを知らせてくる LLDP / CDP の隣。 電話や端末だけを名乗る隣は除きます。アクセススイッチの先の電話で一覧が埋まらないようにするためです。
OSPF の隣と BGP の相手。
どのノードのものでもない syslog / SNMP トラップの送り手。
ルータの ARP / IPv6 近隣キャッシュにあるホスト。 その走査を有効にしたときだけです（下の囲みを参照）。

有効にする必要があるのは ARP だけです。各行には、アドレスと、隣や syslog のヘッダーが名乗った名前が出ます。どこで見えたかも出ます。出どころごとの印と、それを見た機器とポートです。一覧は 100 行ずつ読みます。さらに 100 件読むで次のページを読みます。続きがあるあいだは、絞り込みは読み込んだ行だけを探します。画面にもそう出ます。

行から追加する手順：

表の上の試す認証情報で、SNMP の認証情報を選びます。 範囲をスキャンも同じ一覧を使います。どちらのタブで変えても、両方に効きます。
自動検出を押します。Yagra はその 1 台に認証情報を試し、答えからプロファイルを選びます。
埋まったプロファイルと認証情報を確かめます。何も答えなかったときは、手で選びます。
表の上で追加先を選びます。追加先のフォルダーに選んだフォルダーへ入ります。 IP レンジで振り分けるが ON（既定）なら、アドレスを含む IP レンジを持つフォルダーがあれば、そちらへ入ります。監視を開始の上の 1 行が行き先を示します。どのフォルダーのレンジにも入らないときは、警告の印が付きます。 IP レンジを持つフォルダーが 1 つも無いあいだは、IP レンジで振り分けるは出ません。
監視を開始を押します。範囲スキャンと同じ取り込みの経路を通って、ノードになります。

誰にどの行が見えるか。 一部のフォルダに限られたアカウントには、最初にその機器を見たノードが自分のフォルダにある行だけが出ます。証拠も、自分のフォルダのノードが報告したものだけが出ます。 syslog やトラップの送り手だけが根拠の行は、制限の無いアカウントにだけ出ます。

NAT の内側では、送り手のアドレスは変換装置のアドレスになります。証拠としては出しますが、それだけで取り込むことはしません。

送り手だけが根拠の行には、自動検出も監視を開始もありません。 syslog やトラップの送信元アドレスは偽れます。検出すると、認証情報が偽った相手に届いてしまいます。そのため、この行は情報として出すだけです。自分の機器なら、ノードを追加から足してください。一覧がいっぱいのときは、監視中の機器が見た行を先に残します。偽の送り手を大量に送っても、本物の機器は押し出されません。

一部のフォルダに限られたアカウントは、見えるフォルダーへ取り込みます。 そのアカウントにはツリーのルートが見えません。そのため、ルートに入る取り込みは断ります。フォルダーを選んでください。範囲スキャンの取り込みも同じ理由で、ルートに入る行が 1 つでもあれば断ります。

スキャンは要りません。すでに動いているポーリングの副産物として得られます。

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

同じ隣を、機器の側から見る。 ノードの隣接タブには、各ポートが CDP と LLDP で聞いている相手が並びます。ほかに次のものも出ます。

アドレス —— 隣の管理アドレスです。隣の名前の横の印が、そのアドレスがここで何なのかを示します。 監視中、見えないフォルダのノードなら監視中（範囲外）、複数のノード、未監視のどれかです。監視の列で絞り込めます。
2 台以上のノードが持つアドレス —— 隣が送った名前と一致するノードがちょうど 1 台あれば、そのノードにリンクします。見えないフォルダのノードは、この方法では選びません。その行は複数のノードのままです。どちらの場合も、名前の横にアドレスが重複している印が付きます。行を開くと、ほかのノードの一覧と、そのアドレスを載せたポートにリンクがあるかどうかが出ます。
機種 / OS —— CDP の機種と OS 版、または LLDP のシステムの説明です。
MAC アドレスのシャーシ ID には、IEEE に登録されたメーカー名が出ます。これはネットワークの部品のメーカーです。機器そのもののメーカーとは限りません。

監視していない隣には監視を設定ボタンが付きます。未登録の機器タブと同じ自動検出、追加先のフォルダー、監視を開始の手順が開きます。無線コントローラーが報告しているアクセスポイントは、そのコントローラーから追加します。Meraki の組織が持っている機器は、その組織のページへ案内します。ボタンが無いときは、その場所に理由を出します。たとえば、未登録の機器の一覧にまだ載っていない（一覧は 5 分ごとに作り直します）、相手が電話機だと名乗っている、自分のフォルダーの外のノードが見つけた、などです。

Meraki のスイッチ（MS）、MX、アクセスポイント（MR）にも隣接タブが出ます。隣は Meraki Dashboard から読みます。MX は LAN 側の口で聞こえる相手を出し、インターネット側の口の相手は出しません。 MR は有線の口で聞こえる相手を出します。多くはつながっているスイッチです。管理アドレスを送ってこない Meraki の相手は、組織の機器一覧にある MAC で突き合わせます。そのため、その行でも監視中かどうかが分かります。

スイッチは、ほかの機器の隣の収集と同じ頻度で読みます（既定は 1 時間ごと）。MX と MR は、組織の Dashboard API の速さの範囲で 1 台ずつ読みます。そのため大きな組織では、1 巡がそれより長くかかります。既定の速さで MX と MR が 2,300 台なら、約 2 時間です。

アップグレードで Yagra の隣の書き方だけが変わったときは、その機器の隣接の履歴に 1 件だけ アップグレードで記録の書き方が変わりました。配線の変化ではありません。 と印の付いた記録が入ります。その行は畳んで出し、隣がどれだけ変わらずに続いているかはリセットしません。

しきい値

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

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

しきい値を掛けられるのは、ゲージのメトリクスだけです。 カウンタのメトリクスには掛けられません（if_hc_in_octets、エラーや破棄のカウンタなど、収集カタログがカウンタと宣言しているものです）。

カウンタに掛けると、増え続ける生の累計を境界値と比べることになります。上回るルールは、カウンタが境界を越えた時点で鳴りっぱなしになります。下回るルールは、機器の再起動でカウンタがリセットされるたびに、幻のアラートを上げます。

ですから Yagra は、作成そのものを拒否します。カウンタのメトリクスに対する POST /api/v1/thresholds は 400 counter_metric を返します。すでにあるカウンタのサンプルは OK として読むので、古いルールが鳴らしっぱなしにしていたアラートも、通常の復旧経路で解消します。

カウンタをレートで見たいときは、問い合わせ側で扱ってください。しきい値は、ゲージに掛けるものです。
しきい値の一覧を見るには、監視の管理（manage-monitoring）の権限が要ります。 Operator 以上が持つ権限で、単なる閲覧権限では足りません。しきい値の集合は「Yagra がいつ誰を呼び出すか」を書いたものなので、公開ダッシュボードでも閉じたままにします。認証していないリクエストには 401 を返します。

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

ルールが適用される範囲

ルールは必ずスコープを 1 つ持ちます。スコープは 6 種類です。広いほうから順に、全ノード、デバイスプロファイル、ノードのタグ、フォルダグループ、ノード 1 台、インターフェース 1 本です。

当てはまるもののうち、いちばん狭いスコープが勝ちます。プロファイルのルールが標準の値を決め、ノードのルールが 1 台だけ上書きし、インターフェースのルールが 1 ポートだけさらに上書きします。同じ階層で 2 つが当てはまる場合は、より厳しい値を使います。

1 つのルールで、その階層の対象を複数指名できます。たとえば Cisco IOS 系の 2 プロファイルを、ルール 2 本ではなく 1 本で指せます。指名できるのは最大 32 件までで、インターフェースのルールは今までどおりポート 1 本だけです。

インターフェースのスコープがあるのは、使用率・エラー・光レベルがポートごとの値だからです。ノードに書いたルールでは、その機器の全ポートを同じ値で縛ることになります。

表の行ごとに値が出るメトリクスは、行ごとに判定します。行とは、メモリプール、CPU、温度センサーのことです。行ごとに別のチェックになり、アラートには行の名前が入ります。たとえば cisco_mem_used_pct on I/O above 80 (was 83.9) です。Device health には、値の高い 5 行が名前付きで並びます。それより多い機器では、最後に「ほか N 行」と出ます。

ルールの 行の名前 欄に書くと、効かせる行を指定できます（I/O、MPU Board *）。

* は任意の文字列です。大文字と小文字は区別しません。空欄なら、すべての行に効きます。
同じスコープでは、行の名前を指定したルールが、指定の無いルールより優先します。優先するのは、名指した行についてだけです。これで、全行向けのルールと並べて 1 つのプールだけ緩めたり厳しくしたりできます。
スコープの狭さのほうが先に効きます。行の名前が無いノードのルールは、行の名前があるプロファイルのルールに勝ちます。
ポーラーは、行の名前を 1 時間に 1 回、機器から読みます。名前をまだ読んでいない行には、行の名前を指定したルールは一致しません。その間は、全行向けのルールが効きます。

タグのスコープは新しいルールでは選べません。同じ範囲はフォルダグループで表せて、ダイアログが作るのもそちらです。既存のタグのルールはそのまま解決され続けます。v0.3.17 からは探す相手もできました。タグは WebUI から編集できるようになり、ルールはノードが 実効的に 持つタグ — そのノード自身のものと、フォルダの連なりが与えるもの — に一致します。

新規インストール時に入っているもの

新規インストールには、到達性、SNMP の到達性、パケットロス、遅延、SNMP walk の完全性、CPU、メモリ、温度、ディスク、UPS のバッテリー、BGP ピアの状態のルールが入ります。ベンダー固有の値は、それが当てはまるプロファイルを指しています。組み込みの URL 監視と DNS 監視のプロファイルにも、それぞれのルールが入っています（たとえば DNS 監視の dns_up）。ですから新しい監視は、設定しなくてもアラートを上げます。

行の名前を指定した既定のルールが 1 本あります。Cisco IOS の I/O メモリプールは、90% で warning、 95% で critical です。このプールには、スイッチが前もって確保するパケットバッファが入ります。そのため健全なスイッチでも高い値のままです。ほかのプールには、通常のメモリのルールが効きます。

30 本はすべて普通のルールで、ノードの up/down も含みます。これまで到達性のアラートはアラートエンジン内の定数から出ており、変更する手段がありませんでした。いまは全ノードのスコープに置かれた 到達性 のルールから出ます。連続 3 回の失敗という条件も同じまま初期投入されるので、アップグレードで既存の環境の発報の早さは変わりません。変わるのは、値を調整できること、プロファイル・グループ・ノード単位で上書きできること、そして削除できることです。

削除すると、その範囲のノードダウンの通知が止まります。一覧でのノードの状態表示、フリートサマリ、親障害による抑制は影響を受けません。これらはアラートではありませんし、アラートルールを消すことは「そのノードを追わなくてよい」という依頼ではないからです。

ポーリング動作

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

間隔。 新しくインストールしたときの既定のポーリング間隔は 300 秒（5 分）で、10〜3600 秒の範囲に収められます。既にあるデプロイは、保存済みの間隔をそのまま使います。

5 分間隔だと、応答しなくなったノードがダウンと判定されるのは約 15 分後です。既定の到達性ルールが、 3 回続けて失敗するのを待つからです。それでは遅い場合は、設定 ▸ 監視の既定値か、デバイスプロファイルで間隔を短くしてください。

YAGRA_POLL_INTERVAL_SECS の環境変数が効くのは、初回起動のときだけです。それ以降は、データベースに保存された設定が正です（WebUI で編集できます）。デバイスプロファイルごとの間隔を決めれば、全体の既定を上書きできます。

ノードを追加したときや、間隔を変えたときは、すぐに反映されます。スケジューラの次の周回を待ちません。
ジッタ。 ポーリングの時刻は少しずつずらします。数万のノードが同じ瞬間に一斉に動いて、ネットワークやポーラーを圧迫しないようにするためです。
1 デバイスにつき、同時に 1 プローブ。 遅いデバイスに対して、プローブが積み上がることはありません。次のプローブは、前のプローブを待ちます。

DNS 監視だけは、意図的な例外です。設計上リゾルバという同じ相手を共有するので、対象ごとの上限ではなく全体の上限で制御します。
全体の同時実行数の上限。 YAGRA_MAX_CONCURRENT_POLLS（既定 256）が、ポーラー 1 台あたりの同時プローブ数を制限します。これに加えて、デバイスごとのレート制限と流量調整も働きます。これは速さの上限ではなく「同時に何本走らせるか」で、得られる 1 秒あたりのポール数はこの数を 1 本あたりの所要時間で割った値になります。間に合っているかどうかは yagra_poll_cycles_missed_total が答えます。

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

ポーラーは状態を持たず、台数を増やすだけで規模を広げられます。作業がプールや拠点をまたいでどう配られるか、そしてリモートのポーラーがネットワークの切断をどう乗り切るかは、分散ポーリングで扱います。

監視