ページ

2026年8月7日金曜日

メモリ99.8%の障害を調べたら、犯人が証拠に写っていなかった —— Zabbix + LLMの障害調査を実際にやってみた記録

深夜1時16分、Zabbixからメールが届きました。

朝、復旧を確認したうえで調査に入りました。結論から言うと、障害の直接原因は特定できませんでした。理由は、自分で作った証拠収集の仕組みに欠陥があり、肝心の犯人プロセスが記録に残っていなかったからです。

この記事は、その調査と対処、そして「原因が分からなかったこと」から得た考察の記録です。

Zabbix APIからメモリ使用率の履歴を引くと、状況は明快でした。

同時刻の状態はこうでした。

  • Load Average 248(CPU 20コアの機体)

  • CPU時間の87%がシステム時間(ユーザー処理は1.2%)

  • PSI(Pressure Stall Information)の memory full avg10 = 88.7%

  • スワップ 0

CPUが計算に使われていない。システム時間ばかり。これは典型的なスラッシングです。物理メモリが尽きたとき、Linuxはページキャッシュを捨てて凌ごうとしますが、スワップが無いと逃げ場がありません。

この記事は要約版です。続き(残りの話題・実装の詳細)は元記事でどうぞ:

メモリ99.8%の障害を調べたら、犯人が証拠に写っていなかった —— Zabbix + LLMの障害調査を実際にやってみた記録

スキャン書類の管理を自社サーバーで。OSS「Docspell」を日本語で使えるようにした話

「日本語対応あり」と書いてある OSS の翻訳率を測る話をこれまで3本書きました(Vikunja 91%、Docmost 100%、Planka 88%)。今回は逆で、 日本語が一切入っていない OSS を、ゼロから日本語にした 記録です。対象は、スキャンした書類・メール添付・P...