Linux の監視

RPM または DEB パッケージをインストールして、Linux エージェントをインストールします。 RPM または DEB のどちらが必要かは、パッケージをインストールする Linux ディストリビューションによって異なります。

インストールする前に、パッケージを入手し、エージェントを実行するホスト（scp や WinSCP など）にパッケージを転送する必要があります。

RPM または DEB パッケージを取得し、必要に応じてscp 、WinSCP またはその他の手段を使用して監視するホストにコピーしたら、1 つのコマンドでインストールが完了します。

RPM パッケージは、root コマンドで、ユーザー としてインストールします。rpm -U

ちなみに、-U オプションは「更新」を意味しますが、最初のインストールも正しく実行できます。 つまり、このコマンドを使用して、既存のエージェントを現在のバージョンに更新したり、将来エージェントパッケージが更新されたときに同じコマンドを使用して更新したりすることができます。

DEB パッケージのインストールおよびアップデートは、ユーザーroot で、コマンドdpkg -i を使用して行います。

ここでは、パッケージが、これまでエージェントがインストールされていなかったホストに初めてインストールされています。cmk-agent ユーザーが作成され、systemd が設定されています。insecure mode 、つまりレガシープルモードに関する一時的な警告については、後で説明します。

商業版には、カスタマイズしたエージェントを自動的にパッケージ化するソフトウェアモジュール「エージェントベーカリー」が付属しています。 このモジュールの詳細については、エージェントに関する一般的な記事をご覧ください。 ベイクしたパッケージのインストールは、付属のパッケージの場合と同じ方法で行います。

Checkmk Cloud 以降では、エージェントベーカリーを使用して、自動登録用の設定をエージェントパッケージに追加することができます。 これにより、ホストの自動作成が容易になります。 この場合、エージェントパッケージのインストール後にエージェントの登録が自動的に行われ 、次の章で説明する手動での登録は不要になります。

エージェントベーカリーを使用する場合、エージェントの自動更新を設定することもできます。 これらの更新については、別の記事で説明しています。

インストール時にエージェントコントローラーをsystemd で設定できた場合、次のステップは登録です。この登録により、TLS 暗号化が設定され、暗号化されたエージェント出力が Checkmk サーバーで復号化され、監視に表示されるようになります。

エージェントコントローラーを使用してエージェントを初めてインストールした場合、特別な機能があります。 この場合、エージェントは暗号化されていないレガシープルモードに切り替わります これにより、Checkmk サーバーが監視データから切り離されることなく、データを引き続き表示することができます。 これは、新規インストールだけでなく、2.0.0 以前のバージョンのエージェントのアップデートにも適用されます。

エージェントのインストール中に、有効化されたレガシープルモードに関する通知がコマンド出力で表示されます。 監視では、次のように表示されます。

Checkmk サイトは、エージェントの出力から、エージェントコントローラーが存在し、TLS 暗号化が可能であることを認識しますが、まだ有効になっていません。Check_MK Agent サービスは、WARN 状態になり、登録するまでその状態を維持します。 登録後は、通信には暗号化されたプルモードのみが使用されます。 レガシープルモードはオフになり、その状態を維持します。 ただし、必要に応じてコマンドで再びオンにすることができます。

インストール中にエージェントコントローラーをsystemd のディーモンとして登録できなかった場合は、状況が異なります。 エージェントコントローラーがない場合、登録は不可能であり、唯一の通信パスはレガシーモードのままとなります。

次の章では、エージェントコントローラーとシステム環境をテストして、登録を続行できるかどうかを判断します。

注： Checkmk Agent installation auditing ルールセットには、エージェントの状態をチェックし、監視で表示するためのさまざまな設定があります。 ここでは、TLS 設定がまだ行われていない場合に、Check_MK Agent サービスが持つべき状態を指定することができます。

エージェントのインストール直後（バージョン2.0.0 以前のエージェントのアップデートの場合も同様です）、レガシープルモードでは暗号化されていない通信のみが可能です。 暗号化されたデータ送信のみを有効にするには、信頼関係が確立されている必要があります。

この例外は、自動登録用に事前設定され、エージェントベーカリーからダウンロードしたパッケージです。 これらのパッケージは、インストール後に自動的に登録を行います。

それ以外の場合は、エージェントのインストール後、すぐに手動で登録を行ってください。 この章では、登録の方法について説明します。

登録、つまり相互の信頼関係の確立は、REST API へのアクセス権を持つ Checkmk ユーザーとして行います。 このためには、エージェントの登録のみ許可され、Checkmk のインストール時に自動的に作成されるオートメーションユーザー agent_registration が適しています。 対応するオートメーションパスワード（オートメーションの秘密）は、アイコンでランダム化することができます。 新しいパスワードを使用するには、ユーザーを保存する必要があります。

