家のWAN回線がぽろぽろ落ちる原因を Prometheus + Grafana で見える化した

はじめに

自宅のインターネットがたまに切れます。仕事中に Zoom が落ちることもあれば、ゲーム中にラグが入ることもある。最初は気のせいかと思っていたのですが、Cisco C1111 のログを見たら WAN 側のリンクが物理的に落ちて復旧する を繰り返していました。

ルータも置き換えられない、回線契約も変えられない、ケーブルも宅内設備の途中にある JJ コネクタ で繋がっている状態。手の届く範囲が極端に狭い中で、まず「いつ、どれくらいの頻度で、どんなパターンで落ちているのか」を見える化することにしました。

本記事はその監視構築と、14 日間集めたデータをどう解釈したか、そして次にどんな物理交換を試すかまでの記録です。結論から言うと、データはまだ十分ではなく、原因は「ランダム性のある物理接触不良」という仮説のまま、物理層への介入フェーズに入ります。 続編は物理交換後にあらためて書きます。

背景: マンション備え付け回線という制約

私の住まいはマンションタイプの備え付けインターネット回線です。回線種別もプロバイダも、契約上は自分で変更できません。宅内に光コンセントが来ていて、そこから ONU、Cisco C1111-8P の WAN ポート (Gi0/0/0) に LAN ケーブルで繋いでいる構成です。

ある日、ONU と C1111 の間のケーブル経路をよく見たら、壁内配線と宅内配線の境目で JJ (Jack-to-Jack) コネクタ が挟まっていました。JJ はメスメスの中継コネクタで、規格上は永続配線 (Permanent Link) 側で使うものです。Patch ケーブル区間に挟むことは推奨されていませんが、なぜか挟まっている。しかも壁内側のケーブルカテゴリが不明で、宅内側と混在している疑いがあります。

物件オーナーの設備が一部入っているため、勝手に剥がせない構造です。やれることは限られています。

症状の現れ方

• Zoom や WebRTC 系の通信が突然切れる
• ゲームの ping が一時的に飛ぶ (タイムアウトに近い揺れ)
• C1111 のシステムログに %LINK-3-UPDOWN と %LINEPROTO-5-UPDOWN が GigabitEthernet0/0/0 で交互に記録される
• ケーブルを一度抜いて挿し直すと、しばらく安定する

物理層っぽい振る舞いです。ただ、頻度が高くないので「気のせいかも」と思える境界線にいて、本格的に追いかけるトリガーがなかなか引けない、というのが厄介でした。

一次調査: show interfaces のカウンタを読む

まずやることは、C1111 にログインして show interfaces GigabitEthernet0/0/0 を 1 回叩くことです。瞬間値ではなく、起動からの累積カウンタが見えます。

2026-04-22 時点で取った主要カウンタは以下でした。

Chirarin_RT#show interfaces GigabitEthernet0/0/0
GigabitEthernet0/0/0 is up, line protocol is up
  Hardware is C1111-2x1GE
  ...
  5 minute input rate 2403000 bits/sec, 313 packets/sec
  5 minute output rate 1484000 bits/sec, 166 packets/sec
  reliability 255/255, txload 1/255, rxload 1/255
  0 runts, 775 giants, 0 throttles
  3008 input errors, 3007 CRC, 0 frame, 0 overrun, 0 ignored
  0 output errors, 0 collisions, 1 interface resets
  115 lost carrier, 0 no carrier, 0 pause output

このうち、原因切り分けで重要なのは次の三つです。

lost carrier がカウントされている時点で、物理層でリンクが落ちている事実は確定です。あとはどれくらいの頻度か、どんなタイミングか、です。

19 日後の 2026-05-11 に同じコマンドを叩くと、差分はこうなりました。読んだのは 04-22 00:00 と 05-11 00:00 の 2 時点です (この後に出てくる SNMP の集計窓 04-27 00:00 〜 05-11 12:00 とは重なるだけで、入れ子にはなっていません)。

