【テクニカル・上級編】Zabbixのタイムアウト・輻輳トラブルの根本原因調査：内部プロセッサー（Poller/Trapper/Httpoller）の枯渇を防ぐプロセス配分の科学 – 運用監視・オブザーバビリティ活用バイブル

Zabbixの限界を突破せよ：内部プロセッサーの解剖と「枯渇・輻輳」を根絶するプロセス配分の科学

არ-squad（アーキテクト集団）の皆さん、目を覚ましてほしい。
深夜3時、突如として鳴り響く「Zabbix internal queue is too high」のアラート。ダッシュボードを開けば、グラフは軒並み欠損し、ビジープロセッサー率は100%に張り付いている。パニックに陥り、思考停止で `StartPollers` を適当に倍増させ、挙句の果てにデータベースのコネクション枯渇を踏み抜く――。

この悪夢のようなシーンを、あなたは何回繰り返してきただろうか？

Zabbixは「枯れたオープンソースの監視ツール」などではない。数万台のホスト、数百万のメトリクスをさばく現代の超高負荷なオブザーバビリティ基盤において、その内部アーキテクチャを完全に理解していなければ、Zabbixサーバー自身が最大の障害発生源（Single Point of Failure）と化す。

今回は、Zabbixの心臓部である内部プロセッサーの挙動を低レイヤから解剖し、輻輳と枯渇を物理的に根絶するための「プロセス配分の科学」を伝授する。

—

1. Zabbixサーバー内部の解剖：なぜプロセッサーは枯渇するのか

Zabbixサーバーは、単一のモノリシックなプロセスではない。C言語で書かれたマルチプロセス・マルチスレッドの協調動作システムであり、各タスクが専用のプロセッサー（ワーカープール）に分かれて処理を行う。

プロセッサーの枯渇メカニズムを理解するためには、まず主要なアクターたちの「生態」を知る必要がある。

[Target Hosts] ──(Pull)──> [ Pollers / HTTP Pollers ] ──┐
[Zabbix Sender] ──(Push)─> [ Trappers ] ──────────────┼─> [ Preprocessors ] ──> [ History Cache ] ──> [ DB Writer ]
[Active Agents] ──(Push)─> [ Trappers ] ──────────────┘

主要プロセッサーの役割とボトルネックの兆候

1. `StartPollers` (Poller):

  • 役割: パッシブチェック（SNMP, Zabbix Agentパッシブ, IPMI等）を定期的に「ポーリング」しに行く。
  • ボトルネックのメカニズム: ネットワークの遅延やターゲット機器の応答遅延（タイムアウト）が発生すると、そのPollerプロセスはブロックされる。デフォルトのタイムアウト（`Timeout=3`秒など）の間、そのプロセスは完全に死活停止し、処理キューが雪だるま式に蓄積する。

2. `StartPollersAsync` (Asynchronous Poller):

  • 役割: `libevent`ベースの非同期I/Oを用いたポーリング。
  • ボトルネックのメカニズム: 大量のSNMP/Agentパッシブ監視を行う場合、同期型Pollerを数千に増やすとメモリ（スタック領域）が爆発するため、非同期Pollerへの移行が近代Zabbixスケーリングの必須条件となる。

3. `StartTrappers` (Trapper):

  • 役割: アクティブチェックのデータ受信、Zabbix Senderからのデータ受領、内部コマンドやフロントエンド（API）からのリクエスト処理。
  • ボトルネックのメカニズム: トラッパーが枯渇すると、エージェント側からのデータ送信がブロックされ、「No active checks got from server」が頻発する。また、Zabbix APIのレスポンスが極端に悪化する原因の9割はTrapperの枯渇にある。

4. `StartHTTPPollers` (HTTP Poller):

  • 役割: Webシナリオ（Web監視）の実行。内部でlibcurlを使用。
  • ボトルネックのメカニズム: 対象のWebサーバーが重い場合、HTTP Pollerが即座に詰まる。APIエンドポイントの死活監視などで多用すると、真っ先に枯渇する。

5. `StartPreprocessors` (Preprocessor):

  • 役割: 受信したメトリクスの前処理（JavaScriptによるカスタム変換、正規表現、デルタ計算など）。
  • ボトルネックのメカニズム: 現代のZabbixパフォーマンスチューニングの最難所。 複雑なJavasScript前処理を大量に走らせると、プリプロセッサーキュー（Preprocessing queue）が溢れ、全メトリクスの遅延を引き起こす。

