第5回 応用編 (1/3)

技術特集

1_zabbix5_tit

tit_zabbix
1)大規模環境への対応

Zabbixで監視する環境が大きくなってくるにつれて、ZabbixサーバとZabbixサーバが利用するデータベースのチューニングが重要になってきます。


Zabbixサーバが十分に処理できているかを把握するためには、


  • キューの状態
  • Zabbixサーバの各プロセスのbusy率
  • Zabbixサーバのキャッシュ利用状況
  • Zabbixサーバ自体のOSとしての負荷状況

で確認することができます。


データベースの部分のチューニングに関しては、その負荷状況に合わせてデータベース自体のチューニングやデータベースを稼働させるサーバのOS自体のチューニングで行うことになります。


今回はZabbixの特集ですので、MySQLやPostgreSQLといった個別のデータベース製品のチューニングに関しては割愛させて頂きます。
ただ注意して頂きたいのは、サーバに十分なメモリを搭載したとしても、インストールしただけのデフォルトの設定のままだと良いパフォーマンスが得られません。

例えば、折角サーバに大量のメモリを搭載しても、デフォルトの設定のままでは、そのメモリを有効に利用した処理を行うことができませんので、必ず利用するメモリサイズや利用方法に合わせた設定を行うことが必要であるということだけは覚えておいてください。


Zabbixサーバのサーバプログラム(デーモン)側も、監視の規模によっては、いくつかのチューニングを行うことが必要になります。


チューニングポイントを挙げるとすれば、例えば以下のようなポイントがあげられます。


  • 各処理プロセスのプロセス数の増減
  • Zabbixが利用するキャッシュメモリの増減
  • Zabbixプロキシを利用した処理の負荷分散

プロセス数のチューニングに関してですが、現時点のZabbixサーバのサーバプロセスは複数のプロセスによって構成されています。


各プロセスは以下の図のような構成になっています。
(Zabbixのバージョンによってプロセスの有無や個数が異なる場合があります。)


zbx_large_process


デフォルトの設定ファイルでは、起動されないプロセスもあります。
上図の「x 0」と書かれているのがそういったデフォルトでは起動されないプロセスです。

あと、青い矢印は、Zabbixサーバ側から値を取得しにいく種別の処理で、オレンジの矢印は各種エージェントからZabbixサーバに通知される(アクティブ)な処理となります。


具体的な機能への影響という意味では、VMware監視用(vmware collector)やJMX監視用(java poller)のプロセスは、デフォルトだとプロセス自体が起動されませんので、必要に応じて値をきちんと設定してから起動するようにしてください。

プロセス数を変更できないものもあるのですが、それらを変更しなければならないような状況には通常はなりにくいと思います。

JMXとは、Javaに標準で用意された監視と管理のための仕組みです。これを利用することで、Java VM内のメモリの利用状況や変化を監視したりすることができます。


起動されるプロセスは、それぞれ役割を持ったプロセスとして起動されるのですが、監視するアイテムの内容や量によっては、デフォルトで起動させる数よりも多くのプロセスを起動しておかないと、処理しきれない状態が発生してしまう場合があります。
例えば、本来であれば30秒間隔で監視するつもりであったのが、分単位での監視しかできなくなってしまうような場合が発生してしまう可能性が考えられます。


それぞれの処理の負荷状況や進捗状況を確認するためには、


  • 各処理のキュー
  • 各プロセスのbusy率

を確認します。


キューの状態の確認は、「管理」->「キュー」で確認することができます。

キューの画面は、以下のような画面になります。
正常に処理できていて、処理が滞留してしまっているような状況が発生していなければ、すべて0で表示されます。
本来取得する予定であったタイミングで値を取得できずに処理待ちの状態のアイテムがあれば、それぞれZabbixエージェントを利用した値取得なのかSNMP を利用した値取得なのかといった種別毎に、処理が遅延してキューに溜まっているような状態のアイテムの個数を確認することができるようになっています。


zbx_large_queue


各プロセスのbusy率は、元々用意されているテンプレート「Template App Zabbix Server」をZabbixサーバに紐づけしておくと値の取得とグラフの作成が行われるようになっているので、Zabbixサーバを構築された場合は、このテンプレートを紐づけしておくことをお勧めします。

このテンプレートを紐づけしておくと、以下のようなグラフを見ることができます。


zbx_large_internal


Zabbixサーバを稼働させているサーバの負荷状況に問題が無ければ、キューに溜まっている種別に対応した処理プロセス数を増加させることで問題が解決する場合が多いでしょう。

例えば、「Zabbixエージェント」のキューが溜まっているようであれば、Pollerのプロセス数を増加させ、「Zabbixエージェント(アクティブ)」のキューが溜まっているようであれば、Trapperプロセスを増加させて対応します。
プロセス数を増やしても改善しない場合は、値取得時にタイムアウトが発生してしまっていないかを確認してください。


タイムアウトが発生してしまっているようであれば、zabbix_server.confとzabbix_agentd.conf内のTimeoutの値を伸ばしてみてください。

ただし、Timeoutの値は30秒が上限です。
それ以上の時間がかかるようなアイテムの値取得処理は、Zabbixから直接取得することができませんので、cronなどと組み合わせて別途値を取得してファイルなどに出力させておき、Zabbixではそのファイルを読み込んで値を取得するか、zabbix_senderという外部から値をZabbixサーバに送るコマンドを利用してZabbixサーバに値を渡すようにして対応することをご検討ください。


なお、zabbix_senderに関しては、後の節でご紹介します。


先に、Zabbixプロキシを利用した負荷分散に関して、次の節で説明します。