lost carrier は 約 1 日に 1 回弱のペースで増えている。CRC は 1 日 10 回弱。

reliability はこの 2026-04-22 の出力で 255/255 でした (05-11 側の reliability は記録が残っていないので、19 日間ずっと満点だったかは確かめられません)。IOS の reliability は load-interval (既定 5 分) の指数移動平均を 255 分率で表す指標なので、1 日 1 回未満の低頻度な障害は、累積カウンタが増えていても満点表示に埋もれます。

TDR が使えなかった話

物理層が怪しいなら、ケーブル診断機能の TDR (Time Domain Reflectometry) を試したくなります。Cisco IOS には test cable-diagnostics tdr interface <intf> というコマンドがあって、ケーブルのオープン/ショート/長さを反射で測ってくれる、はずでした。

C1111-8P の Gi0/0/0 で叩いてみた結果がこれです。

Chirarin_RT#test cable-diagnostics tdr interface GigabitEthernet0/0/0
Chirarin_RT#show cable-diagnostics tdr interface GigabitEthernet0/0/0

% TDR Port Data not ready

同時に syslog へ %PM-4-NO_SUBBLOCK: No PM subblock found for Gi0/0/0 が記録されます。test コマンドは受け付けられるのに、結果を取り出す段で「データが無い」と言われる、という落ち方です。

syslog のメッセージが示すとおり、WAN 側内蔵ポートには TDR 用の Port Manager サブブロックが登録されていません。機能そのものがこのポートに実装されていない、と読むのが素直です。

LAN 側の Gi0/1/0〜Gi0/1/7 (内蔵スイッチポート) は機種によっては TDR に対応するとされますが、本機で実際に走らせて確かめてはいません (show cable-diagnostics tdr interface Gi0/1/0 は「まだ一度も実行されていない」と返ります)。稼働中のポートに TDR をかけるとリンクが瞬断するため、試すならメンテナンス時間帯に限ります。

つまり、C1111 の WAN は 物理層を IOS から覗くインターフェースがほぼ存在しない。手元で取れるのは SNMP の if カウンタと、syslog の UPDOWN メッセージくらい。

この時点で方針が決まりました。TDR で物理を一発診断する道は閉ざされたので、SNMP で時系列パターンを取って原因を絞り込む。

監視を組む: snmp_exporter + Prometheus + Grafana

自宅にはすでに監視 VM (chillarin-ops, 172.16.1.151) があり、Prometheus と Grafana が動いています。ここに snmp_exporter を足して、C1111 から SNMP v2c でメトリクスを引き抜く構成にしました。

全体構成

SNMP v2c を使っているのは家庭内の閉じたネットワークだから……という言い訳で始めたのですが、v2c の community は平文で流れる実質の共有パスワードです。**最低でも snmp-server community <文字列> RO <ACL 番号> で送信元を監視ホストに絞り、可能なら v3 にしてください。**この記事では community 文字列を伏字にしています。

なお 10.1.1.254 は SNMP エージェント (ルータ) の管理アドレスであって、WAN ポート Gi0/0/0 のアドレスではありません。Gi0/0/0 は ISP から DHCP で払い出されるアドレスで、10.1.1.0/24 は宅内 LAN 側です。Prometheus の instance ラベルは「どの機器に SNMP を投げたか」を指しています。

snmp.yml の罠: metrics: 欠落で series が 0 になる

snmp_exporter は snmp.yml という設定ファイルで walk する OID と、Prometheus メトリクスとして公開する OID を別々に書きます。これを最初混同して、walk セクションだけ書いて起動したら、scrape は成功するのに メトリクスが 0 件 という状態になりました。

# これだと walk はするけど Prometheus には何も出てこない
modules:
  if_mib:
    walk:
    - 1.3.6.1.2.1.2.2
    - 1.3.6.1.2.1.31.1.1

metrics: セクションを書かないと、exporter は OID ツリーを歩くだけで値を返してくれません。正しい書き方は以下です。