エージェントコントローラーを備えたエージェントには、systemd 、より正確にはsystemd バージョン 219 以降の Linux ディストリビューションが必要です。

2015 年以降、ほとんどの Linux ディストリビューションは、SysVinit などの他の init システムに代わってsystemd を init システムとして採用しているため、お使いのホストがこの要件を満たしている可能性は高いです。例えば、SUSE Linux Enterprise Server バージョン 12 以降、openSUSE バージョン 12.1 以降、Red Hat Enterprise Linux バージョン 7 以降、Fedora バージョン 15 以降、Debian バージョン 8 以降、Ubuntu バージョン 15.04 以降などです。 残念ながら、バージョン番号だけを比較しても確実ではありません。systemd は、長年にわたって「更新のみ」が行われてきた現在の Linux システムでも、インストールされていない場合があるためです。

systemd のバージョンに加え、いくつかの追加の要件を満たす必要があります。これらは本章で説明します。

注意：プッシュモードと自動登録は、エージェントコントローラーに依存しているため、レガシーモードでは使用できません。この点については、この章で何度か触れます。

したがって、まず、エージェントをインストールするホストで、systemd が実行されているかどうか、およびそのバージョンを確認してください。

上記のコマンドの出力は、systemd の正しいバージョンがインストールされていることを示しています。systemd が実行されていないか、バージョンが古すぎる場合、エージェントコントローラーは使用できません。 レガシーモードでの Linux の監視の記事の説明に従って、セットアップを完了してください。

エージェントコントローラーが起動できるかどうかを確認します。

出力にバージョン番号が表示される必要があります。例:

まれに、次のエラーメッセージが表示される場合があります。

この原因は、お使いの Linux がx86_64 とは異なるコンピュータアーキテクチャ（たとえば、古い32 ビット x86またはARM）を使用しているためです。 この場合、エージェントコントローラーは使用できません。

レガシーモードでの Linux の監視の記事に記載されているセットアップを完了してください。

次に、ポート 6556 でリクエストを待機しているプログラムを確認します:

ここでは、cmk-agent-ctl です。 これで、暗号化された通信の要件が満たされました。 ただし、systemd 、xinetd 、またはinetd が括弧内に含まれている場合、エージェントコントローラーを使用するための前提条件が満たされていません。 その場合は、「レガシーモードで Linux を監視する」の記事に記載されているセットアップも完了してください。

まず、Setup > Hosts > Add host.から新しいホストを作成します。 ホストは、設定環境に存在している必要があります。

Checkmk Cloud 以降では、ホストのプロパティの監視エージェントのセクションにCheckmk agent connection mode オプションがあります。 ここでは、すべてのエディションで利用できるプルモードの代わりに、Checkmk エージェントのプッシュモードを有効にすることができます。

登録は、接続を設定するためのコマンドインターフェースを提供するエージェントコントローラーcmk-agent-ctl を使用して行います。 コマンドのヘルプは、cmk-agent-ctl help で表示できます。また、cmk-agent-ctl help register など、使用可能な特定のサブコマンドのヘルプも表示できます。

コマンドの例では、ホストがプルモードまたはプッシュモードのいずれで設定されているかは関係ありません。 エージェントレシーバーは、登録時にエージェントコントローラーに、どのモードで動作すべきかを伝えます。

次に、登録するホストに移動します。 ここで、root の権限を使用して、Checkmkサイトにリクエストを送信します。

--hostname オプションの後のホスト名は、セットアップで作成したときとまったく同じである必要があります。--server および--site オプションは、Checkmk サーバーとサイトの名前を指定します。 サーバー名は IP アドレスでもかまいません。サイト名（ここではmysite ）は、web インターフェイスの URL パスに表示される名前に対応しています。 オプションは、オートメーションユーザーが使用する名前とパスワードで完了します。 --password オプションを省略すると、パスワードが対話形式で要求されます。

指定した値が正しい場合、接続先の Checkmk サイトの ID を確認するメッセージが表示されます。 ここではわかりやすくするために、確認するサーバー証明書を省略しています。

Y で確認して、プロセスを完了してください。

エラーメッセージが表示されなければ、暗号化された接続が確立されました。 これで、すべてのデータは、この接続を介して圧縮されたフォームで送信されます。

登録を完全に自動化するためなど、証明書の対話型チェックを無効にしたい場合は、追加パラメータ--trust-cert を使用することができます。 この場合、転送された証明書は自動的に信頼されます。 証明書の整合性を確認するための他の措置を講じる必要があることにご注意ください。 これは、ファイル /var/lib/cmk-agent/registered_connections.json を検査することで（手動またはスクリプトを使用して）実行できます。

