OpenShift の監視

OpenShift クラスタは、個々のコンポーネントの数や配置が短時間で大きく変化する場合があるため、OpenShift 環境の監視には別の Checkmk サイトを作成することをお勧めします。 このサイトは、分散監視の手順に従って、通常どおりセントラルサイトに接続することができます。

Checkmk は、2 つの方法で OpenShift クラスタを監視します。

まず、OpenShift クラスタで Checkmk 用の名前空間とサービスアカウントを設定する必要があります。 最も簡単な方法は、OpenShift CLI (略称oc ) を使用することです。

以下の例では、この名前空間に「checkmk-monitoring 」という名前を付けます。 別の名前を選択したい場合や選択する必要がある場合は、サービスアカウントの作成時にもこの変更を行う必要があります。

関連付けられたロールと、いわゆる RoleBinding を持つサービスアカウントは、GitHub で公開されている既製のYAML ファイルを使用して作成できます。 その内容を確認し、次のコマンドを実行してください。

または、この YAML ファイルをダウンロードし、必要に応じてカスタマイズしてから、oc apply -f をこのローカルコピーのファイルに適用することもできます。

oc コマンドラインツールを使用すると、通常、スペシャルエージェントの設定で指定する必要のある、クラスタのすべての情報を読み出すこともできます。 サービスアカウント名または名前空間を変更した場合は、以下のコマンドの説明に従って、この情報を編集する必要があります。

サービスアカウントのパスワード（トークン）は、Checkmk パスワードストアに保存することをお勧めします。 これにより、パスワードの保存と使用を整理して分離できるため、最も安全な方法です。 あるいは、ルールを作成する際にパスワードをプレーンテキストで直接入力することもできます（以下を参照）。

パスワードを Checkmk パスワードストアに追加するには、Setup > General > Passwords > Add password に移動します。 この例では、ID およびタイトルとして「My OpenShift Token 」を使用しています。

Checkmkがサービスアカウントの証明書チェーンを信頼するには、その証明書を Checkmk に保存する必要があります。BEGIN CERTIFICATE およびEND CERTIFICATEを含むすべての行をここにコピーし、[Setup > General > Global settings > Site management > Trusted certificate authorities for SSL] の [セットアップ] メニューで証明書を追加します。

通常どおり Checkmk で新しいホストを作成し、たとえば「myopenshiftclusterhost 」という名前を付けます。 タイトルとホスト名からもわかるように、このホストはピギーバックデータの収集、およびクラスタレベルでのすべてのサービスとメトリックのマッピングに使用されます。 このホストは特別なエージェントを通じてのみデータを受信するため、ホストのプロパティで「IP address family 」オプションを「No IP 」に設定してください。 「Save & view folder 」ボタンを押して、この設定全体を確認してください。

異なる Kubernetes クラスタ内のオブジェクトを確実に分離するために、通常、Setup > Hosts > Add folder を使用してクラスタごとにフォルダを作成し、そのフォルダにダイナミックホストマネージメントがクラスタのすべてのホストを自動的に作成できるようにします。 ただし、このようなフォルダを作成して使用することは任意です。

次に、着信ピギーバックデータの接続を設定します。 これを行うには、Setup > Hosts > Dynamic host management > Add connection.に移動します。 まずタイトルを入力し、[Connection Properties ] で [show more] をクリックします。

次の非常に重要な手順は、Restrict source hosts に、先ほど作成したピギーバックホストを入力することです。

次に、Piggyback creation options で「Add new element 」をクリックし、「Create hosts in 」で、先ほど作成したフォルダを選択します。

Host attributes to set のデフォルトの属性はそのままにしておいてください。 これにより、Checkmk は、自動的に作成されたホストからのピギーバックデータのみを受け入れ、これらのホストに ping を実行したり、SNMP 経由でアクセスしたりすることを試みません。

監視可能オブジェクトおよび監視対象オブジェクトが絶えず増減する OpenShift 環境では、通常、Automatically delete hosts without piggyback data オプションも有効にすることをお勧めします。 このオプションの具体的な機能、およびホストが実際に削除される状況については、ダイナミックホストマネージメントに関する記事の「ホストの自動削除」の章で説明しています。

最後に、Discover services during creation オプションを有効にしてください。

この新しい接続の「Connection Properties 」セクションは、次のように表示されます。

デフォルトでは、Checkmk は 2 時間ごとにサービスディスカバリーを実行し、その結果をCheck_MK Discovery サービスに表示します。 この設定は、Periodic service discovery ルールセットにあります。 OpenShift のコンテキストでは、すべてのホストに対して、ラベルcmk/kubernetes:yes のルールを作成することをお勧めします。 これは、Kubernetes オブジェクトを表すすべてのホストが、Checkmk からこのラベルを自動的に受け取るためです。 この場合、サービスディスカバリーのインターバルは 2 時間よりも短い間隔を選択し、Automatically update service configuration オプションも有効にしてください。 以下のスクリーンショットの設定はあくまで例です。 クラスタごとに、適切な設定をケースバイケースで決定してください。

