Zabbixサーバーと監視対象ホストの関係とは？Zabbixにおける監視の仕組み

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

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

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

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


## 監視の種類

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

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

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

:::note warn
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にはプロセスごとの詳細な状態は含まれていないことが多いです。
また、**設定が複雑**であることもデメリットとして挙げられます。
販売されているスイッチやファイアウォール等では、<ins>拡張MIB</ins>と呼ばれるMIBファイルを使用することが多いです。
この拡張MIBはメーカーごとや機器ごとに定義されており、環境内で使用する全ての機器のMIBファイルを収集、設定する必要があり、非常に手間のかかる作業です。

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

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

:::note
ちなみに、OIDは**ツリー構造**で構成されています。
例えばCPU使用率のOIDが<ins>1.3.6.1.2.1.25.3.3.1.2.1</ins>として、以下のようなツリー構造を持ちます。
```
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を送出する設定にすれば、機器側の設定は簡単かもしれません。
ですが<ins>「どのイベントを受信した場合にアラートを発生させるか」</ins>をZabbixサーバーで定義しておく必要があります。
1000個のイベント（もちろんもっと多い場合もあります）の中から、どのイベントでアラートを発生させるのか、どのイベントではアラートを発生させないのかを決定するのは簡単ではありません。

:::note warn
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に対応しているかを確認する必要があります。

:::note warn
昨今広く利用されているような仮想基盤での運用を行っている場合、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をインストールし、監視環境を構築する手順を説明します。