Checkmk Cloud 以降、Checkmk では、登録時にホストを自動的に作成する機能を提供しています。 自動登録を行うには、ホストを登録する許可を持つユーザーに加え、自動的に作成するホストを保存するためのフォルダを 1 つ以上設定する必要があります。

これらの条件が満たされている場合は、コマンドラインからホストの自動作成を含む登録を実行することもできます。

通常は、エージェントベーカリーの設定手順を使用します。 この手順では、エージェントパッケージに/var/lib/cmk-agent/pre_configured_connections.json 設定ファイルが含まれ、インストール時に登録が自動的に実行されます。 したがって、ここで紹介するコマンドライン呼び出しは、主にテストやデバッグ、たとえば--agent-labels <KEY=VALUE> オプションを使用して独自のエージェントラベルを試す場合などに使用します。

ここでの最大の違いは、Checkmk サイトでの新しいホストの登録と作成を要求するために使用される、変更されたregister-new サブコマンドです。 ホストの名前は、$HOSTNAME 環境変数に保存されている名前です。 その後の証明書の確認は、前のセクションで示したとおりです。

ホストが プルモード プッシュモードで作成されるか、まったく作成されないかは、Agent registration ルールセットの設定によって決まります。 登録が正常に完了した後、ホストが監視に表示されるまで数分かかる場合があります。

cmk-agent-ctl status コマンドは、Checkmk サーバーとの信頼関係を 1 つだけ正確に表示します。

マシン読み取り可能な形式で情報が必要な場合は、追加パラメーター--json を付加して、JSON オブジェクト形式で出力された結果を取得します。

注記:ホストとサイト間の信頼関係は 1 つしか存在できません。 たとえば、すでに登録されているホストmynewhost を、別の名前 (mynewhost2) で同じ IP アドレスで登録すると、新しい接続が既存の接続に置き換わります。mynewhost からサイトへの接続は切断され、監視用のエージェントデータはホストに供給されなくなります。

複数のホストを簡単に登録するために、エージェントがインストールされているホストは、他のホストに代わって登録を行うことができます。 登録プロセスでは、JSON ファイルがエクスポートされ、そのファイルをターゲットホストに転送してインポートすることができます。 ここでも、前述と同様に、ジョブに登録されているホストは、サイト上にすでに設定されている必要があります。

まず、セットアップの任意のホストで、プロキシによる登録を行います。 ここでは、通常、最初にセットアップされるホストである Checkmk サーバーが役立ちます。 上記の例と同様に、--password オプションを省略すると、パスワードをオプションで渡すか、対話形式で入力するよう求められます。 この例では、JSON 出力をファイルにリダイレクトしています。

次に、/tmp/mynewhost3.json ファイルを登録したホストに転送し、そのファイルをインポートします。

このプロセスは、cmk-agent-ctl proxy-register の出力をssh hostname cmk-agent-ctl import の入力として渡すパイプラインを使用することで、1 つのステップで実行することもできます。

登録が完了したら、Checkmk サーバーのセットアップで接続テストとサービスディスカバリーを実行します。 最後に、変更をアクティブにして、ディスカバリーされたサービスを監視に含めます。

接続テストが失敗した場合は、次の章でテストおよびトラブルシューティングに関する情報を参照してください。

ホストの登録を解除することもできます。

Checkmk サーバーに接続されているホストでは、信頼を取り消すことができます。 ここでは、次のコマンドで、cmk-agent-ctl status コマンドによって出力される UUID (Universally Unique Identifier) を指定します。

ホストからのすべての接続を削除し、さらにレガシープルモードを復元するには、次のコマンドを入力します。

その後、エージェントは、最初のインストール後、最初の登録前の状態と同じように動作し、データを暗号化せずに送信します。

Checkmk サーバーで登録の解除を完了します。 セットアップの「Properties of host 」ページで、「Host > Remove TLS registration 」メニュー項目を選択し、プロンプトを確認します。

コマンドラインを使用する場合は、次のように入力します。 Checkmk サーバーでは、監視対象のホストの各接続に対して、エージェントの出力があるフォルダを指す UUID を含むソフトリンクがあります。

Checkmk Cloud以降では、ホストをプッシュモードからプルモードに、またはその逆に切り替えることができます。 これは、ネットワークトポロジの変更が保留中である場合、またはプルモードのみ可能なCheckmk Enterpriseへのダウングレードを行う場合に、個別に必要な場合があります。