modules:
  if_mib:
    walk:
    - 1.3.6.1.2.1.1
    - 1.3.6.1.2.1.2.2
    - 1.3.6.1.2.1.31.1.1
    metrics:
    - name: ifNumber
      oid: 1.3.6.1.2.1.2.1
      type: gauge
    - name: ifIndex
      oid: 1.3.6.1.2.1.2.2.1.1
      type: gauge
      indexes:
      - labelname: ifIndex
        type: gauge
    - name: ifDescr
      oid: 1.3.6.1.2.1.2.2.1.2
      type: DisplayString
      indexes:
      - labelname: ifIndex
        type: gauge
    - name: ifOperStatus
      oid: 1.3.6.1.2.1.2.2.1.8
      type: gauge
      indexes:
      - labelname: ifIndex
        type: gauge
      lookups:            # これが無いと ifName ラベルが付かない
      - labels: [ifIndex]
        labelname: ifName
        oid: 1.3.6.1.2.1.31.1.1.1.1
        type: DisplayString
    - name: ifInErrors
      oid: 1.3.6.1.2.1.2.2.1.14
      type: counter
      indexes:
      - labelname: ifIndex
        type: gauge
      lookups:
      - labels: [ifIndex]
        labelname: ifName
        oid: 1.3.6.1.2.1.31.1.1.1.1
        type: DisplayString
    # ... ifType / ifMtu / ifSpeed / ifAdminStatus / ifLastChange / ifInDiscards /
    #     ifOutErrors / ifHCInOctets / ifHCOutOctets / ifHighSpeed を同じ形で並べて計 15 メトリクス

lookups: は飛ばさないでください。 これを書かないと出てくる系列は ifOperStatus{ifIndex="1"} のままで、ifName ラベルが付きません。この記事に出てくる PromQL は全部 ifName="Gi0/0/0" で絞っているので、lookups: を落とすとアラートもダッシュボードも集計クエリも、エラーを出さずに空振りします。ifIndex はリロードで変わり得るので、インターフェース名で絞れる形にしておくのが安全です。

なお community は snmp.yml の先頭に auths: ブロックで定義し、Prometheus 側から auth パラメータで指定します (snmp_exporter 0.21 以降の書き方)。

auths:
  chillarin_v2:
    community: <YOUR_COMMUNITY_STRING>
    version: 2

特に 1.3.6.1.2.1.2.2.1.8 = ifOperStatus が今回の主役です。値は 1=up, 2=down で、これの変化回数を Prometheus の changes() 関数で数えれば flap が見えます。

この metrics: 欠落でハマったのは半日くらいで、原因に気付くまで「Prometheus 側の relabel が悪いのか」「community 文字列が違うのか」と無関係な場所を疑いました。教訓は、snmpwalk -v2c -c <community> <ip> 1.3.6.1.2.1.2.2.1.8 を直接叩いて値が返ってくるか先に確認すること。コマンドラインで返ってくるのに Prometheus で見えないなら、snmp_exporter 側の問題です。

prometheus.yml の job 定義

snmp_exporter は /snmp?target=<ip>&module=<module> というクエリで動くタイプなので、Prometheus 側で relabel して target を渡します。

scrape_configs:
  - job_name: snmp_network
    scrape_interval: 30s
    static_configs:
      - targets:
          - 10.1.1.254   # Chirarin_RT (Cisco C1111)
    metrics_path: /snmp
    params:
      module: [if_mib]
      auth: [chillarin_v2]   # snmp.yml の auths: で定義した名前
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp-exporter:9116

掲載しているのは WAN ルータ 1 台に絞った抜粋です。実際には同じジョブで L3SW・L2SW・AP も見ているので、後で出てくるスクリーンショットには 10.1.1.254 以外の instance も写っています。

scrape_interval: 30s は「これで十分」ではなく「30 秒より短いダウンは原理的に見えない」という割り切りです。ifOperStatus はイベントログではなく 30 秒ごとの状態のサンプル列なので、ダウンしている間に 1 回も scrape が当たらなければ系列は 1 のままで、changes() は 0 のままです。changes() が up→down→up を「変化 2 回」と数える性質は、この取り逃しを一切埋めてくれません。

