3.2 インストール方法
環境に応じたZabbixの導入手順とベストプラクティス
Zabbixの導入方法は、ひとつではありません。公式のパッケージをOSのパッケージ管理で入れる方法、ソースコードからコンパイルする方法、コンテナで動かす方法、クラウド上に構築する方法があり、それぞれ、手間のかかり方や、後の運用の楽さが違います。どれが正解というものではなく、環境と運用体制に合うものを選ぶことが大切です。
この章では、四つの方法の特徴を比べたうえで、もっとも標準的なパッケージによる導入の流れを、手順の意図とあわせて説明します。そのあと、ソースコンパイル、Docker、クラウドの考え方、そしてインストール後の動作確認を扱います。コマンドの細かな書き方は、バージョンやOSで変わるため、利用するバージョンの公式のインストール手順を併せて参照してください。前の章で説明したシステム要件の確認が済んでいる前提で進めます。
インストール方法概要
どの方法を選んでも、最終的に動かす部品は同じです。Zabbixサーバー、フロントエンド、データベース、そして必要ならエージェントです。違いは、それをどのように導入し、更新するかにあります。
選ぶときは、まず、運用の継続性を考えます。バージョンアップは、導入の後にも何度も発生する作業です。パッケージ管理の仕組みに乗せておけば、更新を、コマンドで行えます。一方、ソースから入れると、更新のたびに、コンパイルと入れ替えの作業が必要です。
インストール方法の比較
四つの方法を、観点別に整理すると、次のとおりです。
| 方法 | 手間 | 柔軟性 | 更新のしやすさ | 向いている場面 |
|---|---|---|---|---|
| パッケージ | 少ない | 標準的 | 高い | 本番環境や標準的な構成 |
| ソースコンパイル | 多い | 高い | 低い | 特殊なビルドオプションが必要な場合 |
| Docker | 中程度 | 中程度 | 高い | 検証環境やコンテナ基盤での運用 |
| クラウド | 構成による | 高い | 構成による | クラウド上に基盤を置く場合 |
迷ったときの目安は、まずパッケージによる導入を選ぶことです。公式がOSごとに用意しているため、依存するソフトウェアの導入や、サービスの登録まで、まとめて行われます。ソースコンパイルは、特別な理由がない限り、選ぶ必要はありません。
パッケージによるインストール
パッケージによる導入は、公式のリポジトリを追加して、OSのパッケージ管理（dnfやapt）で入れる方法です。流れは、リポジトリの追加、データベースの準備、パッケージの導入、スキーマの投入、設定の編集、サービスの起動という順序になります。
事前準備
最初に、Zabbixの公式リポジトリを、OSに追加します。リポジトリを追加すると、OS標準の配布よりも新しい、公式のパッケージを取得できるようになります。追加の方法は、公式のダウンロードのページで、バージョンとOS、データベース、Webサーバーを選ぶと、手順が表示されます。この画面を使えば、自分の環境に合った正確なコマンドを得られるため、他の記事のコマンドをそのまま写すより確実です。
Red Hat系では、リポジトリの設定を含むリリースパッケージをrpmで導入し、キャッシュを更新します。Debian系では、リリースパッケージをdpkgで導入し、aptの情報を更新します。ここで注意したいのは、OS標準のリポジトリにもZabbixのパッケージが含まれている場合があることです。古い版が入ってしまわないよう、公式のリポジトリを優先する設定が、手順に含まれています。
データベースの準備
データベースは、Zabbixとは別に、事前に導入しておきます。MySQL系かPostgreSQLを選び、Zabbix用のデータベースと、専用のユーザーを作ります。MySQLの場合は、文字コードをutf8mb4、照合順序をutf8mb4_binで作成する点が、公式の手順に定められています。
CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'zabbix'@'localhost' IDENTIFIED BY '強いパスワード';
GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost';この三行は、データベースの作成、ユーザーの作成、権限の付与です。パスワードは、推測されにくいものにしてください。なお、MySQL 8系でスキーマの投入を行う間は、バイナリログが有効だと、関数の作成権限の設定が必要になる場合があります。その場合の注意は、公式の手順に記載されています。PostgreSQLでは、createuserとcreatedbのコマンドで、同様に、ユーザーとデータベースを作ります。
Zabbixサーバーのインストール
データベースが用意できたら、サーバーとフロントエンド、エージェントのパッケージを導入します。MySQLを使うか、PostgreSQLを使うかで、サーバーとフロントエンドのパッケージの名前が変わります。また、Apacheを使うかNginxを使うかによって、Webサーバー用の設定のパッケージも変わります。Apacheの場合は、zabbix-apache-confというパッケージが、設定ファイルを提供します。
パッケージの導入が終わったら、データベースにスキーマ（テーブルの定義と初期データ）を投入します。これは、パッケージに同梱されているSQLファイルを、作成したデータベースに流し込む作業です。
zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbixこの作業は、初回の導入で一度だけ行います。二度目を実行すると、データを壊すおそれがあるため、注意が必要です。投入が終わったら、スキーマの投入のために一時的に変更した設定があれば、元に戻します。
設定ファイルの編集
Zabbixサーバーの設定ファイルは、/etc/zabbix/zabbix_server.confです。最低限、必要なのは、データベースへの接続情報で、DBPasswordの項目に、先ほど決めたパスワードを書きます。ほかの項目は、初期値のままでも動きます。
Webサーバーの設定では、PHPのタイムゾーンを、Asia/Tokyoに設定しておきます。公式パッケージの設定ファイルには、このタイムゾーンの項目がコメントアウトされた状態で入っているので、環境に合わせて有効にします。このタイムゾーンは、フロントエンドの初期設定の画面でも、変更が可能です。
設定ファイルには、データベースのパスワードが平文で入るため、読み取り権限を、サービスの実行ユーザーだけに限ります。パッケージで入れた場合は、通常、適切な権限が設定されますが、手で編集したあとは、権限が変わっていないかを確認してください。
サービスの起動と自動開始設定
最後に、Zabbixサーバー、エージェント、Webサーバーを起動し、OSの起動時に自動で立ち上がるように設定します。Systemdを使う環境では、systemctlのenableと、startの組み合わせで行います。
起動したら、すぐに状態を確認します。サービスがactiveになっていれば、ひとまず起動は成功です。失敗している場合は、ログファイルに原因が出ていることが多いため、次の節で述べる確認の手順に従って、確かめます。
ソースからのコンパイルインストール
ソースコードからの導入は、公式のパッケージが提供されていないOSで動かしたい場合や、特定の機能を有効にしたビルドが必要な場合に選びます。自由度は高い反面、手間と責任が大きくなるため、慎重に選択してください。
開発環境の準備
まず、コンパイルのために、コンパイラや、各種の開発用のライブラリを導入します。データベースのクライアント、OpenSSL、SNMP、cURL、XMLの処理、PCREなどのライブラリがあり、有効にしたい機能に応じて、必要なものが変わります。必要な開発用のパッケージの名前は、OSごとに異なるため、公式の手順で、使うOSのものを確認してください。
また、Zabbixを動かす専用のユーザーとグループを作ります。rootでは動かさず、権限を限定した専用のユーザーで動かすことが、セキュリティ上の基本です。
ソースコードの取得とコンパイル
ソースコードは、公式サイトのダウンロードのページから、配布されているアーカイブを取得します。展開したら、configureスクリプトで、ビルドの設定を行います。このとき、サーバーとエージェントのどちらを作るか、どのデータベースを使うか、SSLやSNMPなどの機能を有効にするか、をオプションで指定します。
./configure --enable-server --enable-agent --with-mysql --with-openssl --with-net-snmp
make install指定したオプションに対応するライブラリが不足していると、configureの段階でエラーになります。エラーのメッセージが、不足しているライブラリを示してくれるので、それを追加して、やり直します。
設定ファイルとサービスの設定
コンパイルしたものは、パッケージとは違い、設定ファイルの置き場所や、ログの出力先、systemdへの登録などを、自分で整える必要があります。ログ用とPIDファイル用のディレクトリを作って、専用ユーザーに権限を与え、設定ファイルをコピーします。さらに、サービスとして管理するために、systemdのユニットファイルを自作します。
この作業は、パッケージ導入では自動的に行われる部分です。ソースからの導入が、手間のかかる選択である理由のひとつは、ここにあります。さらに、バージョンアップのときも、コンパイルから同じ作業を繰り返す必要があります。
Dockerによるインストール
コンテナで動かす方法は、環境の再現性が高く、検証や、コンテナ基盤での運用に向いています。Zabbixは、サーバー、Web、エージェントなどの各部品について、公式のコンテナイメージを提供しています。
Docker Composeを使用した構成
コンテナで構成するときは、部品ごとにコンテナを分けます。データベースのコンテナ、Zabbixサーバーのコンテナ、Webインターフェースのコンテナ、必要ならエージェントのコンテナです。これらを、Docker Composeという、複数のコンテナをまとめて管理する仕組みで定義し、一度に起動します。
構成の定義には、公式がGitHubで公開しているZabbixのDockerのリポジトリに、Composeのサンプルのファイルが用意されています。自分で一から書くより、このサンプルを使うほうが、環境変数の名前などを間違えにくく、確実です。環境変数で、データベースの接続先とパスワード、PHPのタイムゾーンなどを指定します。
コンテナ運用で気をつけるのは、データの永続化です。データベースのデータを、コンテナの外のボリュームに保存しないと、コンテナを作り直したときに、データが消えます。また、パスワードを、定義ファイルに直接書かず、シークレットなどの仕組みで渡すのが、望ましい運用です。
Kubernetesでのデプロイ
Kubernetes上で動かす場合は、公式がHelmチャートを提供しており、これを使うのが一般的です。Helmは、Kubernetes向けのパッケージ管理の仕組みで、チャートに値を渡すだけで、必要なリソースをまとめて作成します。
Kubernetesでは、データベースの運用や、永続化のためのストレージ、外部に公開するための設定など、考える点が増えます。そのため、すでにKubernetesの運用の経験があるチームに向いた方法で、初めての導入には、まずパッケージかDocker Composeで試してから、検討するとよいでしょう。
クラウド環境でのデプロイ
クラウドでの導入は、仮想マシンを作り、そこにパッケージで導入する形が基本です。AWSのEC2、Google CloudのCompute Engine、AzureのVirtual Machinesのいずれでも、仮想マシンのOSにLinuxを選び、この章のパッケージの手順で構築します。クラウドごとの特別な手順があるわけではなく、考えるのは、ネットワークの設計や、費用です。
AWS EC2での構築
AWSでは、EC2のインスタンスにZabbixを導入し、セキュリティグループで通信を制御します。管理画面へのHTTPSと、エージェントからの10051番のポートだけを、必要な送信元のアドレスに限って許可します。SSHの22番も、管理者のアドレスに限るのが基本です。すべてのアドレスに開放する設定は、避けてください。
データベースには、インスタンス内に入れる方法のほかに、マネージドのデータベースサービスを使う方法もあります。運用の手間を減らせる反面、対応するバージョンや設定の制約を、事前に公式の要件で確認する必要があります。
Google Cloudでのデプロイ
Google Cloudでは、Compute Engineのインスタンスを作り、ファイアウォールのルールで、必要なポートを許可します。インスタンスの作成は、コンソールの画面でも、gcloudコマンドでも行えます。初めてであれば、画面の操作で、設定の項目を確認しながら進めるほうが、全体を理解しやすいでしょう。
ディスクの種類は、SSDを選び、容量は、前の章で見積もった値に合わせます。監視対象が増えるにつれて、ディスクが必要になるため、後から拡張できる設定にしておくと安心です。
Microsoft Azureでのデプロイ
Azureでも、仮想マシンを作成し、ネットワークセキュリティグループで通信を制御する点は同じです。Azureでは、リソースグループという単位で、関連するリソースをまとめて管理できます。構築を繰り返す場合は、テンプレートなどの仕組みを使うと、再現しやすくなりますが、初めて構築するときは、ポータルの画面で、手順を確認しながら進めてください。
どのクラウドを使う場合でも、監視システムの通信が、インターネットを通る場合は、暗号化と接続元の制限を、必ず組み合わせてください。また、クラウド事業者が公開しているイメージを使う方法もありますが、公式のものかどうか、バージョンが新しいかどうかを確認してから利用しましょう。
インストール後の確認
インストールが終わったら、期待どおりに動いているかを、順に確認します。確認の順序は、プロセス、ポート、ログ、画面の順に進めると、原因を切り分けやすくなります。
動作確認手順
まず、サーバー、エージェント、Webサーバーのサービスが、起動しているかをsystemctlのstatusで確認します。次に、ポートの待ち受け状況を調べ、サーバーが10051番、エージェントが10050番、Webサーバーが80番で、待ち受けているかを確かめます。
最後に、ログファイルを確認します。サーバーのログに、データベースへの接続エラーなどが出ていないかを見ます。ログは、/var/log/zabbix/に出力されるのが一般的で、起動直後のメッセージが、問題の原因をもっとも多く伝えてくれます。
Webインターフェースへのアクセス
ブラウザから、サーバーのアドレスの/zabbixにアクセスすると、初回のセットアップのウィザードが始まります。ウィザードでは、前提条件の確認、データベースの接続情報の入力、サーバーの設定を順に進めます。この内容は、次の章で詳しく説明します。
セットアップが完了すると、ログイン画面になります。初期のアカウントは、ユーザー名がAdmin、パスワードがzabbixです。この初期のパスワードは、公開されているため、最初のログインのあとで、すぐに変更してください。
初期トラブルシューティング
よくある問題として、まず、データベースへの接続エラーがあります。この場合は、設定ファイルのデータベースの項目と、データベース側のユーザーの権限が一致しているかを確認します。手でデータベースにログインして接続できれば、設定ファイルの記述に誤りがあると判断できます。
次に、権限のエラーがあります。ログやPIDファイルの置き場所に、Zabbixの実行ユーザーが書き込めないと、起動に失敗します。ディレクトリの所有者を確認してください。
Red Hat系でSELinuxが有効な場合は、Zabbixが必要とする通信が、ブロックされることがあります。無効にするのではなく、公式が提供するSELinux用のポリシーのパッケージを導入し、必要に応じて、ブール値を設定する方法が、安全です。この場合の具体的な項目は、公式のドキュメントに記載されています。
参考リンク