まず、セットアップのホストのプロパティで、Checkmk agent connection mode オプションを使用してアクセスモードを指定します。 1 分以内に、監視データを受信していないため、すべてのサービスがUNKNOWNステータスになります。 次に、再登録を実行します。 この再登録中に、Checkmk サーバーのエージェントレシーバーは、エージェントコントローラーに、プルモードでデータを期待するか、プッシュモードでデータを期待するかを伝えます。 その後、cmk-agent-ctl status を使用してチェックを行うと、新しい UUID と、セットアップでの変更と一致するモードが表示されます。

エージェントスクリプトは、システム上のデータを取得し、それを大まかな形式のテキストとして出力する単純なシェルスクリプトです。 このスクリプトは、コマンドラインから直接呼び出すことができます。 出力はビット長くなる場合があるため、出力をスクロールするオプションless が非常に便利です。 Q キーで終了できます。

これにより、エージェントスクリプト、プラグイン、およびローカルチェックが正しくインストールされているかどうかをテストできます。

ちなみに、エージェントを呼び出すには、root である必要はありません。 ただし、その場合は、root 権限が必要な情報 (マルチパス情報やethtool の出力など) が出力されません。

非アクティブなプラグインやコマンドからのエラー出力が、必要なデータを「汚染」することを防ぐため、エージェントスクリプトは通常、標準エラーチャンネル (STDERR) を抑制します。 特定の問題を探している場合は、エージェントスクリプトを特別なデバッグモードで呼び出すことで、STDERR を再度有効にすることができます。

その前に、エージェントスクリプトとダンプモードのエージェントコントローラーの出力が同じであることを確認し、必要に応じて環境を同一にしてください。 これは、プラグイン/ローカルチェックまたはシェルで変数を設定することで実行できます。 環境のダンプを作成するには、プラグインファイルに次の行を追加し、エージェントコントローラーによる実行後にファイルの内容をチェックします。

をプラグインファイルに追加し、エージェントコントローラーによる実行後にファイルの内容を確認することで作成できます。

追加のデバッグ情報は、-d オプションを使用して出力されます。 スクリプトによって実行されたすべてのシェルコマンドも出力されます。 ここでless を使用するには、標準出力 (STDOUT) とエラーチャンネルを2>&1 で結合する必要があります。

証明書が提示される前にホストの登録に失敗した場合、通信方法に関する知識があれば、問題の特定、そしてもちろんその解決にも役立ちます。

cmk-agent-ctl register コマンドを入力すると、エージェントコントローラーはまず、REST API を使用して Checkmk サーバーにエージェントレシーバーポートを問い合わせます。 次に、エージェントレシーバーへの接続を確立し、証明書を要求します。curl などのプログラムを使用して、ホストでの最初の要求をシミュレートすることができます。

パラメータ--insecure は、証明書チェックをスキップするようにcurl に指示します。 この動作は、このステップにおけるエージェントコントローラーの動作を反映しています。 応答は、エージェントレシーバーのポート番号を含む数バイトのみです。 最初のサイトでは通常、8000 、2 番目のサイトでは8001 というように続きます。

このリクエストに関する一般的な問題は次のとおりです：

上記のリクエストが失敗した場合、ルーティング設定またはファイアウォール設定を変更してアクセスを許可してください。

登録しようとしているホストが HTTP プロキシを使用している場合、curl はそのプロキシを使用しますが、cmk-agent-ctl はデフォルト設定では使用しません。cmk-agent-ctl にシステム設定で設定されたプロキシを使用するように指示するには、追加の--detect-proxy オプションを使用してください。

ただし、多くの場合、エージェントレシーバーのポートを見つけてメモしておく方が簡単です。 そのためには、Checkmk サーバーで、サイトユーザーとしてログインして、次のように実行してください。

これで、登録用のコマンドを入力する際にポートを指定することができます。 これにより、REST API への最初のリクエストがスキップされます。 その後、通信は迂回することなく、エージェントレシーバーと直接行われます。

ポート 8000 もホストからアクセスできる必要があります。 アクセスできない場合は、次のエラーメッセージが表示されます。

ポート 443 （それぞれ 80） に相当します。上記と同様に、登録するホストがエージェントレシーバーのポート（8000 または 8001…​）で Checkmk サーバーにアクセスできるように、ルーティングまたはファイアウォールの設定を調整してください。

プッシュモードで登録した場合、以下が適用されます。 登録が正常に完了すると、エージェントの出力は 1 分ごとに正常に転送されます。

お使いの環境のセキュリティポリシーによりエージェントレシーバーへのアクセスが許可されていない場合でも、Checkmk サーバーでプロキシによる登録を使用することができます。

エージェントコントローラーには、監視に届いたエージェントの出力をすべて表示する独自のサブコマンド「dump 」があります。

