 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. 概要
2000 以上の既製のチェックプラグインと 、ファイルおよびフォルダの内容の監視、 ログメッセージの評価 、定期的なタスクの監視を行う複数の方法を備えた Checkmk は、さまざまな監視タスクに最適な、すぐに使えるソリューションです。 非常に特殊な用途向けのプラグインがない場合は、Checkmk コミュニティがCheckmk Exchange を通じてカスタム開発のお手伝いをいたします。
しかし、ハードウェアが新しすぎる、ソフトウェアがあまり知られていない、組織独自の開発が個別すぎて、Checkmk への統合の必要性をまだ誰も認識していないという状況も、常にあります。 そのような場合は、独自の拡張機能のプログラミングを開始してください。
この記事では、利用可能なオプションの概要を説明します。
これらのオプションは多岐にわたります。 たとえば、Checkmk で簡単に表示できるフォームで成功または失敗を出力するために、バックアップスクリプトを数行拡張するだけで十分な場合もあります。つまり、「社内開発」は、場合によってはわずか数分で完了する場合もあります。 また、負荷状況を詳細なグラフで視覚化する必要がある場合もあります。このような状況では、数時間余分に投資する価値があります。
2. 独自のプログラムを使用した拡張の可能性
以下のセクションでは、独自の拡張機能を Checkmk に統合するための手順、および各ケースにおけるデータ収集と評価の実施場所について説明します。
2.1. ローカルチェック
Checkmk を拡張する最も簡単な方法は、ローカルチェックを使用することです。 監視対象ホストのエージェントスクリプトによって実行されるプログラムが、名前、状態、およびその他の必要な情報を 1 行で出力します。 ローカルチェックの場合、Checkmkは自動サービスディスカバリーをサポートしています。 API を習得する必要はなく、あらゆるプログラミング言語でプログラミングが可能です。
実行：監視対象のホスト上で完全に実行されます。必要に応じて、ローカルチェックを受けるすべてのホストで適切なインタープリタが利用可能になっていることを確認してください。
閾値：下限と上限の閾値（それぞれWARN およびCRIT への移行用）のペアを、Checkmkサイトで管理できます。
メトリック：サービスごとに複数のメトリックを使用できます。単位は明示的に管理することはできませんが、自動的に割り当てられるか、または省略されます。
2.2. ネイティブエージェントベースのチェックプラグイン
エージェントベースのチェックプラグインは、Checkmk エージェントから提供されたデータを評価します。 エージェントプラグインは、生データを収集して事前フィルタリングを行いますが、収集したデータの分析は実行しません。 このデータ収集は、任意のプログラミング言語で実行できます。 JSON ファイルまたは CSV 形式での出力は、非常に一般的です。 ただし、Linux システムのコマンドのみを呼び出すエージェントプラグインも数多くあります。
その後、Checkmk の API を使用した Python で記述されたチェックプラグインにより、Checkmk サーバー上で評価が行われます。 これにより、ステータスを非常に柔軟に決定することができます。 下限および上限の閾値を使用することができます。 さらに、複数のサービスを作成し、複数のチェックによってサービスのステータスを確認することができます。 また、傾向を判断し、古い値を含めることも可能です。 ネイティブチェックプラグインは、ラベルの自動作成とHW/SW インベントリをサポートしています。
実行：監視対象のホスト上の任意のプログラミング言語でデータ収集を行うエージェントプラグイン、Checkmk サーバー上のチェックプラグインによる Check API を使用したさらなる評価。
閾値：各サービスに対する閾値の任意の組み合わせ。
メトリック：サービスごとに、単位付きメトリックをいくつでも設定できます。
2.3. スペシャルエージェント
エージェントベースのチェックプラグインの拡張機能が、スペシャルエージェントです。 ここでは、エージェントプラグインが生データを収集するのではなく、Checkmk サーバー上で実行されているプログラムが別のソースからデータを取得し、Checkmk のエージェント形式に変換します。 スペシャルエージェントは、たとえば、監視対象デバイスが REST API 経由で JSON または XML 形式で監視に関連するデータを提供する場合に使用されます。 Checkmk で提供されるスペシャルエージェントの使用例については、AWS、Azure、またはVMware を参照してください。
プログラミングでは、2 つの API にアクセスします。ポートなどの設定については、Checkmk は、セットアップでそのような設定を指定できる API を提供しています。 データクエリ自体については、外部ソースの REST API を使用してください。 Checkmk サーバーでの評価は、前のセクションで説明したネイティブチェックプラグインと同様に行われます。
実行：Checkmk サーバーでのデータ収集およびさらなる評価のためのプログラム/スクリプト。
閾値：各サービスに対する閾値の任意の組み合わせ。
メトリック：サービスごとに、単位付きメトリックをいくつでも指定できます。
2.4. ネイティブ SNMP ベースのチェックプラグイン
エージェントベースのチェックプラグインのバリエーションとして、SNMP 用のチェックプラグインがあります。 このプラグインとの違いは、エージェントセクションが要求および評価されない代わりに、特定の SNMP OID が SNMP エージェントによって明示的に要求されることです。
実行：Checkmk サーバー上のチェックプラグインが、Check API を使用してデータ収集とさらに評価を行います。
閾値：各サービスに対して任意の閾値の組み合わせを設定できます。
メトリック：サービスごとに、単位付きメトリックをいくつでも指定できます。
SNMP プロトコルは本質的に非常に非効率的であるため、監視データに他の方法でアクセスできない場合にのみ SNMP を使用することをお勧めします。 たとえば、デバイスが REST API を通じて同じデータも提供している場合は、そのデバイス用にスペシャルエージェントを構築する必要があります。
2.5. レガシー Nagios チェックプラグイン
Nagios チェックプラグインは、Checkmk の 2 箇所で確認できます。 アクティブチェックとして、Checkmk サーバーからの特定のサービスのアクセス可能性をチェックするため、およびホストからそのようなサービスをチェックするためのWindowsまたはLinuxエージェントのMRPE 拡張機能として（ホスト/サービスが Checkmk サーバーからアクセスできない場合）。
プログラミングは任意の言語で可能です。
実行：監視対象のホスト上で完全に（MRPE 経由）、または Checkmk サーバー上で完全に（アクティブチェック）。
閾値：アクティブチェックとして使用する場合にのみ閾値。
メトリック：アクティブチェックとして使用する場合のみメトリック。
トラブルシューティングが面倒であるなどの多くの欠点があるため、Nagios との完全な互換性が必要な場合にのみ、再実装をお勧めします。 それ以外の場合は、ネイティブチェックプラグインを使用するか、単純なクエリの場合はローカルチェックを使用してください。 出力形式の詳細については、Monitoring-Plugins.org をご覧ください。
3. 追加記事
3.1. スプールディレクトリ
Checkmk には、エージェントデータを生成するためのもう 1 つのメカニズムがあります。 プログラムで、Checkmk エージェント形式のテキストファイルを直接書き込むのです。 スプールディレクトリに保存されたこのファイルの内容は、Checkmk エージェントによって他のエージェント出力とともに転送されます。
スプールディレクトリを使用すると、たとえば、バックアップスクリプトで、ローカルチェックまたはチェックプラグインのステータスと統計情報を、完了直後に直接書き込むことができます。 これにより、ログファイルの評価という余分な作業が省けます。
独自のチェックプラグインを開発する場合、スプールファイルは、エージェントプラグインからの特定の出力をシミュレートするのに役立ちます。
3.2. ピギーバックメカニズム
ピギーバックメカニズムは、あるホストが別のホストに関する情報を持っている場合に使用されます。 エージェントの出力を評価する際に、特別にフォーマットされたエージェントセクションが関連するホストに割り当てられます。
仮想マシンの場合、ピギーバックメカニズムは、仮想化ソフトウェアによって収集されたデータを、仮想マシン内の監視データとマージするために使用されます。
3.3. Checkmk 拡張パッケージ (MKP)
独自の拡張機能をプログラムし、そのバージョン管理と転送を行いたい場合は、拡張機能と関連ファイルをCheckmk 拡張パッケージ (MKP) にバンドルすることができます。 また、Checkmk Exchange でこれらの拡張機能を提供したい場合も、このパッケージ形式を使用する必要があります。
3.4. ベーカリー API
多くの場合、エージェントプラグインに追加の設定を提供したいでしょう。 あるいは、Checkmk の設定に応じて特定のインストールスクリプトレットを実行したい場合もあります。
エージェントパッケージの配布にエージェントベーカリーを使用する場合、ベーカリー APIにより、Checkmk で行った設定を監視対象の他のホストに簡単に転送できるプログラミングインターフェースが提供されます。
4. Checkmk への貢献
独自の拡張機能をプログラムする場合は、まずCheckmk Exchange に提出することをお勧めいたします。 ここでは、お客様が所有者および連絡先となり、新しいバージョンを簡単に提供することができます。 Exchange のコーディング品質要件は、Checkmk に付属のチェックプラグインほど厳しくありませんので、Exchange を通じて、幅広いユーザーに新しいアイデアを簡単に試すことができます。
チェックプラグインを Checkmk の不可欠な機能として組み込むべきだと考えた場合は、まず「Checkmk への貢献」ドキュメントをお読みください。