実際、後述の 19 日間の lost carrier は +17 なのに、同じ期間に SNMP で捕捉できたダウンはずっと少ない。差の多くはこの解像度で落ちていると考えるのが自然です。短い瞬断まで数えたいなら、SNMP のポーリングではなく syslog (%LINK-3-UPDOWN) を Loki 等に流して数えるべきでした。

Alert ルール: flap を即時警告にする

alert_rules.yml には三段構えのルールを書きました。

groups:
- name: wan_link
  rules:
  - alert: WANLinkDown
    expr: ifOperStatus{instance="10.1.1.254",ifName="Gi0/0/0"} == 2
    for: 30s
    labels:
      severity: critical
    annotations:
      summary: "WAN link is DOWN (Gi0/0/0)"

  - alert: WANLinkFlapping
    expr: changes(ifOperStatus{instance="10.1.1.254",ifName="Gi0/0/0"}[30m]) >= 4
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "WAN link flapping detected (>=4 changes in 30m)"

  - alert: WANInputErrorsIncreasing
    expr: rate(ifInErrors{instance="10.1.1.254",ifName="Gi0/0/0"}[10m]) > 0
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "WAN input errors are increasing"

changes(ifOperStatus[30m]) >= 4 の意味は、「30 分以内に up/down が 4 回以上変化したら flapping とみなす」。down→up→down→up で 3 回、もう 1 回変化したら 4 回です。瞬断 1 回では発火しないけれど、短時間に何度も落ちる時はすぐ気付ける、というバランスにしました。

WANInputErrorsIncreasing は CRC や input error が増え続けている状態を検知します。これは flap が起きていなくても、信号品質の悪化を早期に拾うためのものです。

Grafana ダッシュボード