これにより、エージェントスクリプトからのデータがエージェントコントローラーに到達したことを確認できます。 この出力は、エージェントがネットワークからもアクセス可能であることを証明するものではありません。

一部のケースでは、出力は次のように表示されます:

これは、エージェントソケットがバックグラウンドで実行されていない場合、たとえば、更新の直後に発生します。 このバックグラウンドプロセスを再起動してください。

cmk-agent-ctl dump が再び失敗した場合は、ポート 6556 でリスニングしているプログラムがあるかどうか、およびそのプログラムを確認してください。

出力が空の場合、または括弧内にcmk-agent-ctl 以外のコマンドがある場合、エージェントコントローラーを使用するためのシステム要件が満たされていません。 この場合、記事「レガシーモードで Linux をモニターする」の説明に従ってセットアップを完了してください。

プルモードで、エージェントスクリプトとそのインストール済みプラグインが正しく実行されていることを確認したらnetcat (またはnc) を使用して、ホストの外部 IP アドレスからポート 6556 にアクセスできるかどうかを確認します。

16 の出力は、接続が正常に確立され、TLS ハンドシェイクを実行できることを示しています。 ここでは、その他はすべて TLS 暗号化されているため、より詳細なチェックは不可能です。

リモート接続テストが失敗した場合は、通常、ファイアウォールの設定が原因です。 この場合、iptables またはnftables を設定して、Checkmk サーバーからの TCP ポート 6556 へのアクセスを許可してください。

エージェントと Checkmk サーバー間の通信が依然として暗号化されていない場合（レガシープルモードの場合）、または暗号化されておらず、今後も暗号化されない場合（レガシーモードの場合）、 このコマンドは、16 の代わりに、暗号化されていないエージェントの出力をすべて表示します。

注：Checkmk サーバーで実行するその他の診断については、監視エージェントに関する一般的な記事をご覧ください。

Checkmk サイトの~/var/agent-receiver/received-outputs/ フォルダには、登録されている各ホストの UUID を名前としたソフトリンクがあります。 プッシュモードのホストの場合、このソフトリンクはエージェントの出力があるフォルダを指し、プルホストの場合は、監視で使用されているホスト名と同じ名前の存在しないファイルを指します。

キャッシュされたエージェント出力の保存期間に基づいて、定期的な送信が正常に実行されたか、または、例えば、断続的なネットワークの問題によって中断されているかを判断することができます。

さらに、systemctl status cmk-agent-ctl-daemon コマンドを使用して、ホストでの最新の送信および送信の試みのステータスを表示することができます。 次のような行は、接続の問題を示しています。

Agent controller auto-registration ルールセットでホストが自動登録するように設定されており、Keep existing connections オプションがno に設定されている場合、cmk-agent-ctl-daemon サービスが再起動されるたびに (ホストが再起動された場合など)、自動登録用に設定された接続を除く、他のすべての接続が削除されます。 これは、ベイクドエージェントパッケージのインストール前に複数のサイトへの接続が設定されていたホスト、またはエージェントパッケージのインストール後に手動で接続が追加されたホストなどに影響します。

この動作は、ホストのC:\ProgramData\checkmk\agent\pre_configured_connections.json ファイルで、keep_existing_connections 変数をtrue に設定することで一時的に無効にできます。 エージェントパッケージのアップデート後もこの設定を永続的に有効にするには、上記のルールセットでKeep existing connections をyes に設定してください。

ホストを自動登録する場合、通常、ホストが監視に表示されるまでに約 2 分かかります。

プッシュモードで初期設定されていたホストに、その後プルモードで別のサイトへの接続が追加された場合、ポート 6556 が開かれるまでに最大 5 分かかります。cmk-agent-ctl-daemon サービスを再起動すると、ポートをすぐに開くことができます。

セキュリティは、あらゆるソフトウェアにとって重要な基準であり、監視も例外ではありません。 監視エージェントは、監視対象のすべてのサーバーにインストールされるため、セキュリティ上の問題が発生した場合、特に深刻な結果につながります。

そのため、Checkmk の設計ではセキュリティが重視され、Checkmk の初期段階から絶対的な原則となっています。 エージェントはネットワークからデータを読み取りません。 つまり、攻撃者が監視ポート 6556 経由でコマンドやスクリプトコンポーネントを注入することは不可能です。

しかし、攻撃者にとっては、プロセスリストでさえ、価値のあるターゲットについて結論を導き出すための最初の手がかりになる可能性があります。 そのため、Checkmk バージョン2.1.0 以降では、エージェントと Checkmk サーバー間のトランスポート暗号化に Transport Layer Security (TLS) の使用が義務付けられています。 ここでは、Checkmk サーバーが監視対象のホストに「ping」を送信し、監視対象のホストが Checkmk サーバーへの TLS 接続を確立して、エージェントの出力をその接続を介して送信します。 信頼関係のある Checkmk サーバーのみがこのデータ転送を開始できるため、データが不正な手に渡る危険はありません。

