2.1 Zabbixアーキテクチャ概要 ​

Zabbixの全体アーキテクチャと各コンポーネントの役割

Zabbixを導入するとき、最初に決めるのは「どの部品を、どこに置くか」です。サーバー、エージェント、プロキシ、Webインターフェース、データベースという部品の役割を知らないまま構築を始めると、通信がつながらない、負荷が偏るといった問題に後から悩まされます。

この章では、Zabbixを構成する五つのコンポーネントについて、それぞれが何を担当し、互いにどう通信し、どんな場面で使い分けるのかを説明します。設定ファイルの細かな値は公式ドキュメントに任せ、ここでは構成を考えるための設計の視点を中心にまとめます。

Zabbixアーキテクチャ概要 ​

Zabbixは、複数のコンポーネントが分担して動く分散型の監視システムです。ひとつの巨大なプログラムがすべてを行うのではなく、データを受け取って判断する部分、データを集める部分、画面を表示する部分、データを保存する部分が、それぞれ独立して動作します。

この分け方には、設計上の利点があります。まず、必要に応じて部品を増やしたり、別のマシンに移したりできるため、小規模な環境から大規模な環境まで同じ製品で対応できます。次に、役割が分かれているので、どこかで問題が起きたときに原因を切り分けやすくなります。たとえば、画面が重い場合はWebインターフェースやデータベースを疑い、データが届かない場合はエージェントやネットワークを疑う、という具合です。

基本アーキテクチャの特徴 ​

分散型であることは、地理的に離れた拠点を監視する場合に特に役立ちます。本社に置いたサーバーが、各拠点のプロキシを通してデータを集める構成にすれば、拠点の機器と直接やり取りする必要がなくなります。

また、モジュールとして組み合わせる構成のため、小さく始めて、監視対象が増えたらプロキシを足す、データベースを別のサーバーに分ける、といった拡張がしやすくなっています。最小構成では、ひとつのマシンにサーバー、Web、データベースをすべて載せて動かすことも可能です。

主要コンポーネント ​

Zabbixの中心にあるのは、監視データを受け取って判定するZabbix Serverです。その周りに、データを集めて送るZabbix Agentと、中継役のZabbix Proxy、画面を表示するWeb Interface、そして全データの保存先となるDatabaseがあります。なお、監視対象側で動くエージェントやプロキシは必要に応じて使うもので、最小構成ではサーバー、Web、データベースの三つがあれば動作します。

次の図は、各部品の関係を表したものです。矢印はデータが流れる向きの目安で、実際の接続の開始側は、後述するパッシブとアクティブの違いによって変わります。

図の見方としては、Webインターフェースもサーバーも、データベースを通して同じ情報を共有しているところが重要です。画面から変更した設定は、データベースに保存され、サーバーがそれを読み込んで動作に反映します。つまり、WebインターフェースとZabbix Serverが直接通信するわけではなく、データベースが両者の橋渡しをしています。

Zabbix Serverの役割と機能 ​

中央制御システムとしての役割 ​

Zabbix Serverは、監視システム全体の中枢です。監視対象に問い合わせてデータを集めたり、エージェントやプロキシから送られてくるデータを受け取ったりして、それをデータベースに記録します。さらに、受け取った値をトリガーの条件と照らし合わせ、問題があれば、アクションとして通知やコマンド実行を行います。

サーバーには、設定を管理する役割もあります。データベースに保存されたホストやアイテムの設定を読み込んでメモリに持ち、監視の予定を組み立てます。設定を変更したときは、一定の間隔でデータベースから最新の内容を取り込むため、画面で変更してから反映されるまでには少し時間がかかる場合があります。

プロセス構成 ​

Zabbix Serverは、ひとつのプログラムとして起動しますが、内部では、役割ごとに複数のプロセスが並行して動作します。データの収集を担当するプロセスとして、監視対象に問い合わせに行うポーラー、エージェントやプロキシから送られたデータを受け付けるトラッパー、ICMPで死活を確認するピンガーなどがあります。

収集した値を処理する側には、値の前処理を行うプロセスや、メモリ上の値をデータベースに書き込む同期用のプロセスがあります。通知を送るアラーターや、問題が続いたときの段階的な通知を管理するエスカレーターも、それぞれ専用のプロセスです。こうして役割ごとにプロセスが分かれているので、特定の処理が詰まっても、それ以外の処理への影響を抑えられます。

設定と性能の考え方 ​

