Zabbix×ローカルLLM×Bluditで「調査済みの障害メール」が届く監視を作る——AIエージェントで実際に対応した実録つき

サーバー監視の通知は、たいてい「何かが起きた」としか教えてくれません。当社（エクスブリッジ）では、OSSの定番 Zabbix にローカルLLMを組み合わせ、障害の瞬間の証拠を自動収集し、AIが調査レポートを書いた状態でメールが届く構成（社内呼称: Kurage Zabbix）を実運用しています。今朝この仕組みが実際に障害を拾い、AIエージェントとの会話だけで解決まで行けたので、構成と技術的なハマりどころを実録込みで書きます。

全体構成——部品はすべてOSS

Zabbix 7.0（検知）
  └─ 障害イベント発生
       ├─ 証拠スナップショット収集（systemd timerで毎分、/var/tmp に最新状態を保持）
       │    メモリ・プロセス上位・failed units・ログ末尾など
       ├─ ローカルLLM（Ollama / Gemma系12B）が証拠+Zabbix APIの履歴を読んで
       │    日本語の調査レポートを生成
       ├─ Bludit（軽量ブログOSS）の認証付き限定ブログにレポートを蓄積
       └─ メール通知（レポート本文つき）

ポイントは3つです。

証拠は「事前に」集め続ける。 障害通知を見てからサーバーに入っても、その瞬間のプロセス状況はもう消えています。毎分のスナップショットを軽く取り続け、障害イベント発生時にその時点の証拠を確保します
調査はローカルLLMに書かせる。 レポート生成はGemma系12Bで十分な品質が出ます。API費ゼロ・障害情報が社外に出ない・外部APIが落ちていても動く、の三拍子です。スナップショット収集側で password|token|api[_-]?key 等を正規表現でリダクトしてからLLMに渡します
記録はBluditの限定ブログへ。 過去障害が検索できる「障害ナレッジベース」が勝手に育ちます。Bluditは1インストールが軽く、認証を被せて管理者専用にしています

実録: 今朝の障害対応

今朝08:37、「High swap space usage (less than 50% free)」をZabbixが検知。届いたメールには既にAIレポートで「メモリ上位はLLM推論プロセス15GB/CPU 5.6%/iowait 0.01%」まで書かれていました。

ここからAIエージェント（Claude Code）に「レポート見て対応して」と依頼。エージェントはZabbix APIで現在値を取り直し、「RAMは58%空き・I/O待ちなし・スワップ使用は過去のメモリピークの残留で実害なし」と診断しました。スワップは一度追い出されるとRAMに余裕が戻っても居座るので、警告だけが鳴り続けるパターンです。

対応は3つ。①ホストマクロ {$SWAP.PFREE.MIN.WARN} を50→20に調整（大容量RAM機のAIワークロードでは残留スワップが正常なため）②swapoff -a && swapon -a で残留5GBをクリア ③ついでに発見した不要データ約130GBを、/proc/*/cwd の実測で稼働プロセスが参照していないことを確認してから削除。ディスク83%→70%になり、警告は全消灯しました。

人間がやったのは「sudoパスワードを渡す」「削除対象を選ぶ」の2判断だけです。この一部始終の読み物版はnoteに公開しています。

技術的なハマりどころ3つ

1. SSHヒアドキュメントでZabbixマクロ名が壊れる。 ホストマクロをAPIで設定する際、ssh host 'python3 <<PY ... {$SWAP.PFREE.MIN.WARN} ... PY' のように送ると、リモートシェルが $SWAP を環境変数として展開し、マクロ名が {.PFREE.MIN.WARN} になって Invalid parameter で落ちます。対処はスクリプトを base64で運んで base64 -d | python3 - で実行すること。クォート地獄から一発で抜けられます。

2. pgrep -f は自分自身にマッチする。 削除前の「使用中チェック」を pgrep -f ディレクトリ名 でやると、そのチェックを実行しているシェル自身のコマンドライン文字列にマッチして全件SKIPします。正しくは /proc/[0-9]*/cwd と exe のシンボリックリンクを読んで実測することです。この実測のおかげで、消そうとしていた1つが実は学習ジョブの稼働中ディレクトリだと分かり、事故を防げました。

3. 誤報設計こそ監視の本体。 テンプレ既定のしきい値のまま運用すると「無害な警告」が鳴り続け、監視は必ず無視されるようになります。今回のスワップ50%警告はまさにそれで、ホスト実態に合わせたマクロ調整（本当に逼迫する20%だけ鳴らす）が正解でした。Zabbixのホストマクロはテンプレを汚さずホスト単位で上書きできるので、この用途に最適です。

この構成の再現に必要なもの

Zabbix 7.0（無料・パッケージあり）＋各サーバーへのagent導入
Ollama＋日本語が書ける12Bクラスのモデル（GPU 1枚で足ります）
Bludit（PHPが動けばどこでも）＋認証
接着コード（イベント取得→証拠収集→LLM→投稿→メール）——ここがAIエージェント開発（バイブコーディング）の出番で、当社はこの接着部分を含めて数日で構築しました

費用相場（監視SaaS: 1台月2,000〜5,000円×台数が永続、SIer構築: 数百万円）との比較や、非エンジニア向けの構築サービス（買い切り110,000円税込〜）の話は、解説ページにまとめています。

まとめ

Zabbix＋ローカルLLM＋Bluditで「調査済みの障害メール」が届く監視が、全部OSSで作れる
証拠は事前に集め続ける・調査はローカルLLM・記録は限定ブログ、の3点セット
運用の質を決めるのは検知ではなく誤報設計（ホストマクロで実態に合わせる）
対応もAIエージェントに任せられる時代。人間の仕事は「破壊的操作の承認」だけに寄せていく

更新履歴: 2026-08-16 初版公開