このルールをクラスタ内のすべてのホストに制限するには、[Host labels ] で、[Conditions] に「cmk/kubernetes:yes 」と入力してください。 ただし、クラスタごとに異なるルールを作成したい場合は、ここでそれぞれのクラスタ固有のラベルを使用してください。 これらのラベルは、常に「cmk/kubernetes/cluster:mycluster 」というフォームになります。

クラスタと Checkmk で必要な準備がすべて完了しましたので、スペシャルエージェントの設定に移ります。 これは、Setup > Agents > VM, cloud, container > Kubernetes から確認できます。Add rule で新しいルールを作成します。

まず、監視するクラスタの名前を割り当てる必要があります。 この名前は、必要に応じて自由に指定できます。 この名前は、この特定のクラスタに由来するすべてのオブジェクトに一意の名前を割り当てるために使用されます。 たとえば、ここに「mycluster 」と入力すると、このクラスタ内のすべてのポッドのホスト名は、後で「pod_mycluster 」で始まるようになります。 ホスト名の次の部分は、この Kubernetes オブジェクトが存在する名前空間になります。 たとえば、ポッドのホスト名は「pod_mycluster_kube-system_svclb-traefik-8bgw7 」になります。

Token で、Checkmk パスワードストアから先ほど作成したエントリを選択します。

API server connection > Endpoint で、Checkmk は、Kubernetes API サーバーに接続するための URL の入力要求を表示します。 ポートは、サービスが仮想ホスト経由で提供されていない場合にのみ必要です。 ここでは、Kubernetes API エンドポイントの取得セクションで決定したアドレスを入力してください。

これまでの手順に従って、クラスタの CA 証明書を Checkmkに保存した場合は、[SSL certificate verification ] で [Verify the certificate] を選択します。

Enrich with usage data オプションを有効にし、次のメニューでUse data from OpenShift を選択し、Prometheus API エンドポイントの取得セクションで決定したPrometheus API endpoint を入力します。

Collect information about…​ の下のリストで、クラスタ内で監視するオブジェクトを選択できます。 このリストには、最も関連性の高いオブジェクトが含まれています。Pods of CronJobs も監視する場合は、このオプションのインラインヘルプを参照してください。

次の 2 つの選択項目では、監視するオブジェクトをさらに絞り込むことができます。 特定の名前空間のオブジェクトのみに関心がある場合は、[Monitor namespaces] で適宜設定してください。 ここでは、監視する個々の名前空間を入力するか、監視から個々の名前空間を明示的に除外することができます。

Cluster resource aggregation オプションを使用すると、クラスタのワークロードにリソースを提供しないノードを指定できます。 これらのノードは、使用可能なリソースの計算から除外する必要があります。 そうしないと、容量のボトルネックが検出されないおそれがあります。 そのため、control-plane およびinfra ノードは、デフォルトで計算から除外されています。

最後のオプションとして、Kubernetes からいわゆるアノテーションをインポートすることができます。 Checkmk では、これらのアノテーションはホストラベルとなり、ルールで条件としてさらに使用することができます。 インポートするアノテーションを指定するには、正規表現を使用してください。 この時点で、詳細なインラインヘルプを再度参照してください。

注： Import all valid annotations オプションは、完全性を期すためにのみここに記載されています。 すべての注釈を一度にインポートすることは、Checkmk に膨大な量の不要なラベルが作成される可能性があるため、お勧めできません。

重要： Conditions > Explicit hosts で、先ほど作成したホスト を入力してください。

次に、ルールを保存し、このホストのサービスディスカバリーを実行します。 最初のクラスタレベルのサービスがすぐにここに表示されます。

次に、行ったすべての変更をアクティブにして、今後はダイナミックホストマネージメントに作業を任せます。 これにより、Kubernetes オブジェクトのすべてのホストが短時間で生成されます。

Checkmk の商業版には、Kubernetes 用の 6 つのビルトインダッシュボードが付属しています。 これらのダッシュボードを理解するには、クラスターコレクターをインストールして設定する必要があります。 具体的には、これらのダッシュボードは次のように呼ばれています。

エントリポイントは常にKubernetes ダッシュボードで、Monitor > Applications > Kubernetes からアクセスできます。

Kubernetes ダッシュボードでは、監視対象のすべてのクラスタが左側にリスト表示されます。 このクラスタのリストは、ダッシュボードをさらに詳しく調べるためのエントリポイントでもあります。 クラスタの名前をクリックすると、選択したクラスタのKubernetes Cluster ダッシュボードに移動します。Kubernetes Cluster ダッシュボードで、それぞれの名前をクリックすると、他のコンテキスト依存のダッシュボードに移動します。

Checkmk による OpenShift の監視では、HW/SW インベントリもサポートされています。 たとえば、上記のクラスタダッシュボードで、クラスタの ID 名（ここではmycluster ）をクリックすると、そのクラスタのインベントリに移動します。

同様に、他のダッシュボードでも、オブジェクトの ID 名のボックスをクリックすると、それぞれのオブジェクトのインベントリを表示できます。 次の例は、ポッドの HW/SW インベントリを示しています。

デフォルトの YAML ファイルを使用してサービスアカウントを作成した場合は、次のようにしてそのアカウントを削除することもできます。