サーバーの設定ファイルでは、各プロセスの数や、メモリ上のキャッシュの大きさを調整できます。ポーラーの数を増やすと、同時に取得できる項目が増えますが、そのぶんCPUやデータベースへの負荷も上がります。

基本的な考え方としては、最初は既定値で動かして、サーバー自身の内部メトリクスを監視し、プロセスの忙しさやキャッシュの空き容量を確認してから、必要な部分だけを増やします。あらかじめ大きな値を設定しておくのではなく、実測に基づいて調整するのが安全です。具体的な項目名や推奨値は、公式ドキュメントの「Daemon configuration」と「Performance tuning」を参照してください。

Zabbix Agentの仕組み ​

軽量監視エージェントとしての特徴 ​

Zabbix Agentは、監視対象のサーバーに導入して、そのマシン内部の情報を取得して返す小さなプログラムです。外から見えないCPUやメモリ、ディスク、プロセスの状態を、OSに問い合わせて取得できます。消費するリソースが少なく、常時動かしても負担になりにくいように作られています。

エージェントには、従来型のZabbix agentと、新しい設計のZabbix agent 2があります。agent 2は、Go言語で書かれていて、複数のチェックを並列に実行でき、プラグインで機能を拡張できる点が特徴です。公式は、新規の導入ではagent 2を選択肢に入れることを案内しています。基本的な役割は同じですが、設定ファイルの名前や一部の項目が異なるため、利用するバージョンのドキュメントで確認してください。

データ収集モード ​

エージェントがサーバーとやり取りする方法には、二つのモードがあります。ひとつは、サーバーが「いまの値を教えて」と問い合わせ、エージェントが答えるパッシブチェックです。エージェントは、既定でTCPの10050番ポートで待ち受けており、サーバーからこのポートへ接続できる必要があります。設定が単純で分かりやすく、社内のネットワークではこの方式がよく使われます。

もうひとつは、エージェントのほうからサーバーへデータを送るアクティブチェックです。エージェントは、まずサーバーに「自分が実施すべきチェックの一覧」を問い合わせ、その内容にしたがって値を集めて送信します。サーバーの10051番ポートへ接続できればよいので、エージェントがNATの内側にある場合や、サーバーからエージェントへの接続を許可できない場合に向いています。また、ログファイルの監視は、アクティブチェックで行います。

どちらを使うかは、アイテムごとに選べます。ネットワークの方針が許せば、パッシブを基本にして、ログ監視や外向きの接続しか許されない環境にだけアクティブを使う、という構成が分かりやすい進め方です。

エージェントの設定 ​

エージェントの設定で最低限必要なのは、接続を許可するサーバーのアドレス、アクティブチェックの接続先、そして自身のホスト名です。パッシブチェックでは、設定した許可リストにないサーバーからの問い合わせを拒否します。アクティブチェックでは、エージェントが名乗るホスト名とZabbix上のホスト名が一致している必要があります。

Server=192.168.1.10
ServerActive=192.168.1.10
Hostname=web-server-01

これは、設定ファイルの最小例です。ほかにも、ログの出力先やタイムアウトなどがありますが、まずはこの三つが正しいかを確認するのが、接続できない問題を調べるときの第一歩です。値の細かな意味は、公式ドキュメントのエージェントの設定の項目にまとまっています。

内蔵監視項目 ​

エージェントには、OSの情報を取得する内蔵のアイテムキーが多数あります。CPUの使用率や負荷、メモリの空き、ファイルシステムの容量とinode（ファイルを管理する領域）の空き、ネットワークインターフェースの送受信量、ポートの待ち受け状態、プロセスの数などが代表的です。

これらは標準テンプレートに組み込まれているので、通常はキーを一つずつ覚える必要はありません。独自に取得したい値がある場合は、ユーザーパラメータという仕組みで、任意のコマンドの結果をアイテムとして取得できます。ただし、外部のコマンドを実行する機能は、設定を誤ると安全面のリスクとなるため、慎重に扱ってください。

Zabbix Proxyの活用場面 ​

分散監視の中間サーバー ​

Zabbix Proxyは、サーバーの代わりに監視対象からデータを集め、まとめてサーバーに送る中継サーバーです。プロキシ自身が監視の予定を持ち、データを収集して一時的に保管します。サーバーに比べると機能が絞られており、トリガーの評価や通知は行いません。それらは、サーバー側の仕事です。