TLS 接続のセキュリティを確保するため、Checkmk は自己署名証明書を使用し、有効期限が切れる直前に自動的に置き換えられます。 エージェントコントローラーは、有効期限が切れる前に、証明書の更新を適時に実行します。 長期間、つまりエージェントコントローラーが実行されていない状態で非アクティブだったエージェントのみ、有効期限が切れると登録が失われ、再度登録する必要があります。 証明書の有効期間は、Agent Certificates > Lifetime of certificates のグローバル設定で指定できます。

認可された Checkmk サーバーのみデータ取得が可能であり、未認可のサーバーは数バイトのハンドシェイク後に失敗するため、サービス拒否 (DoS)攻撃のリスクは極めて低いです。 このため、現時点では、これ以上のアクセス制限は予定されていません。 もちろん、iptables を使用して、不正アクセスからポート 6556 をブロックすることは可能です。 特定の IP アドレスへのアクセスを制限するために、エージェントベーカリーを介してクライアントに転送されたルールは、エージェントコントローラーによって無視されます。

特にエージェントを更新する場合、エージェントスクリプト自体によって実行されるビルトイン（対称）暗号化が有効になっていることがあります。 TLS 暗号化とビルトイン暗号化が同時に有効になっている場合、送信データのエントロピーが非常に高くなり、2.1.0 以降で有効になっている圧縮機能では送信データを保存できなくなります。また、ホストと Checkmk サーバーの両方の CPU に、追加の暗号化および復号化プロセスによる負荷がかかります。

このため、TLS に切り替えた後は、ビルトイン暗号化を速やかに無効にしてください。

まず、Setup > Agents > Access to agents > Checkmk agent > Symmetric encryption (Linux, Windows) の既存のルールで暗号化を無効にしてください。

次に、エージェントのホストで/etc/check_mk/encryption.cfg 設定ファイルの名前を変更します。

3 番目の最後のステップでは、Enforce agent data encryption ルールを使用して、Checkmk サーバーが TLS 経由で暗号化されたデータのみを受け入れるように指定します。 これを行うには、ルールで「Accept TLS encrypted connections only 」の値を選択します。

エージェントベーカリーで暗号化を無効にする手順は、次のとおりです。 最初のステップ、Symmetric encryption (Linux, Windows) ルールを変更すれば、ほぼ完了です。 新しいエージェントをパッケージ化して配布するだけです。 設定ファイル/etc/check_mk/encryption.cfg は自動的に変更され、エージェントパッケージに含まれます。 あとは、3 番目のステップ、Enforce agent data encryption ルールを変更するだけです。

次の自動エージェント更新後に、エージェントスクリプトの暗号化は使用不能になりますが、エージェントコントローラーによって暗号化は保証されます。 自動エージェント更新後は、登録済みのホストのみ監視データを提供できることにご注意ください。

/usr/bin/check_mk_agent エージェントスクリプトには、サービスディスカバリーによって自動的に検出されるさまざまなチェックプラグインの監視データを提供する一連のセクションが含まれています。 これには、オペレーティングシステムに関する重要な監視がすべて含まれています。

さらに、エージェントプラグインを使用してエージェントを拡張することもできます。 エージェントプラグインは、エージェントによって呼び出される小さなスクリプトまたはプログラムで、追加の監視データを含むセクションを追加してエージェントを拡張します。 Checkmk プロジェクトでは、このようなプラグインをシリーズで提供しています。これらのプラグインを正しくインストールおよび設定すると、サービスディスカバリーによって新しいサービスが自動的に提供されます。

これらのプラグインは、エージェントにハードコードされていないのはなぜですか？ プラグインには、以下のいずれかの理由があります。

Linux および Unix に付属のプラグインは、Plugins ボックスのセットアップメニュー（インストール章で説明）のエージェントダウンロードページにあります。

当社が提供するすべてのエージェントプラグインには、エージェントのデータを評価してサービスを作成できる、一致するチェックプラグインがあります。 これらはすでにインストールされているため、新しく見つかったサービスをすぐに検出して設定することができます。

注：ホストにプラグインをインストールする前に、対応するファイルを確認してください。 多くの場合、プラグインの正しい使用方法に関する重要な情報が記載されています。

