3.1 システム要件と準備 ​

Zabbix導入のためのハードウェア・ソフトウェア要件

Zabbixのインストール作業そのものは、手順に沿えば数十分で終わります。ところが、あとから「ディスクが足りない」「画面が重い」「対応していないバージョンのデータベースだった」と気づくと、やり直しの手間が大きくなります。そこで、インストールに入る前に、必要な環境を見積もり、準備しておくことが大切です。

この章では、ハードウェアの考え方、ソフトウェアの対応状況、セキュリティやネットワークの準備、そして事前チェックの観点を説明します。具体的な数値やバージョンは、Zabbixのバージョンごとに更新されるため、実際の導入時には、必ず利用するバージョンの公式ドキュメントにある「Requirements」のページで最新の内容を確認してください。この章では、その数値を判断するための考え方を中心に扱います。

システム要件概要 ​

Zabbixを導入するうえで、システム要件を整理する目的は、監視を安定して続けられる環境を、過不足なく用意することです。要件を決める材料は、監視するホストの数、ひとつのホストで取得する項目の数、取得の間隔、データの保持期間、そして高可用性（止まりにくさ）の要求です。

要件の見積もりが大切な理由は、二つあります。ひとつは、監視システムは障害のときこそ動いていなければならないからです。性能が足りずに値の取りこぼしが起きたり、画面が開かなくなったりすれば、監視の目的を果たせません。もうひとつは、費用の面で、必要以上に大きなサーバーを用意すれば無駄が生まれる点です。

要件決定の重要性 ​

要件を適切に決めると、まず性能が安定します。Zabbixは、取得した値を絶えずデータベースに書き込むため、データベースの処理能力が追いつかないと、値がメモリに滞留して、最終的に監視の遅れにつながります。

次に、将来の拡張に備えられます。最初の見積もりに余裕を持たせておくと、監視対象が増えたときも、サーバーの入れ替えを急がずに済みます。さらに、運用の面でも、バックアップやメンテナンスに必要な時間や領域をあらかじめ見込めるため、保守作業の負担を軽くできます。

ハードウェア要件 ​

サーバー要件の計算方法 ​

Zabbixサーバーのハードウェア要件は、環境によって大きく変わるため、「何台以上ならこのスペック」と一律に決めることはできません。公式のドキュメントにも、規模に応じた構成例が示されていますが、これはあくまで目安という位置づけです。

実際に影響が大きいのは、一秒間に処理する値の数です。たとえば、1000個のアイテムを60秒ごとに取得すれば、一秒あたり約17個の値が発生します。この数字を、サーバー内部のメトリクスでNVPS（New Values Per Second、一秒あたりの新規の値の数）として確認でき、性能を考えるときの主要な指標になります。

ホストの数が同じでも、アイテムの数や間隔が違えば負荷はまったく変わります。そのため、ホスト数だけで判断せず、一台あたりのアイテム数と更新間隔の両方から、NVPSを見積もりましょう。

規模ごとの構成の考え方 ​

小規模な環境では、ひとつのマシンにZabbixサーバー、Webインターフェース、データベースを同居させる構成で十分なことが多くあります。学習用や、数十台程度の監視であれば、CPUとメモリがそれほど大きくない仮想マシンでも動かせます。ただし、ディスクはHDDより、SSDにしたほうが、データベースの書き込みが快適です。

中規模になると、データベースへの負荷が目立ってきます。この段階では、データベースを専用のサーバーに分けることを検討します。メモリはデータベースのキャッシュに使えるぶん多めに確保し、ストレージは書き込みの性能が高いものを選びます。ネットワークも、サーバーとデータベースの間の通信が増えるため、遅延が小さい構成が望ましいです。

大規模な環境では、ひとつのサーバーに全部を任せるのではなく、プロキシで収集の負荷を分散し、データベースも高性能な専用の構成にします。さらに、サーバーのHA（高可用性）構成や、データベースの冗長化も、計画に入れます。規模が大きいほど、構成の設計は個別の検討が必要になるため、公式の資料や、実際の負荷試験を参考に決めることになります。

容量計画の計算方法 ​

ディスクの容量は、あとから足すのが難しいことも多いので、先に見積もっておくことが重要です。公式ドキュメントには、データベースのサイズを見積もる式が示されています。

履歴の容量 ＝ アイテム数 × 一日あたりの取得回数 × 保存日数 × 約50バイト
トレンドの容量 ＝ アイテム数 × 24回 × 保存日数 × 約90バイト

履歴は取得した値ひとつごとに約50バイト、トレンドは一時間ごとに約90バイトが目安です。たとえば、10000個のアイテムを60秒ごとに取得して30日間保存すると、一日に1440回、合計で約21GBです。ここに、トレンドと、イベントなどの設定領域を足します。この値はあくまで概算で、実際はデータベースの索引などの分が加わるため、余裕を持たせて見積もりましょう。

