DevOps実践に有用なZabbixの機能〜自動化機能で運用負荷削減：クラウド＆DevOps時代の運用をZabbixで（3）（1/2 ページ）

ますますクラウド化が進む環境において、システムにはより迅速な対応が求められるようになっています。変化の早いシステムを適切に運用していくためにはどうすればいいのでしょうか？ この記事では、クラウドやDevOpsを前提としたITシステムの「運用」に求められることを整理し、そういった運用に対して、オープンソースの統合監視ツール「Zabbix」がどのように有効活用できるかを紹介します。

[池田大輔（TIS株式会社），＠IT]

　前回の記事「DevOps実践に有用なZabbixの機能〜開発と運用を近づける監視」では、DevOpsを実践するに当たって、開発者と運用者をZabbixを通じてより近づける方法について紹介しました。第3回目の本記事では、運用面にフォーカスを絞り、Zabbixの自動化機能を活用して監視運用作業の負荷をできる限り減らす方法を紹介します。

　第1回でも紹介しましたが、Zabbixは自動化を実現するさまざまな機能を有しています。用途に応じてそれらを使い分けることで、効果はより高まります。

　Zabbixで監視運用を実施するには、大きく分けて以下の3つのステップの作業が必要となります。

1. 監視対象となる機器情報の登録
2. 各監視対象機器に対する監視設定
3. 障害発生時のアクション実行設定

　まず、1.や2.のZabbix Serverに対する登録・設定作業をできる限り自動化し、監視システムを効率よく実現し、管理する方法を紹介します。続けて、3.の障害発生時のアクション実行を効果的に設定し、オペレーション負荷を削減する方法を紹介していきます。

監視対象機器登録の自動化

　仮想化やクラウド化が進むにつれ、環境はより大規模化したり、より動的に変化（マシンの追加・削除や設定変更）しやすくなっています。このような環境の監視を、これまでと同様の対応で行っていては、運用負荷が高まるばかりです。

　例えば、監視対象となる機器が追加されるたびに、その情報を手作業でZabbixに登録していては、上記のような環境では限界が生じます。Zabbixにはこうした問題を解決するため、監視対象となる機器を自動登録できる機能がいくつか用意されています。

ネットワークディスカバリ

　ネットワークディスカバリ機能は、あらかじめ登録されたネットワークIPアドレスレンジに対して、Zabbix Serverがポーリング監視を行い、ディスカバリ処理を実施する機能です。監視対象機器へのZabbix Agent導入の有無にかかわらず、さまざまな条件を基に、追加された機器をディスカバリできます。

　ディスカバリ条件として、以下のような設定が可能です。

■ディスカバリ条件リスト

検知条件タイプ	検知処理内容
FTP	指定したポートがリッスンしているかどうかを検知
HTTP
HTTPS
IMAP
LDAP
NNTP
POP
SMTP
SSH
TCP
Telnet
ICMP ping	ICMP pingが到達するかどうかを検知
SNMPv1エージェント	SNMPの特定のOID情報が取得できるかどうかを検知
SNMPv2エージェント
SNMPv3エージェント
Zabbixエージェント	Zabbix Agentの特定のアイテムキーの値が取得できるかどうかを検知

　ネットワークディスカバリ機能によって新たな機器が発見された後は、「アクション」を実行し、Zabbixに対するホスト登録などが行えます。

　ネットワークディスカバリに対するアクションで実行できる処理の一覧は、以下の通りです。

• メッセージの送信
• リモートコマンドの発行
• ホストを追加
• ホストを削除
• ホストグループに追加
• ホストグループから削除
• テンプレートとのリンクを作成
• テンプレートとのリンクを解除
• ホストを有効化
• ホストを無効化

ネットワークディスカバリ利用時の注意点

　ネットワークディスカバリを利用する場合には、その仕様上、存在しないIPアドレス宛にもパケットが送られることになります。そのため、指定したネットワークIPアドレスレンジ内に管理下にないマシンが存在していたり、パブリッククラウドサービスのようにIPアドレスレンジを特定できない環境に対しては適用が困難です。

