Pollerプロセスの必要数は？ 【MIRACLE ZBX 1.8, 2.0, 2.2】
Pollerプロセスはいくつぐらい設定したらよいのでしょうか？
MIRACLE ZBXのサポートへの質問で、「アイテムの監視に遅延が発生している」といったものや、もっと直接的に「Pollerプロセスの数はいくつに設定したらよいでしょうか？」といったものが時々ありました。
Zabbix LLCの資料にもこれといった指標となるものがなく、「問題が発生するようなら5割増をしてみてください。Pollerプロセス自体はそれほどメモリやCPUリソースは消費しないので増やしても特に問題はありません。」という旨を返答していました。しかしながら、やはり指針となる計算方法があった方が便利と思い、考察してみました。
どれくらいのパフォーマンスが必要なのだろう？
まずは設定した監視項目からどれくらいのパフォーマンスが必要かが計算できるはずです。
Pollerプロセスが受け持つアイテムのアイテムタイプは、以下のようになっています。
0 zabbix
1 snmp v1
3 simple
4 snmp v2c
5 internal
6 snmp v3
8 aggregate
10 external
11 db monitor
12 ipmi
13 ssh
14 telnet
15 calculate
16 jmx (1.8を除く)
(番号づけの意味は、include/common.h をご覧になってください。)
上記を考慮して、DBへから必要なパフォーマンスを計算してみます。
一つのPollerプロセスが動作していて、一つのアイテム監視を平均何秒以内で完了すれば遅延がなくなるかは、アイテムの更新間隔の逆数の和の逆数で求められます。
mysql> select 1/sum(1/delay) from items where type not in (2, 7, 9, 17);
+----------------+
| 1/sum(1/delay) |
+----------------+
| 0.0062 |
+----------------+
1 row in set (0.01 sec)
上記の結果(単位はsec/個)では、1アイテムの監視が0.0062秒以内に完了すれば遅延が発生しないことになります。
実際のPollerプロセスのパフォーマンスは？
それでは、実際のPollerプロセスのパフォーマンスはどうなっているのでしょう？
これはDebugLevel=4のログから判別します。
22578:20150407:122319.988 In get_values()
22578:20150407:122319.988 In DCconfig_get_poller_items() poller_type:0
22578:20150407:122319.988 End of DCconfig_get_poller_items():1
22578:20150407:122319.988 In substitute_key_macros() data:'system.cpu.util[,idle]'
22578:20150407:122319.988 End of substitute_key_macros():SUCCEED data:'system.cpu.util[,idle]'
22578:20150407:122319.988 In substitute_simple_macros() data:'10050'
22578:20150407:122319.988 In get_value() key:'system.cpu.util[,idle]'
22578:20150407:122319.988 In get_value_agent() host:'Zabbix server' addr:'127.0.0.1' key:'system.cpu.util[,idle]
'
22578:20150407:122319.990 Sending [system.cpu.util[,idle]
]
22578:20150407:122319.990 get value from agent result: '94.893191'
22578:20150407:122319.990 End of get_value():SUCCEED
22578:20150407:122319.990 In activate_host() hostid:10084 itemid:23299 type:0
22578:20150407:122319.990 End of get_values():1
22578:20150407:122319.990 poller #4 spent 0.002389 seconds while updating 1 values
22578:20150407:122319.990 In DCconfig_get_poller_nextcheck() poller_type:0
22578:20150407:122319.990 End of DCconfig_get_poller_nextcheck():1428377000
0.002秒で完結しています。前節の結果と合わせるとPollerプロセスは1つでよいことになります。
ただし、今回取得したログはZabbix Server自体への監視でオーバーヘッドも少ないことから、平均して0.01秒掛かるとします。この場合でも、Pollerプロセスは2つでよくなります。(0.01 / 0.0062 = 1.61)
実際に必要な数は非定常状態になったとき
前節までの議論は監視に全く問題が発生しないという状況でのことです。
実際の監視では、ネットワーク的に問題が発生することもあるし、エージェントの反応が悪くタイムアウト
が発生することもあります。諸々のオーバーヘッドも全く考慮していません。
タイムアウトの設定が3秒(デフォルト値)で、10%の監視がタイムアウトギリギリまで掛かったとすると、1アイテムの平均取得時間は、
3 * 0.1 + 0.01 * 0.9 = 0.309(sec)
となり大きく上昇します。
この場合、必要なPollerプロセス数は、0.309 / 0.0062 = 49.8 となり、50以上のプロセスが必要となります。
(大雑把に10%という値を導入しましたが、出てきた値から考えるに悪くない計算ではないかと思います。)
結局として、Pollerプロセスの必要数の算出は、タイムアウト値と失敗率が支配的となってしまいましたが、指標の算出を行うことができました。
必要なUnreachablePoller数は？
最後に、必要なUnreachablePollerの数を考察します。
ネットワークエラー等で監視が行えなかったアイテムは、次回Unreachable Pollerプロセスにより処理されます。
初回監視は、UnreachableDelay秒後に行われ、ここでも失敗した場合は、初回監視失敗からUnreachablePeriod秒以内であれば、再度UnreachableDelay秒後に監視が行われます。
そして、監視に成功した場合、以降の監視はPollerプロセスに戻されます。
Unreachable Pollerプロセスの数の算出は難しいです。というのも、監視が失敗しない定常状態でしたらそもそもこれは必要ありません。
逆に必要となるときは、なんらかのトラブルが発生したときとなり、必要な数が急激に増加します。ただし、初回で全て成功するようなら1プロセスでも充分なはずなので、上記で算出したPollerプロセスの数に失敗率を掛けたものでいかがでしょう？(50 x 0.1 = 5プロセス)
