3.3 初期設定とセットアップ
Zabbixインストール後の基本設定と運用開始のための初期設定
インストールが終わった直後のZabbixは、動き始めてはいますが、実際の運用に使える状態にはなっていません。初期のパスワードは公開されたままですし、通知の宛先も決まっておらず、時刻やタイムゾーンも、環境に合っていないかもしれません。この状態で監視を始めると、見落としや、安全面の問題が起こりやすくなります。
この章では、インストール後に最初に行うべき設定を、順番に説明します。データベースの確認、Webインターフェースの初期設定ウィザード、管理者アカウントの保護、基本的なセキュリティ、最初の監視と通知の設定、運用を支える設定という流れです。画面の操作は、Zabbix 7.0のメニュー構成を前提にしています。バージョンによって名称が異なる場合があるので、公式のドキュメントと見比べながら進めてください。
初期設定概要
初期設定の目的は、安全に、そして、継続して運用できる状態を作ることです。インストールの段階では、動作に必要な最低限の設定しか行われていないため、運用の観点での設定を、ここで追加します。
作業は大きく四つの段階に分かれます。まず、インストール時に作ったデータベースが、安定して動く状態かを確認します。次に、ブラウザからの初期設定ウィザードを完了し、管理者のアカウントを保護します。そのあと、通信やアクセスの制御といった、基本的なセキュリティを整えます。最後に、最初のホストの監視と、通知の設定を行い、動作を確認します。
初期設定の重要性
初期設定を丁寧に行う意味は、あとから直しにくい項目が含まれていることにあります。たとえば、データベースの文字コードや、ホストグループの設計、命名のルールは、運用が進んでから変えると、影響が広がります。
また、セキュリティの設定は、後回しにされやすい項目です。監視システムは、社内のあらゆる機器の情報を集めているため、侵入されると被害が大きくなります。インターネットから到達できる環境や、複数の部署が使う環境では、特に、最初の段階で対策を済ませておくことが重要です。
データベースの初期設定
データベースの確認事項
データベースは、Zabbixの性能と安定性を左右する部品です。インストール時に作成したデータベースが、文字コードとして、MySQLならutf8mb4、照合順序として、大文字小文字を区別するものになっているかを確認します。誤った設定だと、ホスト名の大文字小文字が区別されないなど、予期しない動作の原因になります。
次に、データベースのメモリの設定を見直します。MySQLのInnoDBバッファプール、PostgreSQLの共有バッファは、データのキャッシュに使われるため、性能への影響が大きい設定です。データベース専用のサーバーであれば、搭載メモリの大きな割合を割り当てるのが一般的ですが、他のサービスと同居する場合は、バランスを考えます。具体的な推奨値は、データベースの公式の資料と、Zabbixのパフォーマンスチューニングの資料を参照してください。
データの保持とメンテナンス
Zabbixには、期限が切れた履歴データを自動で削除するハウスキーパーという機能があります。削除の期間は、アイテムごとの設定と、全体の設定の両方で決まります。全体の設定は、管理のメニューのハウスキーピングの画面で確認できます。
自分で削除のスクリプトを書いて、データベースを直接操作するのは、おすすめしません。Zabbixの内部の整合性を崩すおそれがあるためです。保持の期間を短くすれば、データベースの肥大化を抑えられるので、まずは、要件に必要な期間を決め、その範囲で設定してください。非常に大きな環境では、テーブルのパーティショニングという手法で、削除の負荷を抑える方法もありますが、これは、第8部の運用管理で扱います。
接続の制限
データベースは、Zabbixサーバーと、フロントエンドからだけ接続できればよいので、他からの接続を受けない設定にします。同じマシンで動かしているなら、ローカルのみで待ち受けるようにし、別のマシンに分けているなら、ファイアウォールで接続元を限定します。
また、データベースのパスワードは、推測されにくいものにして、設定ファイルの読み取り権限を絞ります。パスワードを変更したときは、サーバーの設定ファイルと、フロントエンドの設定ファイルの両方を更新する必要があるので、忘れないようにしてください。
Webインターフェースの初期設定
初回セットアップウィザード
ブラウザで、サーバーのアドレスの/zabbixにアクセスすると、初回のセットアップウィザードが始まります。ウィザードは、複数の画面を順に進める形式で、言語の選択、前提条件の確認、データベースの接続情報の入力、サーバーの情報の入力、設定の確認という流れになります。
言語は、日本語を選べますが、システムにその言語のロケールが入っていないと、選べないことがあります。その場合でも、あとでユーザーごとの設定から、表示言語を変更できます。
前提条件の確認の画面では、PHPのバージョン、必要な拡張モジュール、PHPの設定値が、要件を満たしているかが一覧で表示されます。問題のある項目は、色で示されるため、Webサーバーの設定を修正して、再読み込みします。この画面で、すべての項目が問題なしになってから、次に進んでください。
データベースの接続情報の画面では、データベースの種類、ホスト、ポート、データベース名、ユーザー名、パスワードを入力します。ここで入力した内容は、フロントエンドの設定ファイルに保存されます。接続のテストが失敗する場合は、データベース側のユーザーの権限と、パスワードを確認します。続くサーバーの設定の画面では、Zabbixサーバーのホスト名とポートを指定し、画面右上などに表示する名前を決めます。
管理者アカウントの設定
ウィザードが終わると、ログイン画面が表示されます。初期のユーザー名はAdmin、パスワードはzabbixです。これらは公式のドキュメントにも載っている公開情報なので、最初のログインのあとに、必ず変更します。
パスワードの変更は、管理画面のユーザーの設定から行います。Adminには、すべての操作ができる強い権限があるため、パスワードは、長く複雑なものにします。日常の運用では、Adminを使い回さず、担当者ごとに個別のアカウントを作成し、必要な権限だけを与えるのが望ましい運用です。
また、初期から存在するGuestというユーザーは、ログインなしで画面を見られる設定に使われます。使う予定がなければ、無効にしておきます。不要なアカウントを残さないのは、セキュリティの基本です。
タイムゾーンと地域設定
監視では、時刻が重要です。問題の発生時刻や、グラフの横軸が、実際の時刻とずれていると、障害の分析に支障が出ます。そこで、時刻に関わる設定を、三か所確認します。
ひとつめは、OSの時刻の同期です。NTPやchronyを使って、サーバーとエージェントの時刻を、正確に合わせます。ふたつめは、PHPのタイムゾーンで、Webサーバーの設定に、Asia/Tokyoを指定します。みっつめは、Zabbixの画面上のタイムゾーンです。管理のメニューの一般設定にあるGUIの項目で、システム全体の既定のタイムゾーンを設定でき、ユーザーごとの設定で上書きもできます。この三つが揃っていると、表示される時刻が、実際の時刻と一致します。
基本的なセキュリティ設定
ネットワークセキュリティ
ファイアウォールでは、必要な通信だけを許可します。管理画面へのアクセスは、管理者のネットワークからだけ、エージェントからサーバーへの通信は、監視対象のアドレスからだけ、というように、接続元を絞ります。サーバーが受け付けるポートの考え方は、第2部のアーキテクチャの章を参照してください。
管理画面は、HTTPSでの提供を前提にします。証明書を設定し、HTTPからHTTPSへ転送する設定にすれば、パスワードが、平文で流れるのを防げます。さらに、HSTSなどのセキュリティ関連のヘッダーを付けると、ブラウザ側の保護も強化できます。不要なディレクトリへのアクセスを拒否する設定は、公式パッケージの設定ファイルに含まれていますが、設定を変更したときは、意図せず外れていないかを確認してください。
認証設定の強化
ユーザーの認証は、管理のメニューの認証の画面で設定します。パスワードの最小の長さや、複雑さの条件、ログインの失敗の回数の制限などを、組織のポリシーに合わせて設定できます。ログインの失敗が続くと一時的にロックされる仕組みは、総当たりの攻撃を、抑える効果があります。
組織にすでに、LDAPやActive Directory、SAMLなどのアカウント基盤がある場合は、それと連携して、認証を一元化できます。連携することで、パスワードの管理が一か所になり、退職者のアカウントの無効化も、漏れにくくなります。設定には、接続先のホスト、ベースとなるDN、検索の属性などが必要で、テストの機能で、接続を確かめられます。
セッションの有効期間も、設定できる項目です。長すぎると、席を離れたときのリスクが増えるため、運用に支障のない範囲で、短めにするとよいでしょう。
アクセス制御の設定
Zabbixでは、ユーザーをユーザーグループに所属させ、ユーザーグループに対して、どのホストグループが見られるか、操作できるかを設定します。さらに、ユーザーにはロールを割り当て、画面のどの機能を使えるか、APIを使えるかを決めます。ユーザーのロールには、標準でUser、Admin、Super adminの三種類が用意されています。
設計の基本は、最小権限です。たとえば、運用の担当者には、担当するホストグループの閲覧と、問題の確認だけを許可し、設定の変更は、限られた管理者だけに許可します。部署ごとにホストグループを分けておけば、部署ごとの閲覧の範囲も、グループの権限で制御できます。そのため、ホストグループの設計を、最初に決めておくことが、後の権限の管理を、楽にします。
また、IPアドレスによるアクセスの制限は、Webサーバー側か、ファイアウォールの設定で行います。管理画面を、社内ネットワークやVPNからだけ到達できるようにしておけば、外部からの攻撃のリスクを、大きく減らせます。
基本監視設定
Zabbixエージェントの設定
Zabbixサーバーを導入すると、サーバー自身を監視するホストが、最初から登録されています。名前は、Zabbix serverで、同じマシンで動くエージェントから、値を取得する設定です。エージェントが動いていないと、このホストの監視が、失敗して表示されるので、最初の動作確認に使えます。
エージェントの設定では、サーバーのアドレス、アクティブチェック用のサーバーの宛先、ホスト名の三つを、合わせます。これは、第2部で説明した、パッシブとアクティブの仕組みに対応するものです。他のサーバーを監視対象に加えるときは、そのサーバーにエージェントを導入して、同じ項目を設定します。エージェントのホスト名は、Zabbixの画面に登録するホスト名と、一致させる必要があります。
ホストの追加と基本監視
新しいホストの登録は、データ収集のメニューのホストの画面から行います。必要な入力は、ホスト名、所属させるホストグループ、インターフェース、そして、リンクするテンプレートです。Linuxのサーバーなら、Linux by Zabbix agentというテンプレートをリンクすれば、CPU、メモリ、ディスク、ネットワークなどの基本的な監視が、すぐに始まります。
Zabbix serverのホストには、Zabbix server healthというテンプレートが標準でリンクされています。サーバー自身のキャッシュの使用率や、プロセスの忙しさを、確認するためのものです。まずは、これらの標準テンプレートを使い、画面に値が表示されることを確認してください。数分待っても値が入らない場合は、エージェントの接続や、ホスト名の一致を、見直します。
登録のときは、ホストグループの付け方も、あわせて考えます。環境（本番や検証）や、役割（Web、データベース）といった観点で整理しておくと、あとで権限やアクションの条件を、設定しやすくなります。
アクション設定
問題を人に知らせるには、メディアタイプと、アクションの二つの設定が必要です。メディアタイプは、通知の手段を定義するもので、アラートのメニューのメディアタイプの画面で設定します。メールを使う場合は、SMTPサーバー、ポート、接続の保護の方式、認証の情報を入力します。標準で、メールやSlack、Microsoft Teamsなど、多くの手段が用意されています。
メディアタイプを作ったら、通知を受け取るユーザーの設定に、宛先を登録します。ユーザーの設定のメディアの項目に、メールアドレスなどを追加し、どの深刻度の問題を受け取るか、どの時間帯に受け取るかを、指定します。
そのあとで、アラートのメニューのアクションの画面で、トリガーのアクションを作成します。条件には、深刻度や、ホストグループを指定でき、操作の項目に、誰に、どのメッセージを送るかを設定します。標準のメッセージのテンプレートには、問題の名前や、ホスト名、深刻度などのマクロが入っているため、最初は、そのまま使って構いません。設定が終わったら、テスト用のトリガーを使って、実際に通知が届くかを確認します。
運用設定
ログ管理設定
Zabbixのサーバーやエージェントは、ログファイルに動作を記録します。ログは、問題が起きたときの、重要な手がかりですが、増え続けるとディスクを圧迫します。そこで、OSのログローテーションの仕組みで、一定の期間や大きさで、古いログを圧縮・削除するように設定します。公式のパッケージを使う場合は、ローテーションの設定が、同梱されていることが多いので、まず内容を確認してください。
ログの詳しさは、設定のログレベルで調整できます。通常は初期値のままにしておき、問題の調査のときだけ、一時的に詳しくします。詳細なログを出し続けると、性能の低下や、ディスクの消費につながるためです。
バックアップ戦略
バックアップは、監視システムの運用で、もっとも重要な設定のひとつです。守る対象の優先順位は、データベースの設定のデータ、設定ファイル、履歴データの順に考えます。設定のデータが失われると、監視を作り直す必要があるため、最優先です。
データベースのバックアップは、MySQLならmysqldump、PostgreSQLならpg_dumpといった、標準のツールで取得し、日次などの定期の実行にします。大きな環境では、履歴のテーブルを除いて、設定のテーブルだけを取る方法もあります。取得したバックアップは、同じサーバーの中に置かず、別の場所にも保管してください。そして、定期的に、復旧の手順を試して、戻せることを確認します。
監視の確認
最後に、初期設定の全体が、正しく行われたかを、確認します。サービスの面では、サーバー、エージェント、Webサーバー、データベースが動いているかを、確かめます。通信の面では、画面にアクセスでき、エージェントの通信が成功しているかを見ます。
監視の機能の面では、ホストが登録され、アイテムに値が入り、トリガーが評価され、通知が届くことを確認します。セキュリティの面では、初期パスワードの変更、ファイアウォールの設定、HTTPSの設定、アクセスの制限が、完了していることを確認します。この点検をひと通り行うことで、安心して、本格的な監視の設定に進めます。
パフォーマンス監視
Zabbixは、自分自身の状態を、内部のメトリクスとして公開しています。プロセスがどれだけ忙しいか、キャッシュの空きがどれくらいか、一秒あたりに処理した値の数などが、取得できます。これらは、Zabbix server healthのテンプレートに含まれており、標準のダッシュボードやグラフで確認できます。
プロセスの忙しさが高い状態が続いたり、キャッシュの空きが少なくなったりしたら、サーバーの設定値の見直しや、構成の拡張を検討する合図です。数値が悪化してから慌てるのではなく、日頃から傾向を見ておけば、余裕のあるうちに対策できます。内部メトリクスの意味と、対応する設定は、公式の資料にまとまっています。
参考リンク