NATセッション数で回線障害を予兆検知するルータ監視

同じ値を10分ごとに採っていれば、過去2回のDNS障害はいずれも落ちる前に気付けました。見るべき値は、端末の死活だけではありません。全通信の上流にあるルータの、NATセッション数です。

以前に記録したMAP-Eポート枯渇の記録では、DNSが不安定になった時点で、すでにネットワーク側の余力は失われていました。もう一件もIPv6側の戻り経路の状態が原因でした。いずれも当時は時系列データがなく、障害後に推定するしかありませんでした。

そこで某所ラボでは、家庭用ルータから読み取り専用で値を定期取得し、パース済みの1行JSONとして残すようにしました。目的は詳細な常時記録ではなく、「まだ使えているが、このままでは危ない」を見つけることです。

NATセッション数を先行指標にする

ホストがdownした、pingが失敗した、DNSが解決できない。これらは重要な監視項目ですが、基本的には遅行指標です。異常が利用者に届いた後で、「もう落ちている」と知らせます。

一方、NATセッション数は資源の上限へ近づく過程を示します。セッション数が継続して増え、余裕が縮んでいる段階なら、下流のホストやDNSに症状が出る前に調査・負荷抑制・詳細記録を始められます。NATセッション数だけで全障害を説明できるわけではありませんが、家庭ネットワークで見落とされがちな上流の先行指標です。

実際の定期収集では、次の値を同じ時刻にまとめています。

• CPU負荷とメモリ使用率
• NAT（MAP-E）セッション総数
• 内側アドレス別の上位ホスト
• IPv6動的セッション数
• トンネル状態とトンネル累積オクテット

大切なのは、生の表示を後から大量に処理することではありません。定期取得の時点で必要な項目に整形し、1回分を1行JSONにして追記します。大量データは、大量になる前に潰します。

平常時は10分ごと、異常時は詳細を保存する

収集間隔は10分ごとです。1行は約380バイト、1日144行で約21KBです。このサイズなら、常時収集を年単位で続けることが負担になりにくいでしょう。ログファイルは8MBを超えた時点でgzipへ退避します。

ただし、定常ログを最初から詳細化しすぎると、保存量も確認コストも増えます。そして障害時に本当に欲しいのは、平常時の冗長な詳細ではなく、異常を踏んだ瞬間の揮発テーブルです。

そこで記録を二層に分けました。

厚い記録を起動する条件は、トンネル断、NATセッション数が1200以上、IPv6セッション数が600以上です。記録の暴発を避けるため、発火後には1時間のクールダウンを置きます。必要なら手動でも起動できます。

この構成なら、平常時の保存量を抑えつつ、異常の瞬間にだけ調査可能な密度を得られます。過去2回の障害では時系列がなかったため事後推定に頼りましたが、NATセッション数を追えていれば、どちらも早期検知につながったはずです。

画面変更・時刻ずれ・取得失敗を監視する

家庭用・SMB向けルータの多くには、監視向けの整ったメトリクスAPIがありません。実装では機器自身の人間向け表示を読み取り、必要な値へパースする場面が出てきます。

ここには明確な制約があります。ファームウェア更新などで出力書式が変われば、収集側は静かに壊れる可能性があります。しかもパース失敗を値ゼロとして扱うと、「正常に見える」監視画面を作ってしまいます。

欠測はゼロではありません。取得できなかった値は欠測として明示し、収集そのものが壊れていないかを別途確認できるようにします。この考え方は、GPUの進捗監視で扱った、状態が正常でも処理は進んでいないという問題にも通じます。下流の状態表示だけを信じず、観測の鮮度と上流の余力を確認する必要があります。

設定差分は変更があった日だけ残す

メトリクスと同様に、設定の保存も無条件に増やしません。設定は日次で取得し、ハッシュで重複を判定して世代保存します。変化がなければ「unchanged」として何も残さず、変化したときだけ世代ファイルを作り、通知します。

変わらない設定は1バイトも使わず、変化だけを記録する設計です。設定ドリフトや想定外の変更を見つける用途にもなります。なお、保存対象の設定表示で秘密情報が*としてマスクされることは、実測で確認済みです。それでも、自分の機器では公開・保存範囲を事前に確認してください。

ルータ監視を追加する判断条件

ルータ監視を追加する価値があるのは、「回線が落ちたら通知が来ればよい」ではなく、「次に不安定になる前に何が逼迫していたかを知りたい」と考える場合です。逆に、収集スクリプトの保守や欠測の確認まで引き受けられないなら、まずは既存の死活監視を整え、障害記録を残すところから始める方が安全です。

導入前に確認する4項目

1. 監視がエンドポイントだけになっていないか。上流にあるルータのセッション数を採れているか。
2. 定常収集は1年放置できるサイズか。1行あたりの保存量を説明できるか。
3. 閾値を踏んだ瞬間にだけ詳細を残す仕組みがあるか。
4. 設定を世代で持ち、変化した時だけ残せているか。

ホームラボの監視は、何でも細かく保存するほど良くなるわけではありません。定常収集は、続けられるほど薄くする。異常時だけ、調査に足るほど厚くする。その二層を分けると、記録は運用の負担ではなく、次の障害を短くする材料になります。

所長の運用でも、過去の障害を「次は分かる」に変えるために必要だったのは、複雑な監視基盤ではありませんでした。上流の余力を、継続できる小ささで記録することです。平常時は薄く、異常の瞬間だけ厚く採る。この原則から始めてください。