プロキシを置く最大の理由は、遠隔地の監視を安定させることです。拠点とのネットワークが細い、あるいは不安定な場合でも、プロキシが拠点内でデータを集めておけば、通信が途切れても、データを失わずに保持できます。回線が復旧したら、溜めたデータをサーバーへ送ります。

プロキシの利点 ​

プロキシの利点は、四つの観点で整理できます。ひとつめは、ネットワークの効率です。拠点の多数の機器とサーバーが直接やり取りするのではなく、プロキシがまとめて送るので、広域の回線を節約できます。

ふたつめは、可用性の向上です。サーバーとの通信が切れても、プロキシは収集を続けるので、監視の空白が生まれにくくなります。みっつめは、セキュリティ面で、DMZや拠点のネットワークの中にプロキシを置くことで、サーバーが各機器へ直接接続する必要がなくなり、通信の経路を絞れます。よっつめは、負荷の分散で、データ収集の仕事をプロキシに任せることで、サーバーの負担を減らせます。

プロキシの動作モード ​

プロキシにも、エージェントと同様に二つのモードがあります。アクティブモードでは、プロキシからサーバーへ接続してデータを送り、設定も取りに行きます。プロキシからサーバーへの通信だけを許可すればよいので、拠点側のファイアウォールの制約が厳しい場合に適しています。

パッシブモードでは、サーバーからプロキシへ接続して、データを取りに行きます。サーバーからプロキシへの通信を許可できる構成であれば、こちらも利用できます。どちらのモードにするかは、プロキシ側の設定とサーバー上のプロキシの登録内容に合わせて決めます。

プロキシ設定の考え方 ​

プロキシは、独自のデータベースを持ちます。軽量な利用ではSQLiteを使えるため、プロキシのためだけにデータベースサーバーを用意する必要はありません。ただし、監視する数が多い場合は、MySQLやPostgreSQLを使うほうが適しています。

設定では、接続先のサーバー、モード、ホスト名を決めます。また、サーバーと通信できない間にデータを保持する期間も設定できます。拠点との回線が数時間から数日止まる可能性がある場合は、その間に溜まるデータ量を見積もって、保持の期間とディスク容量を決めておくと安心です。

プロキシ配置パターン ​

代表的な配置の考え方を紹介します。ひとつは、支社やデータセンターごとにプロキシを置くパターンで、拠点内の機器はそのプロキシが監視し、データだけを本社のサーバーに送ります。もうひとつは、DMZや隔離されたネットワークに置くパターンで、内部のサーバーから外部に直接つなげない対象を、プロキシが代わりに監視します。

さらに規模が大きい場合は、地域ごとに複数のプロキシを並べ、サーバーはプロキシ群からの収集結果を集約します。なお、新しいバージョンでは、複数のプロキシをグループとして扱い、障害時に自動で振り替えられる機能も提供されています。どの機能が使えるかは、利用するバージョンの公式ドキュメントで確認してください。

Webインターフェースの機能 ​

管理・可視化プラットフォーム ​

Zabbixのフロントエンドは、PHPで作られたWebアプリケーションです。ブラウザから、監視の状況を見るだけでなく、ホストやアイテム、トリガー、アクション、ユーザーなどの設定も行います。すべての操作を画面から行えるため、コマンドラインに不慣れな人でも運用できます。

機能は、大きく三つに分かれます。監視のカテゴリでは、ダッシュボードや現在の問題、最新のデータ、グラフ、マップを見られます。データ収集のカテゴリでは、ホストやテンプレートの設定を行い、アラートのカテゴリでは、アクションやメディアタイプの設定を行います。また、レポートのカテゴリでは、稼働率や監査ログ、定期レポートを扱います。

アーキテクチャ特徴 ​

フロントエンドは、Apache HTTP ServerかNginxといったWebサーバー上で動作します。PHPの実行環境が必要で、必要なバージョンや拡張モジュールは、Zabbixのバージョンごとに異なります。動かすサーバーの要件は、第3部のシステム要件の章で整理します。

認証には、Zabbix内部のユーザー管理に加えて、LDAPやSAMLなどの外部認証が使えます。また、画面の操作と同じことをプログラムから行えるAPIもフロントエンドが提供しています。API経由の自動化については、第7部で説明します。

ユーザーインターフェース ​

画面の基本構成は、左側のメニューと、右側のメインの表示領域です。メニューから、監視、データ収集、アラート、管理といった機能の分類を選んで、各画面へ移動します。ユーザーごとに、表示言語やテーマ、タイムゾーンを設定でき、日本語の表示にも対応しています。

