Zabbix Advent Calendar 2016の17日目の記事です。
カスタマーサポート課の伊藤です。
サーバーワークスZabbixスペシャリスト 九龍として今回は Zabbix Serverのチューニングポイントをお伝えします。
前回はZabbix Serverの構築手順をご紹介しました、是非皆さんもお手元のZabbixServerのプロセス負荷を確認してみてください。
※DBチューニングについては今回は含んでいません。
下準備と前提知識
まずはデータ収集のためにZabbixServerの自己監視用ホストを登録し、 Template App Zabbix Server を適用します。
なおTemplate App Zabbix Serverに利用されているzabbixアイテムキーはServerプロセスから直接、値を収集します。このため、Proxyの負荷状況を取得したい場合は、Serverに直接設定せずに、Proxy経由のホストに対して設定する必要があります。
Template App Zabbix ServerではZabbix内部の各種プロセスの負荷状況およびキャッシュ利用状況が収集されます。
Zabbixのプロセスの負荷を確認する場合にはbusy率を確認します。
busy率はプロセスのプロセス全体の合計時間における動作時間の割合となります。
基本的には、40％～70％程度に落ち着くようにチューニングすることをおすすめいたします。
ただし、負荷が偏る条件がありますので、100/プロセス数＝％でグラフがフラットになっている様な場合は
負荷分散が出来ずに1つのプロセスが100％に張り付き、他のプロセスが0%と言う場合あるので、注意が必要です。
Zabbix data gathering process
まずは、データ収集に関わるプロセスを確認します。
[監視データ]-[グラフ]からZabbixServerホストを選択し、グラフ[Zabbix data gathering process busy %] を選択します。
実際のZabbix data gathering process busy %を見てみます。
Zabbix data gathering processをグラフの表示順に見ていきます。
- trapper processes
ZabbixSender,ZabbixAgentのアクティブアイテム,アクティブモードProxyからのデータ受信を担当します。
アイテムタイプ：Zabbixトラッパー,Zabbixエージェント(アクティブ)が多い場合、アクティブモードプロキシを利用している場合に負荷が上がります。
Proxyによる接続時間が長くなる場合があるので、アクティブプロキシ数＋αを基本の考え方として、busy率の数値を元にプロセス数を決定します。
trapper processesの数はStartTrappers=の値により設定します。パッケージの初期値は5です。 - poller processes
ZabbixAgentのパッシブアイテム、SNMPポーリングアイテムのデータ収集を担当します。
アイテムタイプ：Zabbixエージェント,SNMPエージェントが多い場合に負荷が上がります。busy率の数値を元にプロセス数を決定します。
poller processesの数はStartPollers=の値により設定します。パッケージの初期値は5です。 - ipmi poller processes
サーバハードウェアに搭載されるIPMIボードからのセンサーデータ収集を担当します。
アイテムタイプ：IPMIエージェントが多い場合に負荷が上がります。busy率の数値を元にプロセス数を決定します。
ipmi pollerの数はStartIPMIPollers=の値により設定します。パッケージの初期値は0です。変更を行っていない場合はIPMIのデータ収集はできません。 - discoverer processes
[設定]-[ディスカバリ]で設定したネットワークディスカバリを担当します。
ディスカバリ範囲から対象となるIP数を確認します。応答があれば短時間でディスカバリが完了しますが、応答しないIPがある場合は、Timeout=の秒数だけ待機します。このため、応答しないIPが多ければディスカバリに要する時間が長くなります。その場合、タイムアウト×IP数の合計時間がディスカバリ周期以内に収まるように、ディスカバリ範囲を設計する必要があります。
ディスカバリ範囲を分割した場合は、ディスカバリ設定の数だけdiscoverer プロセスを用意します。
discoverer processesの数はStartDiscoverers=の値により設定します。パッケージの初期値は1です。 - icmp pinger processes
ICMP Ping監視を担当します。
アイテムタイプ：シンプルチェックicmpping,icmppingsec,icmppinglossが多い場合に負荷が上がります。
また、存在しないIPアドレスに対してPingチェックを行っている場合、タイムアウトまで待つことになるため負荷が上がります。プロセス数の設定の他、存在しなくなった監視対象の削除、タイムアウトの調整なども検討してください。
icmp pinger processesの数はStartPingers=の値により設定します。パッケージの初期値は1です。 - http poller processes
WEB監視を担当します。
ウェブシナリオ監視の登録が多くなると、負荷が上がります。
http poller processesの数はStartHTTPPollers=の値により設定します。パッケージの初期値は1です。 - proxy poller processes
パッシブモードプロキシからのデータ収集を担当します。
パッシブモードプロキシ数だけ設定しておけば良いでしょう。都度増やすのではなく、ある程度計画的に事前に増やしておく事をおすすめします。
proxy poller processesの数はStartProxyPollers=の値により設定します。パッケージの初期値は1です。 - unreachable poller processes
到達不能ホストへのポーリングを専門に受け持ちます。
ZabbixエージェントやIPMIエージェント、SNMPエージェント、JAVAエージェントなどで値が不正などでは無くそもそも到達性が無いと判断されたホストは通常のPoller プロセスの対象から外され、unreachable pollerのリストに登録されます。
到達不能と判断される時間はUnreachablePeriod=の値により設定します。パッケージの初期値は45秒です。
unreachable pollerプロセスは到達不能と判断されたホストをUnreachableDelay＝値により設定された時間毎に再度チェックされます。パッケージの初期値は15秒です。
unreachable poller processesの数はStartPollersUnreachable=の値により設定します。パッケージの初期値は1です。 - java poller processes
JMXエージェント監視を受け持ちます。
JMXエージェントでJavaVMから値を収集する際に必要となります。
java poller processesの数はStartJavaPollers=の値により設定します。パッケージの初期値は0です。JMX監視を行う場合は1以上に設定を変更します。 - snmp trapper processes
SNMPTTによって出力されたSNMPTrapperFileからデータ収集を行うプロセスです。
snmp trapper processesは動作するかしないかのいずれかですので、チューニングはできません。
StartSNMPTrapper=の値により設定します。パッケージの初期値は0です。SNMPTTを用いたSNMP Trap監視を行う場合は1に設定してください。 - vmware collector processes
VMwareからのデータ収集を受け持ちます。
VMware監視を行う場合に必要になります。
vmware collector processesの数はStartVMwareCollectors=の値により設定します。パッケージの初期値は0です。VMware監視を行う場合は1以上に設定してください。
Zabbix internal process
次にZabbixServer内部でデータ処理を行うプロセスを確認します。
[監視データ]-[グラフ]からZabbixServerホストを選択し、グラフ[Zabbix internal process busy %] を選択します。
実際のZabbix internal process busy %を見てみます。
Zabbix internal processをグラフの表示順に見ていきます。
- timer processes
周期的に判定を行うトリガー（nodata関数）とメンテナンス期間のIN/OUT判定を処理します。
メンテナンス期間の判定は第1プロセスのみが処理します。
nodata関数の利用が多い場合に負荷が上がります。nodata関数の利用が多い場合は、busy率に合わせてプロセス数の増加を検討してください。
timer processesの数はStartTimers=の値により設定します。パッケージの初期値は1です。 - node watcher processes
Zabbix 2.2 までのnode構成でNodeとの連携を受け持つプロセスです。
2.4以降ではnoda構成が削除されましたので、設定項目はありません。 - escalator processes
アクションのエスカレーション処理を受け持ちます。
通知が多い場合に負荷があがります。Zabbix 2.x ではシングルプロセスなので、チューニング出来ません。
Zabbix 3.0からチューニング可能となりました。
escalator processesの数はStartEscalators=の値により設定します。パッケージの初期値は1です。 - housekeeper processes
データーベースないで保存期間が過ぎたデータを削除するプロセスです。
シングルプロセスなので数量の変更はできません。
HousekeepingFrequency=の値により動作周期を設定します。
ハウスキーパープロセス1回の削除時に、 周期の4倍以内のデータを古い物から削除します。
HousekeepingFrequency=1の場合は最大で4時間分のデータを削除します。
HousekeepingFrequency=24の場合は最大で4日分のデータを削除します。
Zabbix 2.4 以降では、起動時の過負荷を避けるため、起動後30分後に動作を開始し、その後はHousekeepingFrequency=の周期毎に動作を行います。
HousekeepingFrequency=を0にした場合は、定期的なデータ削除を行いません。DBパーティショニングによるパーテーションドロップや、Zabbix 3.0 以降でサポートされた手動実行によるハウスキーピングを行いたい場合に設定します。
手動ハウスキーピングを行う場合は
zabbix_server -R housekeeper_execute
を行います。 - alerter processes
アクション実行を受け持ちます。
シングルプロセスなのでチューニングはできません。
alerter processesの負荷が高い場合は、実行されるアラートスクリプトの見直し、メールサーバーの応答性能改善などを検討してください。 - configuration syncer
周期的にDBから設定情報をメモリ上に読み込みます。
チューニング項目はありません。 - db watchdog
DBとの接続性を確認します。
チューニング項目はありません。 - history syncer processes
収集されたメモリ上のデータをDBに書き込むプロセスです。
history syncer の負荷が高い場合データ収集量に対してDB書き込み性能が足りない可能性が考えられます。
history syncer processesの数はStartDBSyncers=の値により設定します。パッケージの初期値は4です。
history syncer の負荷が高い場合プロセス数を増やす方法は有効ですが、ログ監視が多い場合負荷分散が効かずに、1つのプロセスのみ高負荷となり、見かけの負荷が小さくるのに性能が出せない場合があります。
この場合はDB側のIOPS性能を上げる必要があります。この場合はプロセス毎の負荷率を取得し、負荷の偏りを確認する必要があります。
history syncerのバランスを確認したい場合は私の作成したhistory syncer_templateをおすすめいたします。 - self-monitoring processes
Zabbix の自己監視データ用プロセスです。
アイテムタイプ：Zabbixインターナルの値収集に使われます。
チューニング項目はありません。
Zabbix cache usage
続いて、Zabbixのメモリチューニングを見ていきます。
[監視データ]-[グラフ]からZabbixServerホストを選択し、グラフ[Zabbix cache usage, % free] を選択します。
実際のZabbix cache usage, % freeを見てみます。
Zabbix cacheをグラフの表示順に見ていきます。
- trend write cache
トレンドデータを保持する共有メモリです。トレンドデータ使用するトリガーなどが多くなると消費量が増えます。
TrendCacheSize=の値により設定します。パッケージ初期値は4MBです。 - configuration cache
ホスト設定、アイテム設定、トリガ設定を保持する共有メモリです。監視対象が増えると消費量が増えます。
CacheSize=の値により設定します。パッケージの初期値は8MBです。監視項目数に合わせてチューニングしてください。 - text write cache
文字列、テキスト、ログ型の収集データを格納する共有メモリです。Zabbix 2.x で利用されていた項目です。Zabbix 3.0 からはテキスト型独立のメモリは廃止され、後述のhistory write cacheに統合されました。
HistoryTextCacheSize＝の値により設定します。パッケージの初期値は16MBです。
収集するデータ量に応じてチューニングが必要です。
Zabbix 3.0以降ではこのパラメータはありません。 - history write cache
文字列型の収集データを格納する共有メモリです。
HistoryCacheSize=の値により設定します。パッケージの初期値はZabbix 2.x の場合は8MBです。
Zabbix 3.0 以降ではtext write cacheの役目も引き継いだため、16MBになっています。
収集するデータ量に応じてチューニングが必要です。 - history index write cache
HistoryCacheに格納されるデータのインデックス情報を格納する共有メモリです。テンプレートにはまだ含まれていませんが、 Zabbix 3.0 から追加されたキャッシュです。
監視アイテム1つにつき約100Byteの領域が必要です。
HistoryIndexCacheSize=の値により設定します。パッケージの初期値は4MBです。 - value cache
数値型の収集データを格納する共有メモリです。value cacheが不足した場合、zabbix_server.logに5分周期でメッセージが出力されます。
ValueCacheSize=に値により設定します。パッケージの初期値は8MBです。 - vmware cache
VMware監視の際にvmware collector processesが収集してきたデータが格納される共有メモリです。VM監視を行う場合に必要になります。
VMwareCacheSize=の値により設定します。パッケージの初期値は8MBです。
vmware collector processesの起動設定がされていない場合は、確保されません。
まとめ
Zabbixのチューニングは難しいと思われがちですが、基本的にはTemplate App Zabbix Serverを適用し、テンプレートのグラフを確認することで、プロセスやキャッシュの過不足を確認することが出来ます。
注意点として、100％に張り付いているプロセス以外に、25％や20％など、100/プロセス数のような数値でフラットになっている場合は、特定のプロセスに負荷が偏って可能性があります。
この場合は、当該プロセスをプロセスNo毎に分解した値を収集するなどして、負荷の偏りを確認してください。
負荷に偏りが無い場合は、プロセス数を増やすことで、性能を改善できる可能性が高いです。
負荷に偏りがある場合は、ディスクIO性能やアラートスクリプトなど、外部要素により性能が頭打ちになっている可能性が考えられますので、マシン性能の強化やスクリプトの改修等を検討してください。
Template App Zabbix Serverで快適なZabbix生活をお送りください。
来週はZabbixの基本的なアーキテクチャ解説と設定方法についてお送りします。
それではまた！