ダッシュボードは 10 パネル構成にしました (URL: http://172.16.1.151:3000/d/wan-link-monitoring/)。

特に重要なのは 1 番の state-timeline と 2 番のヒートマップです。state-timeline はパッと見で「あ、この時間帯に細い赤い線が入った」と分かるので、家族から「ネット切れた」と言われた時に該当時刻を即座に確認できます。

ヒートマップは規則性を探すために置いたパネルです。ただし changes(...[1h]) をそのまま流し込むと、Y 軸は「曜日」ではなく「flap 数」になります (パネル名に「曜日×時間」と付けたのは私の設定ミスで、実際には曜日軸になっていません)。曜日で切りたいなら系列を曜日ごとに分けるか、集計を Grafana の外でやる必要があります。後述しますが、結果として規則性は出てきませんでした。

ダッシュボード JSON の全量は有料コンテンツ (Grafana ダッシュボード集) 側に置く予定です。本記事では設計判断と PromQL の中身を共有することにしました。

14 日間集めたデータをどう解釈したか

監視を仕掛けてから 2 週間ほど経った時点 (2026-04-27 00:00 〜 2026-05-11 12:00 JST) で、Prometheus に query_range を投げて 1 時間バケットで集計しました。この窓は正確には 14.0 日ではなく 14.5 日です (以下では慣用として「14 日間」と呼びます)。

GET /api/v1/query_range
  ?query=changes(ifOperStatus{instance="10.1.1.254",ifName="Gi0/0/0"}[1h])
  &start=2026-04-27T00:00:00+09:00
  &end=2026-05-11T12:00:00+09:00
  &step=3600

以下の表・グラフの時刻はすべて JST です。上のクエリは当時の内容を再構成したもので、実際に投げた文字列は記録に残っていません。 この後の集計表のバケット時刻が全部 :10 で揃っていることから、実際の start は 00:10 側にずれていたはずですが、そこまでは復元できませんでした。

結果のサマリーがこれです。

14 日間の集計

この「10 回」は changes() が数えた状態遷移の回数であって、リンクが落ちた回数ではありません。 changes() は up→down→up を「2」と数えるので、10 遷移から復元できる「落ちて戻った」サイクルは 5 回です (内訳は後述の個別イベント表)。以降で「14 日間で 10 回」と書いているのは全部この遷移数のことです。

1 日あたり 0.71 回 (遷移数を 14 で割った値。窓の実スパン 14.5 日で割れば 0.69、サイクル数で数えれば 0.36) 。毎日必ず落ちるわけではないので体感では気付きにくく、かといって「たまたま一度」で片付けられる頻度でもありません。サンプル数 10 では、頻度が増えているのか減っているのかを統計的に評価することはできません。ここで言えるのは「この 14 日間はこう出た」までです。

時間帯別の分布

深夜帯 (0-4 時) に 6 回、昼 (11 時台) に 2 回、夜 (21 時台) に 2 回。「毎日決まった時間に落ちる」というパターンは出ていません。 たとえば「毎朝 9 時に DHCP リース更新で落ちる」のような規則性は見えませんでした。

なお この表の時刻は query_range のバケット時刻であって、遷移が起きた実時刻ではありません。changes(v[1h]) の値はバケット時刻の直前 1 時間を見ているので、実時刻は最大 1 時間手前にずれます。たとえば 05-11 分の 03:00台/04:00台 は、実際には 02:34 と 03:12 の遷移でした。

同じずれを他の行にも当てはめると、この表と次の曜日別の表は 1 時間・場合によっては日付をまたいで動きます。 たとえば 05-07 00:10 バケットの 2 遷移は 05-06 23:10〜05-07 00:10 のどこかで起きたもので、水曜の 23 時台だった可能性があります。実時刻を押さえてあるのは state-timeline から読めた 05-11 の 1 件だけなので、**この 2 つの表は「1 時間の精度で時間帯や曜日を語れる資料ではない」**と読んでください。

曜日別の分布

平日寄りには見えるものの、サンプル数 10 (サイクルで数えれば 5) で曜日相関を語るのは無理があります。土日にたまたま発生しなかっただけ、と考える方が自然です。上の脚注のとおり、バケット時刻のずれで日付をまたぐ行があり得る点も含めて、この表は参考程度です。

個別イベント

遷移数の合計は 10、「落ちて戻った」サイクルに直すと 5 回です。遷移数が 2 の行は 1 回のダウンが 1 バケットに収まったもの、1 の行は 1 回のダウンが 2 バケットに割れたもの、という読み方になります。

05-07 の 00:10 と 01:10 は連続しています。それぞれが完結した 1 サイクルなので、一度落ちて戻った後、1 時間以内にもう一度落ちたことになります。

05-11 の 03:10 と 04:10 は、これとは別の見え方をしています。 上の state-timeline が示すとおり、実体は 02:34-03:12 の 38 分ダウンが 1 回。changes() は up→down→up を「変化 2 回」と数えるので、1 回のダウンの down 側 (02:34) と up 側 (03:12) が隣接する 1 時間バケットに割れて「1 と 1」に見えています。2 回落ちたわけではありません。

そして 04-27 から 05-04 までの 7 日間、05-08 から 05-10 までの 3 日間は flap 数 0 でした。

この集計と lost carrier が合っていないこと

ここは正直に書いておきます。ルータの lost carrier は 19 日間で +17 (約 0.89 回/日) なのに、SNMP で捕捉できたダウンは 14 日間で 5 サイクル (約 0.36 回/日) しかありません。 同じ「物理リンクが落ちた」現象を数えているはずなのに、2〜3 倍ずれています。

しかも 2 つの窓は入れ子になっていません。カウンタを読んだのは 04-22 00:00 と 05-11 00:00 で、SNMP の集計窓は 04-27 00:00 〜 05-11 12:00。05-11 02:34 のダウンはカウンタ側の窓の外ですし、04-22〜04-27 の 5 日間は SNMP 側の窓の外です。この 5 日間に落ちた分は lost carrier にだけ乗っています。

それを差し引いても差は残ります。考えられるのは、(1) 30 秒スクレイプで拾えない短い瞬断が lost carrier を増やしている、(2) lost carrier は 1 回のリンクダウンで複数回加算されることがある、のどちらか (または両方) です。どちらかを実測で決められていないので、この記事の「14 日間で 10 回」は「SNMP の解像度で見えた分」であって、物理層で起きた回数の下限だと思ってください。

このデータが何を示しているか

ここが記事の山場です。素直に読み解くと、次のような解釈ができます。

1. 規則性は出てこなかった

毎日定刻に発生するわけでも、特定曜日に集中するわけでもありません。サンプル数が少ないので「無い」と断言はできませんが、少なくとも 14 日間の観測では、ソフトウェア要因 (cron, スケジューラ, ISP 側の定期処理) を示唆するパターンは見えませんでした。

2. クラスタ性 (連続発生) らしき挙動が一度あった

一度落ちると 1 時間以内にもう一度落ちることがあり、そのあと数日安定する、という挙動です。これは温度変化や、家族が回線まわりを通った時の物理的な揺れなど、外乱に対して接点が一時的に不安定になるシナリオと整合します。

ただし、14 日間でこれがはっきり出たのは 05-07 の 1 例だけです (05-11 は前述のとおり単一のダウン)。1 例で「クラスタ性がある」と言うのは強すぎます。「そう見える挙動が一度あった」までが、このデータで言える範囲です。

3. ランダム性自体が手がかり

「パターンが出ない」ことを失敗と捉えがちですが、今回の文脈では違います。マンション設備の JJ コネクタによる接触不良という仮説に対しては、ランダムに発生し、規則的なトリガーが見えないというのはむしろ整合的です (クラスタ性は 1 例なので、ここでは証拠に数えません)。機械的な要因に依存する接触不良は、再現性が低く、温度・振動・経年変化に左右されます。

ただし、これは論理的には「ランダム性 = 接触不良の証明」ではありません。他の要因 (例: ISP 側のメンテナンスがランダムなタイミングで入る、対向 ONU のファームウェアの問題、宅内配線の途中にある別の接続ボックスでの不調) の可能性は残っています。「JJ 仮説と矛盾しない」という以上のことは、今のデータからは言えません。

次のアクション: 物理層に触れる

データはここまでで、ここからは物理側です。マンション設備の JJ そのものに触ることはできないので、自分の手の届く範囲で接点の品質を上げることにします。

記事公開時点 (2026-05-11) では、これから実施するアクションです。

1. WAN ケーブルを Cat6A 短尺ストレートに新調

既存の WAN ケーブルはカテゴリ表記が読めなくなっており、Cat5e か Cat6 か判別不能です。長さも取り回しの都合で曲げ癖がついており、見た目の劣化が目立っています。

これを Cat6A の 1m〜1.5m シールド付きスリムケーブルに交換します。長さを最小限にすることで、不要な引き回しでのストレスを減らせます。Cat6A まで上げるのは過剰スペックではあるのですが、ホームラボの常用ケーブルを一段格上げするついでに、という位置付けです。

期待する効果は、ケーブル本体の経年劣化や物理ストレスによる接点不良を排除することです。WAN ケーブル交換だけで治るなら、JJ よりこっちが原因だったということになります。

2. RJ45 コネクタの接点清掃

ONU 側、ルーター側ともに RJ45 のジャック内側の金属ピンを清掃します。

• 無水エタノールを綿棒に少量
• 接点復活剤 (タミヤ製 or サンハヤトなどの電子部品用) を、塗布後に余剰を拭き取る
• エアダスターで内部のホコリと水分を完全に飛ばす

期待する効果は、酸化皮膜や微細な異物による接触抵抗の増大を解消することです。家庭内のジャックは常時通電しているとはいえ、長期間使うと特に金メッキ層の薄い安物コネクタでは酸化が進みます。

3. 今回はやらないこと (制約)

• JJ コネクタの撤去: マンション設備側に手を入れることになるので不可
• 対向 ONU 側のジャック交換: 同上
• ケーブルテスター (Fluke MicroScanner² 等) での導通テスト: 機材コストが高く、今回は手持ちのケーブルを総入れ替えする方が早い。次の機会の検討課題

JJ そのものが原因なら、自分側のケーブル交換と接点清掃では治らないはずです。治らなかった場合は、マンション側の管理組合や設備業者に対する交渉材料として、今回のデータがそのまま使えます。「19 日間でルータの lost carrier が 17 回増えている。SNMP でも 14 日間に 5 回、リンクが落ちて戻ったのを捕まえている」というデータは、設備側に動いてもらう根拠としては悪くないはずです。交渉に持っていくなら、SNMP の集計値より show interfaces の lost carrier の方が話が早いと思います。カウンタが増えている事実は 1 コマンドで見せられるので。

続編予告

物理交換後の 2〜4 週間で再度 Prometheus データを取り、before / after の比較を続編記事で書く予定です。シナリオは三つ。

どのシナリオに転んでも、続編は書けます。続編記事のリンクは公開後にここに追記します。

教訓

最後に、ここまでの作業で得た汎用的な学びを 4 つにまとめておきます。

• lost carrier / CRC / giants は最初に見るべきトリオ。ただし標準の IF-MIB では取れない。IF-MIB にあるのは ifInErrors (CRC を含む合計) までで、CRC 単体・giants・lost carrier は Cisco 固有 MIB か show interfaces を叩かないと取れません。この記事の 19 日差分表も全部 show interfaces の手作業です。reliability 255/255 は嘘ではないが、低頻度の障害には鈍感
• snmp_exporter は walk だけでなく metrics: セクションも必須。書き忘れると scrape は通るのに値が出ない、という分かりにくい失敗をする。snmpwalk で直接 OID を叩いて切り分ける癖をつけると早い
• changes(metric[range]) は flap 検知のデファクト。for: 1m と組み合わせれば誤検知も減らせる。rate() ではなく changes() を使うのがコツ
• 規則性が出ないこと自体がデータ。「パターンが出なかった」と落ち込むのではなく、「ランダム性が観測されたという事実」として仮説の補強に使える。ただし、それで原因を断定はしないこと

監視を構築すると、いつも「データを集めれば原因が分かる」と期待してしまいます。実際にはデータは選択肢を絞ってくれるだけで、最後は物理に触りに行くしかない、ということを今回あらためて思い知りました。

続編で「治った / 治らなかった」を報告できるよう、まずはケーブルと接点清掃から始めます。

補助資料: PDF レポートとデータセット

本記事の集計データ・設定ファイル・PromQL クエリ一覧・観測運用の落とし穴を 19 ページの PDF レポートにまとめ、CSV データセットと併せて公開しています。CC BY 4.0 で出典明記の上、自由に複製・引用可です。

• 📄 家庭 WAN 安定性レポート 2026 (PDF, 19 ページ) — Cisco C1111 マンション備え付け回線を 14 日間 SNMP 観測した記録
• 📊 wan-stability-2026-dataset.csv — 累積カウンタ差分 + 個別 flap イベントの生データ

関連リンク

• ナレッジ DB: snmp-exporter if_mib モジュールで metrics: 欠落の罠 (d7459313-6895-4700-a151-faeff161acc6)
• ナレッジ DB: Cisco C1111-X の WAN ポート (Gi0/0/0) は TDR 非対応 (482c7daa-8366-45b8-b754-143c290cbf55)
• 過去記事: Raspberry Pi + LINE + Cisco AP で WiFi 自動チャンネル変更
• 過去記事: WiFi が不安定だった話 — Cisco AP / Nest Mini / Meraki の三つ巴

自宅サーバとネットワークの観測の全体像は 自宅 Observability の完全ガイド — Prometheus + Grafana + Loki で家のサーバとネットワークを観測し続ける にまとめています。監視基盤の設計判断から複合障害・retention 運用までを 1 ページで通読できる Pillar ガイドです。