—

2. プロセス配分の科学：経験則を捨て去り、数学的限界値に挑む

「とりあえず `StartPollers=100` にしておけ」――このようなエンジニアリングは今日で終わりにしよう。プロセスやスレッドの数は、ハードウェアリソース（CPUコア数、メモリ）と監視対象の特性から算術的に導き出すべきだ。

最適プロセス数算定のための方程式

① `StartPollers` (同期型) の必要数計算

$$\text{StartPollers} = \frac{\text{総パッシブアイテム数} \times \text{平均処理時間 (秒)}}{\text{ポーリング間隔 (秒)}}$$

  • 例: パッシブアイテムが 10,000個、平均応答時間が 0.5秒、ポーリング間隔が 60秒の場合：

$$\frac{10000 \times 0.5}{60} = 83.3 \rightarrow \text{最低 84 プロセス}$$
※ただし、ネットワーク遅延のスパイクを考慮し、この値に 1.3〜1.5倍の係数 を掛け、さらにCPUの物理コア数を超えない範囲（またはI/Oバウンドであることを考慮して適切に）調整する。

② `StartTrappers` の必要数計算

アクティブチェックの規模と、Zabbix APIの同時リクエスト数に依存する。
基本的には以下の式をベースにする：
$$\text{StartTrappers} = \max \left( 8, \ \left\lfloor \frac{\text{1秒あたりのアクティブデータ受信数} \times \text{処理レイテンシ}}{1} \right\rfloor \right)$$
大規模型環境では、`StartTrappers` を `30` 〜 `60` に設定することが多いが、多すぎるとコンテキストスイッチのオーバーヘッドが増大するため注意が必要だ。

③ `StartPreprocessors` の必要数計算

PreprocessorはCPUバウンドな処理（特にJavaScriptエンジン）を実行するため、原則として利用可能なCPUコア数（物理コア）の数を基準にする。
$$\text{StartPreprocessors} = \text{物理CPUコア数} \times 1.5 \sim 2$$
これを超えて増やしても、CPUのコンテキストスイッチが増えるだけでスループットは低下する。もしプリプロセッサーが追いつかない場合は、プロセス数を増やすのではなく、JavaScriptのコードを最適化するか、前処理の負荷をエージェント側にオフロード（Advanced Preprocessing / Custom Agent Plugins）すべきだ。

—

3. 実践：`zabbix_server.conf` 限界突破チューニング

以下に、数万ホスト規模（100,000+ NVPS）を安定稼働させるための `zabbix_server.conf` の核心部分を提示する。各パラメータの真の意味をコメントから読み取ってほしい。

=================================================================ッチ
Zabbix Server Performance Tuning Configuration (Enterprise Grade)
=================================================================

— データベース接続プーリング —
DBとのコネクション数。DBSocketを使用する場合は適切に調整。
StartDBSyncers=8

— パッシブポーラー設定 —
同期型ポラー。ネットワーク遅延に弱いため、非同期(PollersAsync)と併用、
もしくは極力アクティブチェックに移行して最小限に抑える。
StartPollers=50

— 非同期ポーラー (SNMP / Agent用) —
大規模環境では StartPollers よりもこちらを厚くする。libeventの限界までスケーラブル。
StartPollersAsync=100

— トラッパー設定 —
アクティブエージェント、Sender、APIからのリクエストを処理。
APIを多用する（Grafana連携など）場合は多めに確保。
StartTrappers=40

— HTTPポーラー (Web監視) —
重いWebシナリオを監視する場合は、スレッドブロックを防ぐために独立して確保。
StartHTTPPollers=20

— プリプロセッサー (最重要ボトルネックポイント) —
CPUコア数に合わせて設定。ここに負荷が集中するため、これ以上の増加はCPUキャッシュヒット率を下げる。
StartPreprocessors=16

— キャッシュサイズ（メモリ最適化の要） —
履歴キャッシュ。物理メモリの許す限り大きくし、DBへの書き込み頻度を減らす。
HistoryCacheSize=2G

履歴インデックスキャッシュ。HistoryCacheSizeの約半分を目安に。
HistoryIndexCacheSize=1G

トレンドキャッシュ
TrendCacheSize=512M

