はじめに

監視には、監視する側（Zabbixサーバー） と 監視される側（監視対象ホスト = ノード） が存在します。
監視を行う際、この関係を理解することが非常に重要です。

また、監視の種類によって通信の方向が異なるため、どのようにデータがやり取りされるのかを明確に把握する必要があります。

この記事では、Zabbixサーバーとノードの関係や、監視の種類、通信の方向について詳しく解説します。

この記事では監視の仕組みや通信の流れを理解していただくことを念頭に置いています。
実際の構築方法や設定等はこの記事では解説していません。

監視の種類

まずは監視の種類について解説します。
Zabbixで使用する監視方法の例をいくつか紹介します。

ICMP死活監視

これは非常に一般的な監視です。
ノードに対してPingを送信、応答があることや応答時間を確認するだけです。

この監視で確認できることはノードが動作しているか程度ですが、
ノード側での設定変更もなく、Zabbixサーバー側での設定も非常に簡単です。
一般的には、ICMP死活監視+下記の監視方式でノードを監視することが多いです。

Windowsの場合、ファイアウォールのデフォルト設定でICMPをブロックしていることがあります。
その場合、ICMP監視を行うにはノード側で設定変更が必要です。

Zabbixエージェント監視

Zabbixエージェントと呼ばれるツールをノードにインストールすることで、詳細な監視を実現する方法です。
主にサーバーの監視で使用されます。

この監視方法のメリットは、何よりも詳細な情報が得られるという点です。
CPU使用率、メモリ使用量、ディスクIO、プロセスの状態など、細かい情報を取得できます。

一方で、デメリットとしてはノードにZabbixエージェントをインストール、設定する必要があるという点です。
実際の運用ではグローバルインターネットに接続できない環境で運用されているサーバーも多く、
別端末でパッケージを準備した後にファイルを転送、インストール、設定など手間のかかる作業が発生するケースが非常に多いです。

SNMP監視

SNMP（Simple Network Management Protocol）を利用して、情報を取得する監視方式です。
主にネットワーク機器の監視で使用されます。

この監視方法のメリットは、様々な機器で動作するという点です。
LinuxやWindowsサーバーなどはZabbixエージェントをインストールすることができますが、スイッチやファイアウォールなどはZabbixエージェントをインストールすることができません。
そういった機器にはSNMP機能が搭載されていることが多く、エージェントの代わりにSNMPで監視を行うことが一般的です。

一方で、デメリットとしては詳細な情報の取得が難しいという点です。
例えばサーバーをSNMPで監視する場合、プロセスやサービスの監視の実現は難しいです。
SNMPはMIB（Management Information Base） と呼ばれるデータベースのようなものを用いて情報を管理・提供します。
MIBについては詳しく後述しますが、一般的にMIBにはプロセスごとの詳細な状態は含まれていないことが多いです。
また、設定が複雑であることもデメリットとして挙げられます。
販売されているスイッチやファイアウォール等では、拡張MIBと呼ばれるMIBファイルを使用することが多いです。
この拡張MIBはメーカーごとや機器ごとに定義されており、環境内で使用する全ての機器のMIBファイルを収集、設定する必要があり、非常に手間のかかる作業です。

MIBについて

まず、SNMPはノードから情報を取得する際に「どの情報を取得するか」をOID（Object Identifier） という識別子で指定します。
MIBは、このOIDと取得可能なデータの対応表と思ってください。

例えば、「SNMPを使ってCPU使用率を取得したい」と思った場合、MIBを参照することで 「CPU使用率に対応するOID」 を特定できます。
このOIDをノードにリクエストすることで、ノードからCPU使用率のデータが返ってくる、のようなイメージです。

ちなみに、OIDはツリー構造で構成されています。
例えばCPU使用率のOIDが1.3.6.1.2.1.25.3.3.1.2.1として、以下のようなツリー構造を持ちます。