メモリについても、同様に、サーバーのキャッシュの設定値の合計と、データベースのキャッシュ、OSが使う分を足し合わせて考えます。設定値の目安は、公式のパフォーマンスチューニングの資料に示されています。

ストレージとネットワークの考え方 ​

ストレージは、容量だけでなく、書き込みの速さ（IOPS）が重要です。Zabbixは、常に小さな書き込みを大量に行うため、容量が足りていても、ディスクの応答が遅いと、データベースの処理が詰まります。仮想環境で動かす場合は、同じ物理ディスクを他の仮想マシンと共有していないか、書き込みの性能が保証されているかも確かめてください。

ネットワークについては、帯域の広さよりも、遅延の安定が影響することがあります。Zabbixサーバーとデータベースを別のマシンに分けるときは、同じネットワークセグメントに置いて、通信の遅延を小さく保つのが基本です。遠隔地の監視は、前の章で説明したプロキシを使って、遠くの機器と直接のやり取りを減らします。

また、仮想マシンで動かすときは、CPUやメモリを他の仮想マシンと奪い合わない設定にしておくと、監視の遅れを避けられます。監視システムは、他のシステムが不調なときこそ、安定して動いていてほしい存在です。そのため、監視の基盤は、監視対象のシステムとは、できるだけ別の障害の範囲に置くのが望ましい考え方です。

ソフトウェア要件 ​

サポートオペレーティングシステム ​

Zabbixサーバーは、主にLinuxで動作します。公式のパッケージは、Red Hat系のディストリビューション（RHEL、AlmaLinux、Rocky Linuxなど）、DebianやUbuntu、SUSE系などに向けて提供されています。対応するバージョンは、リリースごとに更新され、古いOSは対象から外れていきます。

ここで大切なのは、公式パッケージが提供されているOSを選ぶことです。パッケージが提供されていれば、インストールもバージョンアップも、パッケージ管理の仕組みで行えるため、運用が楽になります。選択肢の対応状況は、公式のダウンロードのページで、OSとバージョンを選ぶと確認できます。

推奨OS設定 ​

OSの設定では、ファイルを開ける数の上限や、ネットワーク接続に関する設定、時刻の同期が重要です。特に時刻の同期は、監視データの時刻が正しくなければ、グラフやイベントの記録が信頼できなくなるため、NTPやchronyなどで、サーバーとエージェントの時刻を合わせておきます。

また、SELinuxを有効にしている環境では、Zabbix用のポリシーのパッケージを導入して、必要な許可を与える運用が一般的です。無効にしてしまうのではなく、ポリシーで対応する方法が、安全面では望ましいです。詳細は、公式ドキュメントのパフォーマンスチューニングやインストールの項目を参照してください。

データベース要件 ​

Zabbixサーバーが使えるデータベースは、MySQL系（MySQL、MariaDB）とPostgreSQLです。ただし、対応するバージョンの範囲は、Zabbixのバージョンごとに決まっています。新しすぎても、古すぎても、サポート対象外になる場合があるので、導入するバージョンの要件のページを確認してください。

どちらを選ぶかは、組織で運用の経験があるほうを選ぶのが、現実的な基準です。性能の面では、PostgreSQLに時系列データ向けのTimescaleDBの拡張を組み合わせる構成が、大規模な環境では選ばれることがあります。文字コードは、MySQLでは、utf8mb4と、大文字小文字を区別する照合順序を指定して作成します。この設定は、後から変更しにくいので、最初に正しく指定しましょう。

データベースの設定の調整では、最も影響が大きいのは、データベースが使うメモリ領域の大きさです。MySQLのInnoDBバッファプールや、PostgreSQLの共有バッファは、データベース専用のサーバーであれば、搭載メモリの大きな割合を割り当てるのが一般的です。ただし、Webサーバーなどと同居させる場合は、他の用途のぶんを残す必要があります。

Webサーバー要件 ​

フロントエンドは、ApacheかNginxで動かします。公式のパッケージを使えば、Apache向けの設定ファイルが付属し、そのまま動作するのが利点です。Nginxを使う場合は、PHP-FPMと組み合わせます。

どちらを選ぶかについては、既存の運用に合わせるのが基本です。性能や機能の面での決定的な差はないため、チームが使い慣れているほうが、設定や障害対応を進めやすくなります。HTTPSでアクセスさせる場合は、証明書の準備も合わせて考えます。

PHP要件 ​