実際のインストールは簡単です。 ファイルを/usr/lib/check_mk_agent/plugins にコピーします。 実行可能になっていることを確認してください。 実行可能になっていない場合は、chmod 755 を使用してください。そうしないと、エージェントはプラグインを実行しません。 特に、scp 経由でファイルを転送せず、ダウンロードページから HTTP 経由でファイルを取得した場合は、実行許可が失われることにご注意ください。

プラグインが実行可能になり、正しいディレクトリにあると、エージェントによって自動的に呼び出され、エージェント出力に新しいセクションが作成されます。 このセクションは通常、プラグインと同じ名前になります。mk_oracle などの複雑なプラグインでは、一連の新しいセクションがすべて作成されます。

一部のプラグインは、動作するために/etc/check_mk/ に設定ファイルが必要です。 その他のプラグインでは、設定はオプションであり、特別な機能やカスタマイズを有効にします。 さらに、そのままの状態で動作するプラグインもあります。 プラグインに関する情報は、いくつかの情報源から入手できます。

エージェントプラグインは通常、順番に実行されます。 あるいは、プラグインを非同期で実行することもできます。 これは、プラグインのランタイムが長く、収集されるステータスデータを 1 分ごとに再生成する必要がない場合に非常に便利です。

非同期実行はファイルで設定しません。代わりに、/usr/lib/check_mk_agent/plugins ディレクトリ内に、秒数に対応する数値を名前としたサブディレクトリを作成します。 このディレクトリにあるプラグインは、非同期で実行されるだけでなく、プラグインが再び実行されるまでの最小待機時間も秒単位で指定します。 この時間が経過する前にエージェントが再度クエリされた場合、プラグインは前回実行時にキャッシュされたデータを使用します。 これにより、プラグインの実行間隔を通常の 1 分よりも長く設定することができます。

次の例は、my_foo_plugin プラグインを、同期実行から 5 分 (300 秒) の間隔の非同期実行に変更する方法を示しています。

注:一部のプラグインは、非同期実行を自動的に実装しています。 これには、mk_oracle が含まれます。 このようなプラグインは、/usr/lib/check_mk_agent/plugins に直接インストールしてください。

商業版では、付属のプラグインはエージェントベーカリーを使用して設定できます。 これにより、実際のプラグインのインストールと、必要に応じてその設定ファイルの正しい作成の両方が行われます。

各プラグインは、エージェントルールを使用して設定されます。 適切なルールセットは、Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Agent Plugins にあります。

エージェントプラグインは実行可能なプログラムであるため、テストや診断の目的で手動で実行することもできます。 ただし、プラグインの中には、設定ファイルを見つけるためにエージェントによって特定の環境変数が設定されているものもあります。 実行前に、これらの変数を手動で設定してください。

一部のプラグインは、デバッグ用に特別な呼び出しオプションも使用します。 プラグインファイルを確認してください。

Checkmk で Nagios プラグインを引き続き使用するには、2 つの理由があります。 Nagios ベースのソリューションから Checkmk に監視を移行した場合、Checkmk に同等の機能がない古いチェックプラグインを引き続き使用することができます。 多くの場合、これらは Perl またはシェルで自作したプラグインです。

2 つ目の理由は、真のエンドツーエンド監視です。 Checkmk サーバー、web サーバー、データベースサーバーが、大規模なデータセンターに分散して配置されている場合を考えてみましょう。 このような場合、Checkmk サーバーから測定されたデータベースサーバーの応答時間はあまり意味がありません。 web サーバーとデータベースサーバー間の接続の応答時間を把握することが、はるかに重要です。

Checkmk エージェントは、この 2 つの要件を満たすシンプルなメカニズムを提供しています。 MK のリモートプラグインエクゼキュータ、略してMRPEです。 この名前は、Nagios で同じタスクを実行するNRPEに意図的にちなんで付けられました。

MRPE はエージェントにビルトインされており、/etc/check_mk/mrpe.cfg という名前の簡単なテキストファイルで設定します。 このファイルには、1 行に 1 つのプラグイン呼び出しと、Checkmk が自動的に作成するサービスに使用する名前を指定します。 以下に例を示します。

注：Nagios プラグインは、/usr/lib/check_mk_agent/plugins ディレクトリには配置しないでください。 このディレクトリは、エージェントプラグイン用に予約されています。 このディレクトリ以外であれば、エージェントがプラグインを見つけて実行できる場所なら、任意の場所を選択できます。

ここでエージェントをローカルで実行すると、<<mrpe>> という新しいセクションがプラグインごとに作成され、プラグインの名前、終了コード、およびプラグインからの出力が表示されます。 これは、次の便利なgrep コマンドで確認できます。

出力の「0 」および「1 」は、プラグインの終了コードを表し、以下の慣例に従っています。0 =OK 、1 =WARN 、2 =CRIT 、3 =UNKNOWN。