1  - iso（国際標準化機構）
 ├── 3  - org（組織単位）
 │   ├── 6  - dod（国防総省）
 │   │   ├── 1  - internet（インターネット関連）
 │   │   │   ├── 2  - mgmt（管理情報）
 │   │   │   │   ├── 1  - mib-2（標準MIB-2）
 │   │   │   │   │   ├── 25  - host（ホスト情報）
 │   │   │   │   │   │   ├── 3  - hrDevice（デバイス情報）
 │   │   │   │   │   │   │   ├── 3  - hrProcessorTable（CPU情報）
 │   │   │   │   │   │   │   │   ├── 1  - hrProcessorEntry（CPUエントリ）
 │   │   │   │   │   │   │   │   │   ├── 2  - hrProcessorLoad（CPU使用率）
 │   │   │   │   │   │   │   │   │   │   ├── 1  - （CPUの1番目のエントリ）

全く覚えなくていい知識ですが、ツリー構造であることを把握しておくとMIBファイルが読みやすくなります。
（まぁMIBファイルを読む機会なんてあまりないですが）

上記補足に、標準MIBというキーワードが出てきました。
これはRFCで定義されている、業界標準の規格です。
どのメーカーの機器であっても標準MIBで定義されている情報は同じOIDで管理されます。

ですが、標準MIBで定義されている情報は充分であるとは言い切れません。
そこで、メーカーが独自に定義したOIDが存在します。
これを管理するMIBを拡張MIBと呼びます。

拡張MIBを使用することで、標準MIBで定義されている以上の詳細な情報を取得、管理することが可能なのです。

SNMPTrap監視

SNMP監視と混同されることがありますが、違う監視方式です。
SNMPがZabbixサーバーからノードに対して情報を取得するのに対し、SNMPTrapはノードからZabbixサーバーへ情報を通知します。

この監視方法のメリットは、リアルタイム性に優れているという点です。
SNMP監視では、一定間隔（例えば30秒間隔）で情報をリクエストします。
これでは、最悪の場合障害発生以降30秒間は障害を検知できないのです。
SNMPTrapは障害（厳密にはTrap発報イベント）発生時、即座にZabbixサーバーへTrapを送出します。
つまり即座にZabbixサーバーで障害の検知が可能なのです。

この監視方法のデメリットは、設定が複雑であることです。
例えばネットワーク機器には、様々なTrap発報イベントが定義されています。
全てのイベントでTrapを送出する設定にすれば、機器側の設定は簡単かもしれません。
ですが「どのイベントを受信した場合にアラートを発生させるか」をZabbixサーバーで定義しておく必要があります。
1000個のイベント（もちろんもっと多い場合もあります）の中から、どのイベントでアラートを発生させるのか、どのイベントではアラートを発生させないのかを決定するのは簡単ではありません。

WindowsServerの場合、どのイベントをTrapで送出するかを一つ一つ設定する必要があります。
SNMPTrapを使用した監視を実現するのは現実的ではありません。

JMX監視

JMX（Java Management Extensions）は、Javaアプリケーションのパフォーマンスやリソースを監視・管理するための仕組みです。
Zabbixでは、JMX監視機能を使うことでJavaアプリケーションの内部状態を取得し、監視することができます。

この監視方法のメリットは、Javaアプリケーションに特化しているという点です。
スレッド数やガベージコレクションなどJavaアプリケーション特有の監視ができます。

一方で、デメリットとしてはJavaアプリの設定変更が必要という点です。
JMXはリモート接続を許可する必要があるため、不適切な設定の場合外部からの攻撃リスクがあります。
そのためJMXで接続を許可するIPアドレスの制限や、認証設定などを行う必要があります。
また、ZabbixサーバーにZabbix Java Gatewayをインストールする必要もあります。
Zabbixサーバー単体ではJMX監視を行う機能が不足しており、別途コンポーネントをインストールする必要があります。

IPMI監視

