はじめに
自宅のONUが故障した日、地下で動かしている地震観測用センサー（Raspberry Shake）のデータにも異常が出ていました。
ONUの故障は業者の点検でACアダプタの劣化と確定し、当日交換して復旧しました。
Raspberry Shake側もたどっていくとACアダプタの劣化に行き着きましたが、こちらはまだアダプタを交換できておらず、診断は確定していません。
この記事は、Raspberry Shakeから届くデータの遅延を、アプリケーションのログだけでは特定できず、最終的にdmesgのUnder-voltage警告にたどり着くまでの調査記録です。ネットワークの不調を切り分ける手順として、Recv-Qの監視、NTPオフセットの確認、UDPドロップ統計の差分測定、dmesgによるアンダーボルテージ検出まで、実際に使ったコマンドをそのまま載せています。
対象読者は、Raspberry Piなどの常時稼働機器で「ネットワークが原因に見えるけれど、切り分けてもよくわからない」不調に遭遇している方です。
実行環境
- センサー側: Raspberry Shake 4D（ベース機種はRaspberry Pi 3 Model B）。OSはRaspbian GNU/Linux 10 (buster)、カーネル4.14.79
- 受信サーバー側: macOS 12.7.6（
launchctl・netstat・topなどmacOS固有のコマンドを使用） - 通信方式: センサーからUDPで直接データを送信する方式（DATACAST）
TL;DR
- ONUが故障し、業者に確認してもらったところ電源アダプタの劣化が原因でした。本体は2007年製で設置から19年、アダプタは一度も交換していませんでした
- ONU復旧後にサーバー群を再起動した際、Raspberry Shakeの異常に気づき調査しました。受信側の負荷・NTPのずれ・UDPキューの詰まりなど順番に疑いましたが、どれも潔白でした
- 最終的に、
dmesgでRaspberry Pi本体のアンダーボルテージ（電源電圧不足）警告を発見しました。ただしアダプタ交換と復旧確認はまだできていません - ネットワークの不調に見えて、原因は電源にありそうだった、という話です
ONUの故障: 2007年製の機器が、まだ現役だった理由
2026年8月8日20:14、インターネットに繋がらなくなりました。
プロバイダの業者に連絡して見てもらったところ、原因はONU本体ではなく、電源アダプタの劣化でした。翌9日17:48、その場でアダプタを交換してもらい、復旧を確認しました。
このONUは2007年製です。
設置から19年、一度もアダプタを交換していません。
今回のような異常は、たいていアダプタの交換で直るのだと業者は説明してくれました。
意外だったのは、そのあとの一言です。
最近新しく設置しているタイプのONUは、むしろ故障しやすいそうです。
壊れたら本体ごと交換になり、ファイバーの心線を新しい機器に付け替える工事が発生します。
業者にとっても、それは手間のかかる作業だとのことでした。
2007年という年号を聞くと、古い機器だから調子が悪いのだろう、と考えるのが自然な反応です。
実際、そう思って連絡しました。
しかし結果は逆でした。
壊れていたのは本体ではなく、外付けの電源だけ。
本体は19年前の機器のまま、今も現役で動いています。
Raspberry Shakeの調査: パケット遅延の犯人探し
ONUのアダプタを交換してネットが復旧したあと、自宅の各サーバーを順番に再起動していました。
その再起動のさなか、地下に設置してあるRaspberry Shake（地震観測用の小型センサー、以下RS4D）のLTA/STA（地震波の振幅変化を検出するアルゴリズム）推移グラフとリアルタイム表示に異常があることに気づきました。
調べてみると、RS4Dから届くデータの遅延が、以前と比べて明らかに悪化していました。
RS4Dは、地震波の振動をUDPパケットでリアルタイムに自宅サーバーへ送り続けています。
あとからログを見返すと、ネットワーク途絶（8月8日20:14）までパケットに異常はなく、ネットワーク復旧（8月9日17:48）後から異常が多発していました。
ONUのアダプタ劣化そのものはRS4Dのパケット送信経路とは無関係のはずですが、時系列としてはこの復旧が異常の顕在化と重なっています。
受信側の疑いを晴らす
ネットワークの不調を調べるとき、まず疑うのは受信側です。
サーバーの負荷、UDPの受信キューの詰まり、プロセス側の取りこぼし。
順番に確認しました。
受信サーバーはmacOSで動いているため、以下のコマンドはmacOS固有のものです。
まず、サーバー自体の時刻同期を疑い、NTPのオフセットを確認しました。
sntp time.apple.com
オフセットはミリ秒単位で、サーバー側の時計ズレはラグの原因にならない水準でした。
次に、UDPの受信キュー（Recv-Q）をポート単位で繰り返し監視しました。
for i in $(seq 1 15); do netstat -an -p udp | grep '\.8888'; sleep 1; done
15回連続でRecv-Qは0でした。
カーネルレベルでの滞留はありません。
受信プロセスのCPU使用率も見ました。
top -l 1 -n 10 -o cpu
受信プロセスは0.1%程度で、負荷がボトルネックになっている様子はありませんでした。
最後に、受信プロセスそのものを再起動して切り分けました。
launchctl kickstart -k gui/501/com.riverruns.earthquake-web
再起動直後から、パケット遅延（受信時刻とパケット内タイムスタンプの差分。以下同様）が0.6秒〜14.3秒の間で乱高下しました。
プロセスを作り直しても直後から異常値が出るということは、原因は受信プロセス側に溜め込まれた内部状態ではありません。
ここまでで、受信側の疑いはほぼ晴れました。
原因はRS4D本体、つまり送信側にあります。
クロックドリフトを疑う
次に着目したのは、ログに残る奇妙な数値でした。
パケット遅延の推移を並べると、ときどきマイナスの値が混じっていました。
パケットの時刻のほうが、受信した時刻より未来になっているということです。
これは、RS4D本体の内部時計が周期的にずれ、NTPによる再同期でジャンプして戻る、いわゆるクロックドリフトのパターンに見えました。
RS4D本体が返すHTTPレスポンスのタイムスタンプをサーバー側の時刻と突き合わせて裏を取ろうとしましたが、少なくともその経路では明確な時刻のずれは確認できませんでした。
仮説として筋は通っていたのに、証拠が積み上がりません。
監視ソフトの収集タイミングを疑う
行き詰まって、パケット遅延が悪化するタイミングの周期性に着目しました。
だいたい50秒から60秒おきに悪化しているように見えます。
同じサーバー上では、システム監視用のソフト（Telegraf）が動いていました。
メトリクス収集のタイミングでシステムが一瞬ブロッキングし、その間に受信処理が遅延しているのではないか、という仮説です。
設定ファイルを確認しました。
cat /opt/homebrew/etc/telegraf.conf | grep -A3 '\[agent\]'
[agent]セクションのintervalは10秒に設定されていました。
60秒という周期とは一致しません。
プラグインごとに間隔を上書きできる余地は残りましたが、この仮説も決め手を欠いたまま宙に浮きました。
さらに、UDPのドロップ数を計測し、3分待って同じコマンドをもう一度実行して差分を見ました。
netstat -s -p udp | grep -iE 'dropped|full socket|no socket|bad'
3分間でno socketドロップは579→579で変化なしでした。
カーネルレベルでの取りこぼしは増えていません。
ICMP（ping）も長時間流しましたが、400パケット送信して欠落は0件でした。
受信側でパケットを捨てているのでも、リンク層の問題でもありません。
パケットは、そもそも送信側から届いていなかったことになります。
dmesgに答えがあった
最後に、RS4D本体（Raspberry Pi）に直接ログインしてdmesg（カーネルが記録するシステムログ）を確認しました。
dmesg | grep -E 'Under-voltage|Voltage normalised|overrun'
[ 4.150866] Under-voltage detected! (0x00050005)
[ 14.550810] Voltage normalised (0x00000000)
[ 16.630863] Under-voltage detected! (0x00050005)
[ 20.790822] Voltage normalised (0x00000000)
[ 27.029179] Under-voltage detected! (0x00050005)
[ 56.145844] Voltage normalised (0x00000000)
[ 332.787311] Under-voltage detected! (0x00050005)
[ 339.027258] Voltage normalised (0x00000000)
[ 353.587403] Under-voltage detected! (0x00050005)
[ 357.747299] Voltage normalised (0x00000000)
[ 476.307748] Under-voltage detected! (0x00050005)
[ 476.309849] ttyS ttyS0: 1 input overrun(s)
[ 484.627638] Voltage normalised (0x00000000)
電源電圧の不足を示す警告が、起動から484秒（8分強）の間に6回、正常化のログとペアで記録されていました。
起動直後の数十秒（4〜27秒経過時点の3回）は電源投入時の過渡的な変動としてありがちですが、稼働が安定したあとの332秒・353秒・476秒経過時点でも同じ警告が出ています。
しかも最後の476秒の警告は、シリアルポートの入力オーバーラン（ttyS ttyS0: 1 input overrun(s)）と同じタイムスタンプで発生していました。
センサーからのデータを受け取っている最中に、電圧低下でデータを取りこぼした瞬間です。
Raspberry Piには電源状態を確認できるvcgencmdコマンドもありますが、RS4Dの環境ではcommand not foundで使えませんでした。
代わりに/sys以下を直接読みました。
cat /sys/devices/platform/soc/soc:firmware/get_throttled
0
このときの値は0（スロットリングなし）でした。
数分前に起きた電圧低下の後、値がクリアされていたのか、そもそも読み取り方が違うのか、この場では切り分けられていません。
結局、この調査で頼りになったのはタイムスタンプ付きのdmesgのほうでした。
念のため、USB接続機器も確認しました。
lsusb
RS4D（Raspberry Pi 3 Model B）は、USB-EthernetアダプタでLANに有線接続しつつ、Wi-Fiモジュールも有効になっていました。
本体の定格は5.1V/2.5A程度で、センサーボードとEthernetアダプタとWi-Fiモジュールの消費電流を合算すると、電源やケーブルの品質次第では追いつかなくなる負荷構成です。
クロックドリフトでも、監視ソフトの負荷でもありませんでした。
電源が足りていなかった可能性が高いです。
RS4Dのアダプタは数年前に一度交換していましたが、その交換品が今回また寿命を迎えていたと見ています。
ただし、この記事の執筆時点でRS4Dのアダプタはまだ交換していません。
電源の劣化は連続的に進むというより、ある時点から急に症状が出始めるものなのかもしれません。
先述のdmesgは、調査中にRS4D本体を再起動した直後、起動から8分ほどの時点で確認したものでした。
同じ起動のまま5時間19分が経過した時点で改めてdmesgを見ると、Under-voltage警告は141件まで積み上がっていました。
1時間あたりの発生頻度は最初に確認したときとほぼ変わらず、アダプタを交換していない以上、症状は収まっていません。
アダプタを交換して警告が本当に消えるかどうかは、これから確かめます。
ONUと違って、RS4D側の診断はまだ確定していません。
念のため、自宅の気象観測データとも突き合わせてみました。
湿度90%以上を記録した時間帯は、8月4日〜6日はゼロだったのに対し、8月7日は約12時間、8月8日は約7.5時間と、この数日で急に増えていました。
ネット復旧直後の8月9日17:50時点の屋外湿度は77%でしたが、その晩のうちに連続的に上昇し、23:40には96%に達しています。
90%を超えたのは22:40以降で、復旧直後の時点ではまだ低い値でした。
気温のほうは、平均が最も高かったのは8月2日（30.0℃）で、この時期にはデータ抜けは出ていません。
RS4Dは地下に設置していて完全な密閉空間ではないため、屋外の湿度上昇がある程度波及していてもおかしくないとは考えましたが、復旧直後の異常発生時点ではまだ湿度は低く、湿度上昇が直接の引き金だったとは言い切れません。
その晩のうちに湿度が上がり続けたことが、症状の悪化を後押しした可能性は否定できませんが、それを裏付ける実測値はありません。
一方の復旧が、もう一方の異常を見つけるきっかけになった
整理すると、こういう順番になります。
| 日時（2026年） | 出来事 |
|---|---|
| 8月8日 20:14 | ONUのACアダプタ劣化によりインターネット不通に |
| 8月9日 17:48 | 業者がONUのACアダプタを交換、ネット復旧 |
| 8月9日 18時前 | 復旧後、自宅の各サーバーを順番に再起動。この中でRS4Dの異常に気づく |
| 8月9日 18時前後 | 受信側の切り分け、クロックドリフト仮説、Telegraf仮説を順に検証 |
| 8月9日 18:43頃 | 状態をリセットするためRS4D本体を再起動 |
| 8月9日 18:51頃 | 再起動後のdmesgを確認（起動から8分、Under-voltage 6件） |
| 8月10日 0:02頃 | 同じ起動のまま改めてdmesgを確認（起動から5時間19分、Under-voltage 141件） |
| 8月10日（本記事執筆時点） | RS4Dのアダプタは未交換。明るくなったら交換予定 |
あの一斉再起動がなければ、RS4Dの異常発見も、もう少し先になっていたかもしれません。
二つの機器はメーカーも違いますし、経過年数もまるで違います。
ONUのアダプタは19年間無交換、RS4Dのアダプタは数年前に一度交換した後の再劣化です。
設置環境も違います。
ONUがある1階はエアコンで温湿度が管理されていますが、RS4Dのある地下は空気抜きから外気の影響を直接受けます。
気象データとの照合では、両者を結びつける決め手は見つかりませんでした。
2つの独立した部品が、たまたま近い時期に別々に寿命を迎えた、というのが今のところの見立てです。
それでも、その日のうちに「電源が原因でした」という答えが二回続くと、さすがに苦笑いしてしまいます。
まとめ
ネットワークの不調は、アプリケーションのログだけを追いかけても見つからないことがあります。
今回は、受信側のキューやプロセスを疑い、クロックのずれや監視ソフトの負荷まで疑いました。
それでも原因が見えないとき、次に見るべきは電源かもしれません。
RS4Dの場合、答えはアプリケーションの外、dmesgのUnder-voltage警告の中にありました。
Raspberry Piでネットワークやセンサーの挙動がおかしいときは、アプリケーションログを漁る前に一度dmesgを見る価値があります。
観測システムのように24時間動き続ける機器を地下や屋外に置いている場合、電源の状態そのものをログに残しておく価値は大きいです。
パケット遅延という症状だけを追いかけていたら、原因にたどり着くまでにもっと時間がかかっていたはずです。
ACアダプタは、本体より先に寿命を迎える消耗品です。
今回のONUのように十年単位で無交換のまま使えることもあれば、RS4Dのように数年で再び怪しくなることもあります。
長期間動かし続ける機器があるなら、ACアダプタは壊れる前提で、数年おきに予防的に交換しておくのがおすすめです。
参考文献
-
Raspberry Pi Documentation: get_throttled -
vcgencmd get_throttledが返すビットパターンと、アンダーボルテージ検出の意味