フロントエンドの動作には、PHPと、いくつかの拡張モジュールが必要です。必要なPHPのバージョンはZabbixのバージョンで決まっており、バージョンが上がると、必要な最低のバージョンも上がる傾向があります。拡張モジュールには、文字列の処理、ネットワーク通信、データベースへの接続、画像の生成などのものが含まれます。公式のパッケージを使えば、依存するモジュールも自動的に導入されるため、個別に気にする場面は少なくなります。

PHPの設定値としては、スクリプトの実行時間の上限、メモリの上限、POSTデータの大きさの上限、タイムゾーンなどがあり、Zabbixが要求する値が決まっています。公式パッケージの設定ファイルには、これらが含まれています。特にタイムゾーンは、日本で使う場合にAsia/Tokyoを指定しないと、表示時刻がずれるため、設定の確認が必要です。

セキュリティ考慮事項 ​

ファイアウォール設定 ​

Zabbixを動かすサーバーでは、通信の許可を、必要最小限に絞ります。必要になる通信は、役割ごとに異なります。サーバーは、エージェントやプロキシからの接続を受けるため、10051番を許可します。エージェントは、サーバーからの問い合わせを受けるため、10050番を許可します。管理画面には、HTTPの80番か、HTTPSの443番でアクセスします。

データベースのポートは、Zabbixサーバーとフロントエンドが動くマシンからの接続だけを許可し、他には公開しないようにします。Red Hat系でfirewalldを使うなら、必要なサービスやポートを、恒久的な設定として追加して再読み込みする、という流れです。

SSL/TLS設定 ​

管理画面にはログインのパスワードが入力されるため、HTTPSで暗号化してアクセスさせることが基本です。自己署名の証明書でも暗号化はできますが、ブラウザの警告が出るため、本番では、認証局が発行した証明書や、社内の認証局の証明書を使うのが一般的です。

また、監視対象とサーバーの間の通信も、必要に応じて、TLSで保護します。この方法は、第2部のアーキテクチャの章で触れたPSKや証明書を使うものです。証明書の期限が切れると通信できなくなるため、更新の運用も考えておきましょう。

事前準備チェックリスト ​

インストール前確認項目 ​

インストールの前に、確認する項目を、四つの観点で整理します。ハードウェアの面では、見積もったCPU、メモリ、ストレージが確保できているか、ネットワークの帯域が十分かを確かめます。ソフトウェアの面では、OSとバージョンが公式のサポートに入っているか、データベースとWebサーバー、PHPのバージョンが要件に合っているかを確認します。

ネットワークの面では、DNSの名前解決ができるか、必要なポートが開けられるか、HTTPSを使うなら証明書が用意できるか、そして時刻の同期が設定されているかを確認します。セキュリティの面では、SELinuxやAppArmorの扱いを決め、サービスを動かす専用のユーザーを用意し、バックアップの方針と、監査ログの方針を事前に決めておきます。

この確認を、作業前にひと通り行っておくと、インストール中に設定の見落としで止まる場面が減ります。特に、バックアップの方針は後回しにされがちですが、設定のデータベースを失うと、ホストやテンプレートの設定をすべてやり直すことになるため、最初の段階で決めておくことが大切です。

容量監視の設定 ​

インストールが終わったあとは、Zabbix自身を監視することが重要です。Zabbixサーバーを、ひとつのホストとして登録し、標準のテンプレートを使うと、ディスクの空き容量や、キャッシュの使用状況、プロセスの忙しさを確認できます。

特にディスクの空き容量は、データベースが肥大化して、いつの間にか足りなくなるという事態が、よくあります。たとえば、空きが20パーセントを切ったら警告を出す、というトリガーを設定しておくと、余裕のあるうちに増設の判断ができます。定期的な確認と、バックアップの運用も合わせて、継続的に行いましょう。

バックアップについては、何を守るかを分けて考えると整理しやすくなります。もっとも重要なのは、設定が入っているデータベースです。履歴データは量が多く、失っても監視の再開はできるため、保存の優先度を下げる判断もあります。そのほか、サーバーやエージェントの設定ファイル、Webインターフェースの設定ファイル、独自に作ったスクリプトも、復旧のときに必要になります。

実際に復旧できるかを、検証用の環境で試しておくことも大切です。バックアップを取っていても、戻せなければ意味がないためです。復旧にかかる時間も事前に把握しておけば、障害のときに、判断を急がずに済みます。バックアップの具体的な取り方は、第8部の運用管理の章で取り上げます。

ここまでの準備が整えば、次の章で説明するインストールを、安心して進められます。次章では、パッケージ、ソースコード、コンテナ、クラウドという導入方法を比べながら、環境に合ったやり方を選んでいきます。

参考リンク

• Zabbix Requirements
• Zabbix Performance Tuning

← 目次に戻る | 次へ: 3.2 インストール方法 →