あとは Checkmk によって自動的に行われます。 ホストのサービスディスカバリーを呼び出すと、2 つの新しいサービスが利用可能として表示されます。 次のように表示されます。

なお、ファイルの構文上、名前にはスペースを含めることができません。 ただし、URL と同じ構文（スペースの ASCII コード 32 は 16 進数で 20）を使用して、スペースを%20 に置き換えることができます：

mrpe.cfg にリストしたすべてのプラグインは、順番に同期して実行されます。 このため、プラグインの実行時間はあまり長くしないでください。 1 つのプラグインの実行に時間がかかりすぎると、他のすべてのプラグインの実行が遅れます。 その結果、エージェントスクリプトの実行がタイムアウトになり、ホストを確実に監視できなくなる可能性があります。

実行に時間がかかるプラグインをどうしても使用する必要がある場合は、通常のエージェントプラグインと同様に非同期実行に切り替えて、このような問題を回避してください。 これは、計算結果の有効期間を秒単位で指定することで実現できます。 タイムアウトを 5 分に設定するには、mrpe.cfg のサービス名の後に、(interval=300) という式を設定します。

この機能には、いくつかの利点があります。

これにより、Checkmk サーバーで何も設定することなく、より長い時間間隔で、より多くの計算時間を必要とするテストを実行することができます。

商業版のユーザーは、エージェントベーカリーを使用して MRPE を設定することもできます。 これは、ルールセットSetup > Agents > Windows, Linux Solaris, AIX > Agent Rules > Generic Options > Execute MRPE checks で設定します。ここでは、上記と同じ設定を行うことができます。 ファイルmrpe.cfg は、エージェントベーカリーによって自動的に生成されます。

最近のハードドライブには、ほぼ必ずS.M.A.R.T.(Self-Monitoring, Analysis and Reporting Technology) が搭載されています。 このシステムは、HDD または SSD の状態に関するデータを継続的に記録し、Checkmk はsmart プラグインを使用してこれらの値を取得し、その中から最も重要なものを評価します。 プラグインをインストール後に機能させるには、以下の要件を満たしている必要があります。

これらの要件が満たされ、プラグインがインストールされている場合、データは自動的に取得され、エージェントの出力に追加されます。 Checkmk では、新しいサービスを直接有効化することもできます。

スクリーンショットのように、cmd_timeout が時折発生する場合は、プラグインを数分間隔の非同期実行に切り替えてください。

IPMI (Intelligent Platform Management Interface) は、ハードウェアの管理および監視を可能にするインターフェイスです。 Checkmk は、この目的のためにfreeipmi を使用して、ネットワークを経由せずにハードウェアに直接アクセスします。freeipmi はパッケージソースからインストールするとすぐに使用でき、Checkmk が次に呼び出されたときにデータが送信されます。

freeipmi が利用できない場合や、その他の理由でインストールできない場合は、ipmitool を使用することもできます。ipmitool は多くの場合、システムにすでにインストールされており、openipmi パッケージなどの IPMI デバイスドライバをインストールするだけで使用できます。 この場合も、インストール後に追加の作業は必要なく、データは Checkmk によって自動的に収集されます。

エラー診断のために、ホストシェルでツールを手動で実行することもできます。freeipmi パッケージをインストールしたら、次のようにしてその機能を確認できます。

ipmitool がインストールされている場合は、次のコマンドでデータの出力をチェックできます。

多くの大手サーバーメーカーは、ハードウェア情報を収集し、SNMP 経由で利用可能にする独自のツールも提供しています。 このデータを取得して Checkmk に提供するには、以下の前提条件を満たしている必要があります。

これにより、サポートされているハードウェア監視用の新しいサービスが自動的に検出され、追加のプラグインは必要ありません。

各ホストに管理ボードを設定し、SNMP 経由で追加データを取得することができます。 この方法で検出されたサービスは、ホストにも割り当てられます。

管理ボードの設定は非常に簡単です。 ホストのプロパティに SNMP のプロトコル、IP アドレス、およびアクセスデータを入力し、新しい設定を保存してください。

サービスディスカバリーにより、新しく検出されたサービスは通常どおり有効になります。

エージェントがアンインストールされると、インストールスクリプトによって作成されたcmk-agent ユーザーは保持されます。 これは、このシステムにエージェントがすでにインストールされていることを、インストール後スクリプトに知らせる指標となります。 この場合、その後の再インストールではレガシープルモードは有効になりません。 その結果、cmk-agent-ctl delete-all を実行してからエージェントを再インストールすると、ポート 6556 への接続は不可能になります。

暗号化されていないレガシープルモードを再度有効にする場合は、このモードを明示的に有効にする必要があります。