IPMI（Intelligent Platform Management Interface）は、サーバーのハードウェアを監視・管理するための標準インターフェースです。
OSとは別でサーバーの物理面を管理する専用の仕組みが存在し、そこから情報を取得するイメージです。
（iDRACやiLOを使用したことがある方はイメージがつきやすいかと思います）
また、リモートで電源の管理を行うこともできます。

この監視方法のメリットは、OSの状態に依存せずハードウェアの監視が行えるということです。
仮にOSがダウンしていても、ハードウェア情報を取得することができます。
これはOSダウンの原因がハードウェアによるものか、ソフトウェアによるものかの切り分けなどに役立ちます。

一方で、デメリットとしてはIPMI対応のハードウェアが必要であるということです。
小規模環境用のサーバーはIPMIに対応していないことが多いです。
iDRACやiLOなどの管理用コンポーネントをオプションで購入しないとIPMI監視が実現できないケースもあるため、IPMI監視を行う場合は監視対象サーバーがIPMIに対応しているかを確認する必要があります。

昨今広く利用されているような仮想基盤での運用を行っている場合、1台の仮想マシンがダウンしたとしても原因の特定につながることは少ないです。
あくまでこの監視方法はハードウェアの監視であると考えてください。

補足：監視方式について

上記で挙げた以外に、ポート監視などの監視方式もあります。
※厳密には監視方式ではなく監視アイテムに近い

ポート監視とは、任意のポートが正常に応答するかを監視するものだと思ってください。
例としてTCP/80、TCP/443でリッスンするApache Webサーバーがある場合を説明します。

このサーバーはもちろん、80番ポートと443番ポートでリッスンしている必要があります。
そのため、Zabbixサーバーから定期的に80番ポート、443番ポートに対して通信を行い、想定通りの応答が返ってくるかを監視します。

聡い方はお気づきになったかもしれませんが、このシナリオ、Zabbixエージェント監視でプロセス監視を行う場合と似ています。
80番、443番ポートがリッスンしている = Apacheが動作している
と考えればわかりやすいと思います。

じゃあApacheを監視するだけでいいんじゃないの？と思った方もいるかもしれません。
ですが、ファイアウォールで誤って80番、443番ポートへの通信がブロックされた場合はどうでしょう。
Apacheは動作しているのに、80番、443番ポートへの通信ができなくなっています。

その逆も然りで、Apacheの設定ミスで想定と違う応答を返してしまうかもしれません。
そのため、完璧な監視を実現するには複数の方式を用いて、ノードを監視する必要があります。

監視の方向について

Zabbixで機器を監視する場合、監視の方向を理解することが非常に重要です。
監視の方向には以下の2パターンがあります。

Zabbixサーバーからノードに対しての通信を行う
ノードからZabbixサーバーに対しての通信を行う

Pingでの死活監視やポート監視などはわかりやすいですね。
このような監視方式はZabbixサーバーからノードに対して通信を行います。

では、ノードからZabbixサーバーに対して通信を行う監視方式は何でしょうか。
SNMPTrapなどがいい例ですね。
また、上記で解説していませんがアクティブモードのZabbixエージェントもこの通信方向です。
アクティブモードを使用することでZabbixエージェントからZabbixサーバーに能動的に情報をプッシュすることができ、リアルタイム性が確保できます。
（ログ監視等に使われます）

通信方向をしっかりと理解しておくことで、Zabbixで監視を行う際のトラブルシューティングに非常に役立ちます。
しっかりと理解しておきましょう。

まとめ

監視の方式や通信方向について理解いただけましたでしょうか。
Zabbixを用いて監視を行う際には、

どんな方法で監視しているか
その方法はどんなものか
を理解することが非常に重要です。

機器の情報が取得できなくなった場合、その原因が障害なのか。それとも監視設定が原因なのか。
その点を見極めることで、障害発生時の対応がよりスムーズになります。

次回は実際にZabbixをインストールし、監視環境を構築する手順を説明します。