自宅サーバー（Orange Pi / Armbian）にて、外部監視サービスから「ダウン」判定を受け、SSH接続すら受け付けない状態に陥りました。強制再起動後のログ消失という悪条件の中、わずかに残った痕跡から原因を特定し、復旧に至るまでのプロセスを共有します。
結論から言うと、サーバーはダウン（電源断・カーネルパニック）していませんでした。「監視エージェント自体の設定不備によるリソース枯渇」が原因で、システムが窒息していた事例です。
1. インシデント概要
- 発生日時: 2025年12月1日 01:50頃 〜 09:50頃（約8時間）
- 対象システム: 自宅サーバー (Orange Pi 4 / Armbian)
- 現象: 外部監視（Better Stack）からのPing/HTTP監視がタイムアウト。SSH接続不可。Webサービス応答なし。
- 復旧方法: 物理的な電源切断による強制再起動
2. 発生した事象のタイムライン
事後調査により判明した時系列は以下の通りです。
| 時刻 | 事象 | システム内部の状態（推定含む） |
|---|---|---|
| 22:00頃 | 予兆開始 | 監視エージェント(vector)が外部へのデータ送信に失敗し始める（HTTP 401 Unauthorized）。メモリ上に再送用バッファが蓄積され始める。 |
| 00:00 | 負荷上昇 | Armbianの定時処理（log2ram）が発動。vectorが吐き出した大量のエラーログをSDカードへ同期しようとし、一時的にI/O負荷が高まる。 |
| 00:00 - 01:50 | リソース枯渇進行 |
vectorがメモリを食い潰し続け、同時に秒間数百行の勢いでエラーログを出力。物理メモリの空き領域が枯渇していく。 |
| 01:50 | サービス停止（死亡） | 物理メモリ枯渇。 OSがスワップ（SDカードへの退避）を開始するも、書き込み速度が追いつかずI/O Waitが100%に張り付く。システム全体がフリーズ。 |
| 01:50 - 09:xx | ゾンビ状態 | 外部監視からは「ダウン」判定。しかしOSは生存しており、極低速でスワップ処理とエラー再試行を繰り返していた（SSHのハンドシェイクすらタイムアウトする状態）。 |
| 09:xx | 強制復旧 | 管理者による電源切断・再起動。 |
3. 原因調査：なぜログが消えていたのか？
復旧後、直ちに原因究明を行いましたが、Armbian特有の仕様が壁となりました。
3.1 ログ消失の罠
ArmbianなどのSBC（シングルボードコンピュータ）向けOSでは、SDカードの延命措置として log2ram が採用されています。これはログをRAM上に保持し、定期的またはシャットダウン時にディスクへ同期する仕組みです。
今回は「電源ブチ切り」による強制再起動だったため、フリーズ直前（01:50周辺）のメモリ上のログはディスクに同期されず、すべて消失していました。
journalctl -b -1（前回のブートログ確認）を実行しても、有用なデータは得られませんでした。
3.2 残された痕跡からの特定
しかし、完全に証拠が消えたわけではありませんでした。/var/log.hdd/（ディスク上の永続化領域）を確認したところ、決定的な証拠が見つかりました。
-
巨大化したsyslog
通常数MB程度のsyslog.1（前日分）が、23MB に肥大化していました。 -
ログ内容の偏り
中身を確認すると、監視エージェントvectorによる以下のエラーが数十万行にわたり記録されていました。[ERROR] sink... reason="Http status: 401 Unauthorized" [ERROR] source... Failed to load partitions info... Permission denied -
死亡時刻の一致
外部監視サービスのダウン検知時刻（01:50）と、ログの書き込み状況、およびシステムのメモリリソース推移（推測）が合致しました。
4. 技術的考察
なぜ「監視ツール」がサーバーを殺したのか？
監視エージェント（Vector）は、送信に失敗したデータを「捨てずに再送する」ためにメモリバッファに保持します。今回はAPIキーの無効化（401エラー）により、**「永遠に送信できないデータ」を「無限にメモリに溜め込み続ける」**挙動となりました。
さらに、エラーログの大量出力がディスクI/Oを占有しました。SDカードのような低速なストレージにおいて、「スワッピング（メモリ退避）」と「大量ログ書き込み」が同時に発生すると、システムは事実上の操作不能（デスロックに近い状態）に陥ります。
これが、Ping応答すら返さなくなった「ゾンビ状態」の正体でした。
5. 再発防止策
今回の障害を受け、以下の対策を実施しました。
-
監視エージェントの修正（即時）
-
vectorサービスの停止およびAPIキーの再設定。 - 権限エラーが出ていた収集項目（
filesystems等）の無効化。
-
-
リソース制限の導入
-
systemdのUnitファイルにMemoryLimitなどを設定し、監視ツールが暴走してもOSごと道連れにしないよう制限を設ける。
-
-
「死に際のログ」を残す設定へ変更
- メトリクス収集ツール（Netdata）の設定を、デフォルトの「メモリモード」から「DBEngineモード（ディスク保存）」に変更。
- これにより、次回同様のフリーズが発生しても、直前までのCPU/メモリ使用率の推移が確認できるようにした。
6. まとめ
「サーバーを監視するためのツール」が、設定ミス一つで「サーバーをダウンさせる攻撃者（DoS）」に変貌するという、皮肉かつ典型的な事例でした。
特にSDカード運用等のリソースが限られた環境では、「監視ツール自体のリソース消費」もまた、監視・制限の対象にすべきであることを痛感しました。