多言語対応については、公式のフロントエンドは多くの言語に翻訳されています。ただし、翻訳の完成度は言語ごとに異なるため、見慣れない用語は英語の画面と見比べながら確認すると、公式ドキュメントとも対応を取りやすくなります。

データベースの役割と選択肢 ​

データ保存・管理システム ​

データベースは、Zabbixのすべての情報を保存する土台です。ホストやアイテム、トリガーなどの設定、ユーザーと権限の情報、そして収集した値の履歴が保存されます。サーバーとフロントエンドの両方が、このデータベースにアクセスします。

保存するデータの種類は、設定情報と監視データに分けて考えると分かりやすくなります。設定情報は量が少なく、更新も少ないですが、失うと監視を再構築することになるので、バックアップが欠かせません。監視データは、履歴とトレンドの二種類があります。履歴は、集めた値そのものを細かく記録したもので、量が多いぶん保存期間を短めにするのが一般的です。トレンドは、一時間ごとの最小値、最大値、平均値などにまとめたもので、長い期間の傾向を見るために使います。

サポートデータベース ​

Zabbixサーバーが利用できるデータベースは、MySQL（およびMariaDB）とPostgreSQLが中心です。MySQLは広く使われていて、導入の情報も豊富です。PostgreSQLは、拡張機能が充実しており、TimescaleDBという時系列データ向けの拡張と組み合わせる構成も公式にサポートされています。

プロキシでは、SQLiteも使えますが、サーバーのデータベースとしては使えません。そのほかのデータベースへの対応は、バージョンによって変わっており、将来のバージョンで対応が終了する場合もあります。必要なバージョンは、利用するZabbixのバージョンのシステム要件のページで必ず確認してください。

データベース設計とパフォーマンス ​

データベースは、Zabbixのボトルネックになりやすい部分です。履歴を書き込む処理が大量に発生するため、ディスクの性能やメモリの量が全体の性能に直結します。そのため、データベースは専用のサーバーに分けて、SSDなどの高速なストレージを使うのが定石です。

保持期間の設計も重要です。履歴を長く残すほどデータベースは大きくなり、検索や保守に時間がかかります。目安としては、細かな値の履歴は数日から数週間、トレンドは一年程度から数年というように、用途に応じて分けて保持します。また、ハウスキーパーというサーバーの機能が、期限切れのデータを定期的に削除します。非常に大きな環境では、テーブルを期間で分割するパーティショニングを使って、削除の負荷を抑えるやり方もあります。

通信プロトコルとセキュリティ ​

Zabbix内部通信 ​

Zabbixの各部品は、決まったポートで通信します。ファイアウォールを設定するときは、どの方向の通信を許可するかを、あらかじめ整理しておく必要があります。

この表でポイントになるのは、通信の向きです。パッシブでは、サーバーからエージェントへ向けて接続し、アクティブでは、エージェントからサーバーへ向けて接続します。ファイアウォールでは、接続を開始する側から見て許可する必要があります。

暗号化通信 ​

標準の設定では、サーバーとエージェントの間の通信は暗号化されません。社内の閉じたネットワークだけで使う場合でも、機密性が求められる環境や、インターネットを経由する通信では、暗号化を有効にしてください。

Zabbixでは、TLSを使った暗号化に対応しています。方式は二つあります。事前共有鍵（PSK）は、双方が同じ秘密の鍵を持つ方法で、証明書の準備が不要なため、導入が簡単です。証明書方式は、認証局で発行した証明書を使うもので、多数のホストを管理する大規模な環境や、既存の証明書の運用基盤がある環境に向いています。どちらも、エージェントとサーバーの双方で、設定を合わせる必要があります。

セキュリティベストプラクティス ​

ネットワークの面では、必要なポートだけを許可し、監視用のネットワークを他と分離する、といった基本が大切です。リモートの拠点とは、VPNなどの暗号化された経路で結ぶとよいでしょう。

認証と認可の面では、初期のAdminアカウントのパスワードをすぐ変更し、利用者には必要最小限の権限だけを与えます。LDAPやSAMLと連携すれば、組織のアカウント管理に統合でき、多要素認証の仕組みも活用しやすくなります。また、データベースの接続情報を書いた設定ファイルは、権限を絞って保護します。詳しい運用方法は、第8部のセキュリティの章で扱います。

参考リンク

• Zabbixアーキテクチャ概要
• Zabbixコンポーネント

← 前へ: 1.3 基本概念と用語 | 次へ: 2.2 データフローとプロセス →