Zabbixログ監視の「聖域」：CPUを殺さず、エラーを逃さないための極限チューニング術
ログ監視は、運用という泥沼の中で最も「負債」になりやすい領域だ。何も考えずに `log[/var/log/app.log, “ERROR”]` などと書いていないだろうか？
その設定は、トラフィックが急増した瞬間にZabbixエージェントをCPUの熱源に変え、監視サーバのデータベースをゴミデータで埋め尽くす「時限爆弾」だ。本稿では、伝説的なオブザーバビリティを構築するための、Zabbixログ監視の深淵に踏み込む。
—
1. 正規表現の「再帰的罠」を回避せよ
Zabbixのログ監視でCPUが跳ね上がる最大の原因は、「不適切な正規表現によるバックトラッキング（後戻り）」だ。
悪い例
`.ERROR.Exception.`
これを使うと、エンジンは文字列の最後まで走査し、見つからなければ手前に戻って再走査を繰り返す。
プロの解法：プレフィルタリングとアンカー
正規表現は「コンパイル時に確定する」のが鉄則だ。
- アンカーを活用する: `^` や `$` を使い、先頭からマッチを試みる。
- 否定先読みの回避: 複雑な条件は、ログ出力側で構造化（JSON化）し、Zabbix側では単純なキーワードマッチに留めるのが究極の最適化だ。
最適化された正規表現の例:
汎用的なエラーを拾うなら、あえて複雑なRegexを使わず
「ERROR」という固定文字列を先に通し、詳細をスクリプト側でパースする
^\[\d{4}-\d{2}-\d{2}.\] ERROR.
—
2. マルチラインログの「死の行軍」を防ぐ
複数行にまたがるスタックトレースを監視する際、正規表現で一行ずつ結合処理をしていると、エージェントは過負荷で死ぬ。
実践的ベストプラクティス：エージェントサイドでの前処理
ログファイルを直接追わせる前に、`logrt.count` と `log` の使い分けを徹底せよ。
- `logrt` を使え: ローテーションされるログを監視する際は、必ず `logrt` を使用する。ファイルディスクリプタの浪費を防げる。
- 前処理（Preprocessing）の活用: Zabbix 4.x/5.x/6.x以降、アイテムの「前処理」が強化された。エージェント側で全部パースしようとせず、エージェントは「生ログ」を送り、サーバ側の前処理ステップで「正規表現置換」や「JSONPath抽出」を行う。これにより、エージェントのCPU使用率を劇的に下げられる。
—
3. 「神」設定：パフォーマンスを最大化する設定ファイル
チーム開発で運用を標準化するための設定テンプレートを提示する。
Zabbixエージェント設定 (zabbix_agentd.conf)
バッファの最適化：ログの読み込み負荷を平準化する
ログ送信のために確保するバッファサイズ（秒数単位）
BufferSend=5
バッファに保持する値の数（これを増やすとI/O負荷が平準化される）
BufferSize=500
タイムアウトの調整：監視対象が巨大なログを吐く場合
Timeout=10
アイテム設定のベストプラクティス（JSONパース構成）
ログをJSONで出力し、Zabbixで以下のように「前処理」を行うのが現在のデファクトスタンダードだ。
1. Preprocessing 1: 「正規表現」で `{“level”:”ERROR”,.}` にマッチするものだけ抽出。
2. Preprocessing 2: 「JSONPath」で `$.message` を抽出。
3. Preprocessing 3: 「値の変更」で重複を除去。
—
4. 現場で差がつく生産性向上テクニック
隠れたキーボードショートカット
- `G` (Shift+g): Zabbixのダッシュボードやグラフで、最新データまで一気にスクロールする。
- `/`: 監視一覧画面などでフィルタ検索窓へ即座にフォーカスする。
絶対入れるべき「神」ツール・プラグイン
- Zabbix API (Python/Go SDK): 手動でアイテムを作るのは今日でやめろ。`pyzabbix` を使い、`inventory.yaml` から監視設定を流し込むCI/CDパイプラインを構築せよ。
- `logtail`: Zabbixエージェントのログの「今どこを読んでいるか」を追いかけるために、自作の簡易スクリプトを `zabbix_agentd.d` 配下に置いておくこと。
—
5. チームで共有すべき「運用憲法」
監視設定を属人化させないためのルールだ。
1. 「監視の定義」はコードに落とせ: アイテム設定をエクスポートし、Gitで管理する。誰がいつ、なぜその正規表現を入れたのかの履歴を残せ。
2. 「ノイズの閾値」を明文化せよ: 「1分間に100回発生したら通知」などのレートリミットを必ず設定すること。さもなくば、障害時にメールが1万通届き、本当の異常が見えなくなる。
3. ディスク容量の節約: `log` アイテムの第4引数 `maxlines` を調整せよ。デフォルトのままだと、ログが溢れた瞬間に監視プロセスがI/Oを占有する。
—
最後に
監視とは「何を監視するか」を決めることではない。「何を無視するか」を決めることだ。
不要なログを捨て、必要なエラーのシグナルだけを正確に抽出する。その洗練された設計こそが、オブザーバビリティの神髄である。明日から、君の監視ツールから「無駄なCPU使用率」が消え去ることを期待している。