バリューキャッシュ（ダッシュボードやグラファナのクエリ高速化に直結）
ValueCacheSize=3G

設定キャッシュ（ホストやアイテム定義のキャッシュ。巨大環境では 512M〜1G 必須）
CacheSize=512M

履歴シンクロナイザープロセス数
DBへの書き込みを並列化する。DBSyncersが少なすぎるとHistoryCacheが溢れる。
StartDBSyncers=8

— タイムアウト制御 —
ネットワーク機器の応答遅延によるPoller詰まりを防ぐための防衛ライン。
デフォルトの3秒は短すぎることが多いが、長すぎるとPoller枯渇を加速させる。
Timeout=5

エージェントからのデータ切断時間
TrappersTimeout=30

—

4. 監視の監視：プロセッサー枯渇の予兆を検知するメタ監視

「プロセッサーが枯渇してから気づく」のでは、プロフェッショナルなオブザーバビリティ・アーキテクトとは言えない。枯渇が起こる「直前」のメトリクスを監視し、オートスケーリングやアラートのトリガーとするべきだ。

Zabbixの内蔵内部チェック（Internal checks）を活用し、以下のキーを必ず監視せよ。

1. `zabbix[process,,,avg]`

  • 例: `zabbix[process,poller,–,busy]`
  • 意味: 特定のプロセッサーがビジー状態である割合（%）。
  • 閾値アラート: `avg(5m) > 80%` で警告、`95%` でCRITICAL。これが95%を超えた瞬間からキューの雪崩が始まる。

2. `zabbix[queue]`

  • 意味: 処理待ちのアイテムキューの数。
  • 閾値アラート: `last() > 1000` が5分続いた場合。キューの増加傾向（二次関数的な上昇）を捉えることで、障害発生前に手を打つことができる。

3. `zabbix[preprocessing_queue]`

  • 意味: プリプロセッサーの処理待ち数。
  • 知見: ここが増加している場合、ハードウェアのCPU性能限界か、JavaScriptの非効率なコードが原因である。即座にプロファイリングを行え。

—

5. 自動化と診断：CLIによるリアルタイム・プロセスプロファイリング

異常が発生した際、Zabbixサーバーのログを見るだけでは不十分だ。現在どのプロセッサーが何にブロックされているかをリアルタイムで暴くには、Linuxの低レイヤツールを組み合わせる。

Zabbixランタイムコントロールの活用

Zabbixサーバーは、再起動せずに実行時パラメータを変更・調査する機能（Runtime control）を持っている。

プロセッサーの稼働状況をダンプするには以下のコマンドを叩け：

現在のすべてのプロセッサーの稼働率・状態をログに出力する
zabbix_server -R diaginfo

出力されたログ（通常 `/var/log/zabbix/zabbix_server.log`）には、各プロセッサープールが何％ビジー状態であるかが詳細に記録される。

`perf` と `strace` によるシステムコールレベルの解析

特定のPollerがハングアップしている場合や、原因不明のCPUスパイクがある場合、アーキテクトはカーネルレイヤまで踏み込む。

特定の zabbix_server (poller) プロセスのシステムコールをトレースし、
どのソケット通信（外部機器へのSNMP/TCP）でブロックされているかを特定する
strace -p -T -y -e trace=network

CPUプロファイリングを行い、どの関数がボトルネックになっているかを炙り出す
perf top -p

ここで `js_eval` や `regcomp` などの正規表現・JavaScript関連の関数が上位に張り付いている場合、前処理の設計ミスであることが一目瞭然となる。

—

結びにかえて：真のオブザーバビリティとは

Zabbixのタイムアウトや輻輳は、「運が悪かったから起きた」のではない。すべては数学的・物理的なリソース配分の破綻によって引き起こされる必然の現象だ。

プロセッサーの役割を解剖し、数式に基づいてプロセス数を計算し、内部メトリクスによるメタ監視を張り巡らせる。そして、ボトルネックが生じた際にはランタイムコントロールやシステムコールレベルで真因を撃ち抜く。

このレベルの解像度を持ってZabbixを掌握した時、監視ツールは単なる「アラート発報装置」から、システム全体の健康状態を完璧に把握するための最強のオブザーバビリティ・プラットフォームへと昇華する。

さあ、今すぐあなたの `zabbix_server.conf` を開き、その歪みを正せ。

スポンサーリンク
タイトルとURLをコピーしました