Zabbix Agent自動登録機能

　上記の注意点を改良し、より効率よく監視対象機器を登録できるようにする機能が「Zabbix Agent自動登録機能」です。

　この機能では、Zabbix Agentは起動時に、Zabbix Agentの設定ファイル（zabbix_agentd.conf）のServerActiveに指定されたZabbix Server宛てにプッシュ方式で自身の情報を通知します。Zabbix Serverはその内容に沿って、監視対象として自動的に登録します。

　このような仕組みを採るため、ネットワークディスカバリのような不要なパケットが流れることはなく、監視対象機器の登録作業を効率よく自動化できます。なお、ネットワークディスカバリとZabbix Agent自動登録という2つの方法の概要を示すと、以下のようになります。

図1　ネットワークディスカバリとZabbix Agent自動登録の概要

　Zabbix Agent自動登録機能は、Zabbix Agentが監視対象機器に導入されていることが前提となるため、ネットワーク機器などのディスカバリはできません。しかし、プッシュ型で情報を登録できることから、パブリッククラウドサービスのインスタンスなど、対象機器のIPアドレスの特定が困難な環境であっても自動的に登録が行えるなどのメリットがあります。

Zabbix 2.2での最新ポイント

　これまでZabbix Agent自動登録機能では、Zabbix Agentの設定ファイル（zabbix_agentd.conf）に記載された「Hostname」「ListenIP」「ListenPort」という3つの情報のみがZabbix Serverに送られていました。そしてZabbix Serverでは、これら3つの情報のみに基づいて「どういったテンプレートを割り当てるべきか」といった事柄を決めなければならず、あまり柔軟に自動化できないといった課題がありました。

　この課題に対応するため、Zabbix 2.2では新たに「HostMetadata」という情報を送れるようになりました。HostMetadataの設定は、Zabbix Agentの設定ファイル（zabbix_agentd.conf）に行います。zabbix_agentd.confでは、新たに次の2つの設定を行えるようになっています。

• HostMetadata
• HostMetadataItem

　例えば、Zabbix Serverに対して、「OSの種別が何であるか」、また「サーバの役割が何であるか」といった情報を送りたい場合には、次のように設定します。

HostMetadata=Linux WebServer

　このようにHostMetadataには、任意の文字列を指定できます（ただし「255文字以内」という制限があります）。HostMetadataを指定することで、Zabbix Server側のアクションの実行条件設定時に、以下のような指定ができるようになります。

• アクションの実行条件：「ホストメタデータ」に「Linux」が「含まれる」 and 「ホストメタデータ」に「WebServer」が「含まれる」
• アクションの実行内容：「ホストを追加」 and 「Linux監視用テンプレートを割り当てる」 and 「WebServer監視用テンプレートを割り当てる」

　また、HostMetadataを指定する代わりに、HostMetadataItemの設定を利用することもできます。HostMetadataItemには、Zabbix Agentが実行できる監視アイテムキーを指定します。例えば、OSの情報を監視するためのアイテムキーである「system.sw.os[]」の結果をZabbix Serverに渡したい場合には、次のように設定します。

HostMetadataItem=system.sw.os[]

　この時、HostMetadataが設定されているとHostMetadataItemは送付されないため、HostMetadataの設定部分はコメントアウトし、無効化しておく必要があります。HostMetadataやHostMetadataItemを設定した後はZabbix Agentを再起動し、zabbix_agentd.confの設定を反映してください。

Zabbix API

　ここまで紹介したネットワークディスカバリやZabbix Agent自動登録機能を活用することで、監視対象機器の設定作業を自動化できます。より柔軟な設定をしたい場合や監視対象機器の登録以外の処理も自動化したい、といった場合には「Zabbix API」を利用します。

　Zabbix APIを利用することで、「監視結果データの取得」および「Zabbix Serverに対する設定」をプログラマブルに行うことができます。使い方については本記事では割愛します。詳細は公式マニュアルなどを参照してください。