Ubuntu16.04でIcingaを使用してホストとサービスを監視する方法
序章
Icingaは、ネットワーク化されたホストとサービスの状態を監視するために使用されるオープンソースの監視システムです。 このチュートリアルでは、Icingaを使用して2種類の監視構成をセットアップします。 1つ目は、Webサイトへの定期的なHTTPリクエストの作成など、ホストの外部サービスの単純なネットワークチェックに基づいています。 もう1つの構成では、ホストで実行されているソフトウェアエージェントを使用して、負荷や実行中のプロセスの数など、より詳細なシステム情報を収集します。
前提条件
このチュートリアルを開始する前に、このシリーズの前のチュートリアル Ubuntu16.04にIcingaとIcingaWebをインストールする方法を完了している必要があります。 これにより、IcingaコアとIcingaWebインターフェイスが単一のホストで実行されたままになります。これを全体を通してicinga-masterノードと呼びます。
また、監視するサーバーもいくつか必要になります。 この例では、Apacheがインストールされた2台のUbuntu16.04サーバーを使用します。 これらを設定するには、上記のLAMPチュートリアルのApache部分だけを使用できます。
ステップ1-シンプルなホストモニタリングの設定
Icingaでサーバーを監視する簡単な方法の1つは、外部で利用可能なサービスの定期的なチェックを設定することです。 そのため、Webホストの場合、サーバーのIPアドレスに定期的にpingを実行し、Webページへのアクセスも試みます。 これにより、ホストが稼働しているかどうか、およびWebサーバーが正しく機能しているかどうかがわかります。
Webサーバーの監視を設定しましょう。 前提条件として記載されているApacheサーバーの1つを選択し、デフォルトのApacheプレースホルダーページが適切に提供されていることを確認します。 このサーバーをweb-1.example.com
と呼びます。 ログインする必要はまったくありません。すべてのヘルスチェックはマスターノードで構成および実行されます。
注: Icingaは、常にデフォルトで、処理しているホストの完全修飾ドメイン名(FQDN)を使用します。 FQDNはホスト名とそのドメイン名であるため、たとえばweb-1.example.com
です。 ホストに適切なドメインを設定していない場合、FQDNはweb-1.localdomain
のようになります。
これらは使用しても問題なく、一貫性があります。「実際の」FQDNがない場合は、構成するIcingaaddress
フィールドで常にサーバーのIPアドレスを使用してください。
マスターノードにログインします。 新しいホストを追加するには、Icingaのhosts.conf
ファイルを編集する必要があります。 テキストエディタで開きます。
sudo nano /etc/icinga2/conf.d/hosts.conf
これにより、いくつかの説明コメントと単一のホストブロックが定義されたファイルが開きます。 既存のobject Host NodeName
構成ブロックは、 icinga-master ホストを定義します。これは、IcingaおよびIcingaWebをインストールしたホストです。 ファイルの下部にカーソルを置き、新しいホストを追加します。
/etc/icinga2/conf.d/hosts.conf
. . . object Host "web-1.example.com" { import "generic-host" address = "web-1_server_ip" vars.http_vhosts["http"] = { http_uri = "/" } vars.notification["mail"] = { groups = [ "icingaadmins" ] } }
これにより、web-1.example.com
というホストが定義され、generic-host
というテンプレートからデフォルトのホスト構成がインポートされ、Icingaが正しいIPアドレスを指定し、IcingaにHTTPをチェックするように指示するいくつかの変数が定義されます。ルート(/
)URLで応答し、問題が発生した場合はicingaadmins
グループに電子メールで通知します。
ファイルを保存して閉じてから、Icingaを再起動します。
sudo systemctl restart icinga2
ブラウザでIcingaWebインターフェイスに戻ります。 インターフェイスはかなり急速に更新されるため、ページを更新する必要はありません。 新しいホスト情報は短い順序で入力され、Icingaが十分な情報を収集すると、ヘルスチェックは保留中からOKに変更されます。
これは、ホスト上の外部サービスを監視するための優れた方法であり、SSHサーバーやSMTPなどで利用できる他のチェックがあります。 ただし、監視しているサーバーの内部状態について詳しく知ることもできます。
次に、Icingaエージェントを介して監視を設定し、より詳細なシステム情報を監視できるようにします。
ステップ2–エージェントベースの監視を設定する
Icingaは、より広範なリモートヘルスチェックを実行するために、マスターノードとクライアントノード間で安全に通信するためのメカニズムを提供します。 Webサーバーがページを正常に処理していることを知るだけでなく、CPU負荷、プロセス数、ディスク容量などを監視することもできます。
監視する2番目のサーバーをセットアップします。 これをweb-2.example.com
と呼びます。 リモートマシンにIcingaソフトウェアをインストールし、いくつかのセットアップウィザードを実行して接続を確立してから、Icingaマスターノードのいくつかの構成ファイルを更新する必要があります。
注: Icingaインストールを設計する方法は多数あり、マスター/衛星/クライアントノードの複数の層を備えています。可用性フェイルオーバー、およびノード間で構成の詳細を共有するための複数の方法。 1つのマスターノードと複数のクライアントノードを備えた単純な2層構造をセットアップしています。 さらに、すべての構成は master ノードで実行され、ヘルスチェックコマンドはマスターノードでスケジュールされ、クライアントにプッシュされます。 Icingaプロジェクトは、このセットアップをトップダウンコマンドエンドポイントモードと呼びます。
マスターノードを設定する
まず、クライアント接続を行うためにマスターノードを設定する必要があります。 これを行うには、マスターノードでノードセットアップwidgetを実行します。
sudo icinga2 node wizard
これにより、いくつかの質問をするスクリプトが開始され、準備が整います。 以下では、ENTER
を押して、ほとんどのデフォルトを受け入れます。 デフォルト以外の回答が強調表示されます。 わかりやすくするために、一部の情報出力は削除されています。
OutputPlease specify if this is a satellite setup ('n' installs a master setup) [Y/n]: n Starting the Master setup routine... Please specify the common name (CN) [icinga-master.example.com]: ENTER to accept the default, or type your FQDN Checking for existing certificates for common name 'icinga-master.example.com'... Certificates not yet generated. Running 'api setup' now. Enabling feature api. Make sure to restart Icinga 2 for these changes to take effect. Please specify the API bind host/port (optional): ENTER Bind Host []: ENTER Bind Port []: ENTER Done. Now restart your Icinga 2 daemon to finish the installation!
Icingaを再起動して、構成の更新を完了します。
sudo systemctl restart icinga2
ファイアウォールポートを開いて、Icingaへの外部接続を許可します。
sudo ufw allow 5665
次に、クライアントノードに切り替え、Icingaをインストールして、同じウィザードを実行します。
クライアントノードを設定する
web-2.example.comと呼んでいるサーバーにログインします。 Icingaリポジトリを再度インストールしてから、Icinga自体をインストールする必要があります。 これは、マスターノードで使用した手順と同じです。 最初にキーをインストールします。
curl -sSL https://packages.icinga.com/icinga.key | sudo apt-key add -
icinga.list
ファイルを開きます。
sudo nano /etc/apt/sources.list.d/icinga.list
リポジトリの詳細を貼り付けます。
/etc/apt/sources.list.d/icinga.list
deb https://packages.icinga.com/ubuntu icinga-xenial main
ファイルを保存して閉じてから、パッケージキャッシュを更新します。
sudo apt-get update
次に、icinga2
をインストールします。 マスターノードにインストールした'icinga2-ido-mysql
パッケージは必要ないことに注意してください。
sudo apt-get install icinga2
ここで、このサーバーでノードウィザードを実行しますが、masterの代わりにsatellite構成を実行します。
sudo icinga2 node wizard
OutputPlease specify if this is a satellite setup ('n' installs a master setup) [Y/n]: y Starting the Node setup routine... Please specify the common name (CN) [web-2.example.com]: ENTER Please specify the master endpoint(s) this node should connect to: Master Common Name (CN from your master setup): icinga-master.example.com Do you want to establish a connection to the master from this node? [Y/n]: y Please fill out the master connection information: Master endpoint host (Your master's IP address or FQDN): icinga-master_server_ip Master endpoint port [5665]: ENTER Add more master endpoints? [y/N]: ENTER Please specify the master connection for CSR auto-signing (defaults to master endpoint host): Host [icinga-master_server_ip]: ENTER Port [5665]: ENTER
ウィザードは、マスターノードから公開証明書を取得し、その詳細を表示します。 情報を確認して、続行します。
Output. . . Is this information correct? [y/N]: y information/cli: Received trusted master certificate. Please specify the request ticket generated on your Icinga 2 master. (Hint: # icinga2 pki ticket --cn 'web-2.example.com'):
この時点で、master
サーバーに戻り、ウィザードで要求されたコマンドを実行します。 その前にあるsudo
を忘れないでください。
sudo icinga2 pki ticket --cn 'web-2.example.com'
コマンドはキーを出力します。 クリップボードにコピーしてからクライアントノードに戻り、貼り付けてENTER
を押してウィザードを続行します。
Output. . . information/cli: Requesting certificate with ticket '5f53864a504a1c42ad69faa930bffa3a12600546'. Please specify the API bind host/port (optional): Bind Host []: ENTER Bind Port []: ENTER Accept config from master? [y/N]: n Accept commands from master? [y/N]: y Done. Now restart your Icinga 2 daemon to finish the installation!
次に、ファイアウォールのIcingaポートを開きます。
sudo ufw allow 5665
そして、Icingaを再起動して、構成を完全に更新します。
sudo systemctl restart icinga2
netstat
を使用して、2つのサーバー間に接続があることを確認できます。
netstat | grep :5665
接続が確立されるまでに少し時間がかかる場合があります。 最終的に、netstat
は、正しいポートでのESTABLISHED
接続を示す行を出力します。
Outputtcp 0 0 web-2_server_ip:58188 icinga-master_server_ip:5665 ESTABLISHED
これは、サーバーが接続され、クライアントチェックを構成する準備ができていることを示しています。
エージェント監視を構成する
マスターとクライアントが接続されたとしても、監視を有効にするためにマスターで実行するいくつかのセットアップがあります。 新しいホストファイルを設定する必要があります。 マスターノードに戻ります。
Icingaインストールにおける組織の重要なレベルの1つは、ゾーンの概念です。 すべてのクライアントノードは、独自のゾーンを作成し、親ゾーン(この場合はマスターノード)に報告する必要があります。 デフォルトでは、マスターノードのゾーンはそのFQDNにちなんで名付けられています。 Icingaのzones.d
ディレクトリ内にマスターゾーンにちなんで名付けられたディレクトリを作成します。 これにより、すべてのマスターゾーンのクライアントの情報が保持されます。
ゾーンディレクトリを作成します。
sudo mkdir /etc/icinga2/zones.d/icinga-master.example.com
サービス構成ファイルを作成します。 これにより、リモートクライアントノードで実行するサービスチェックが定義されます。 今すぐファイルを開きます。
sudo nano /etc/icinga2/zones.d/icinga-master.example.com/services.conf
以下に貼り付けて、保存して閉じます。
services.conf
apply Service "load" { import "generic-service" check_command = "load" command_endpoint = host.vars.client_endpoint assign where host.vars.client_endpoint } apply Service "procs" { import "generic-service" check_command = "procs" command_endpoint = host.vars.client_endpoint assign where host.vars.client_endpoint }
これにより、2つのサービスチェックが定義されます。 1つ目はCPU負荷について報告し、2つ目はサーバー上のプロセス数をチェックします。 各サービス定義の最後の2行は重要です。 command_endpoint
は、このサービスチェックをリモートコマンドエンドポイントに送信する必要があることをIcingaに通知します。 assign where
行は、client_endpoint
変数が定義されているすべてのホストにサービスチェックを自動的に割り当てます。
それでは、そのようなホストを作成しましょう。 以前に作成したゾーンディレクトリで新しいファイルを開きます。 ここでは、リモートホストにちなんでファイルに名前を付けています。
sudo nano /etc/icinga2/zones.d/icinga-master.example.com/web-2.example.com<^>.conf
次の構成で貼り付けてから、ファイルを保存して閉じます。
web-2.example.com.conf
object Zone "web-2.example.com" { endpoints = [ "web-2.example.com" ] parent = "icinga-master.example.com" } object Endpoint "web-2.example.com" { host = "web-2_server_ip" } object Host "web-2.example.com" { import "generic-host" address = "web-2_server_ip" vars.http_vhosts["http"] = { http_uri = "/" } vars.notification["mail"] = { groups = [ "icingaadmins" ] } vars.client_endpoint = name }
このファイルは、リモートホストのゾーンを定義し、それを親ゾーンに結び付けます。 また、ホストをエンドポイントとして定義し、次にホスト自体を定義して、generic-host
テンプレートからいくつかのデフォルトルールをインポートします。 また、いくつかのvars
を設定して、HTTPチェックを作成し、電子メール通知を有効にします。 このホストにはvars.client_endpoint = name
が定義されているため、services.conf
で定義したサービスチェックも割り当てられることに注意してください。
Icingaを再起動して、構成を更新します。
sudo systemctl restart icinga2
Icinga Webインターフェイスに戻ると、新しいホストに保留中のチェックが表示されます。 しばらくすると、これらのチェックはOkに変わるはずです。 これは、クライアントノードがマスターノードのチェックを正常に実行していることを意味します。
結論
このチュートリアルでは、Icingaを使用した2種類の監視、外部サービスチェックとエージェントベースのホストチェックを設定しました。 Icingaの構成と操作について学ぶことはまだまだたくさんあるので、Icingaの広範なドキュメントをさらに深く掘り下げたいと思うでしょう。
カスタムcheckコマンドが必要になる場合は、グローバル構成ゾーンを使用して、これらをマスターノードからクライアントノードに同期する必要があることに注意してください。 この特定の機能の詳細については、こちらをご覧ください。
最後に、監視するサーバーが多数ある場合は、構成管理ソフトウェアを使用してIcinga構成の更新を自動化することを検討してください。 チュートリアルシリーズ構成管理入門では、関連する概念とソフトウェアの包括的な概要を説明します。