CheckmkはKubernetes監視を公式サポートしています。本記事では監視設定方法詳細について、解説していきます。
はじめに
以前、「【Checkmk KB】コンテナKubernetesを監視する<概要編>」という記事では、CheckmkがサポートしているKubernetesについて、また監視できる項目についてお伝えしました。お読みいただけましたでしょうか。
本記事では、Checkmkサーバーに実際に監視ホストとして登録し、監視するための詳細な設定手順をご紹介します。コマンドラインからの作業とWebGUIからの作業の2つのステップについて画面を見ながら解説していきますので、Kubernetes監視に興味がある方はぜひ本記事を参考に設定してみてください。
設定手順1:【コマンドラインからの作業】
①Helmリポジトリを追加する
Kubernetes監視の設定は「Helmツール」を使用して行っていきます。HelmはLinuxディストリビューションのパッケージの一部で、インストールされていない場合はまずはインストールから行っててください。(インストールコマンド:snap install helm –classic)インストール後、セットアップしていきます。
以下コマンドを実行し、監視対象のKubernetesにhelmリポジトリを追加してください。ここではレポジトリ名を「checkmk-chart」としています。名前は任意です。
user@host:~$ helm repo add checkmk-chart https://checkmk.github.io/checkmk_kube_agent
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/図1-1024x236.png?resize=1024%2C236&ssl=1)
HelmチャートはCheckmkのバージョンごとに更新されることがあります。次のコマンドを使用すると、リポジトリで利用可能なすべてのバージョンのチャートを表示できます。
user@host:~$ helm search repo checkmk-chart --versions
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/図2-1-1024x318.png?resize=1024%2C318&ssl=1)
図2
②設定ファイルの調整と更新
Checkmkコレクタの設定ファイル、values.yamlを編集します。/home/ユーザー名/配下にあります。設定ファイルは手動で必要な個所を更新していきます。デフォルトのままではコレクタへの外部アクセスが不可になっているため、以下(1)(2)を確認し調整してください。
Checkmkがサポートしているアクセス経路は、Ingress経由のクエリとNodePort経由のクエリです。本記事ではシンプルなNodePort経由の設定方法で説明します。
(1)NodePortオプションの変更
service: の設定記載欄を探し、以下を図3のとおり修正してください。
- type: NodePort …ClusterIPから変更する
- nodePort: 30035 …コメントアウトの’#’を外す
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/図3-1024x499.png?resize=1024%2C499&ssl=1)
※Ingress経由で設定したい場合は、service: の設定は何も変更せず、その下のingress: のenabled:をfalseからtrueに変更します。
(2)Helm chartの更新
values.yamlを変更した場合は、必ず以下のコマンドを実行してください。–create-namespaceはここでは「checkmk-monitoring」としています。この引数の名前は任意です。
user@host:~$ helm upgrade --install --create-namespace -n checkmk-monitoring myrelease checkmk-chart/checkmk -f values.yaml
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-4-1024x662.png?resize=1024%2C662&ssl=1)
これで、最新の設定ファイルの内容で更新され、クラスターコレクタが正常にダウンロードされました。これで設定ファイルの編集作業は終了です。
③設定内容の確認
図4のとおり、コマンド実行時の出力には、NOTES:以下に様々なコマンドが記載されています。この複数のコマンドは、次の設定手順2:【WebGUIからの作業】以降の手順で、Kubernetes監視の接続を構成する際に使用します。そのため、一度コマンドを実行して(1)(2)の出力値を確認しておきます。
(1)Nodeポート情報の確認
user@host:~$ export NODE_PORT=$(kubectl get --namespace checkmk-monitoring -o jsonpath="{.spec.ports[0].nodePort}" services myrelease-checkmk-cluster-collector);
user@host:~$ export NODE_IP=$(kubectl get nodes --namespace checkmk-monitoring -o jsonpath="{.items[0].status.addresses[0].address}");
user@host:~$ echo http://$NODE_IP:$NODE_PORT
まず前半のこの3つのコマンドを実行します。結果としてアドレスが取得できますが、これは後でCheckmk WebGUI上で設定するKubernetesルールで、コレクターNodePortに入力する必要があるアドレスになります。(図5赤枠)
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/図4-1024x209.png?resize=1024%2C209&ssl=1)
(2)トークンと証明書の確認
user@host:~$ export TOKEN=$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.token}' | base64 --decode);
user@host:~$ export CA_CRT="$(kubectl get secret myrelease-checkmk-checkmk -n checkmk-monitoring -o=jsonpath='{.data.ca\.crt}' | base64 --decode)";
user@host:~$ echo $TOKEN
user@host:~$ echo "$CA_CRT"
次に、後半のこの4つのコマンドを実行します。これは、トークンと証明書を取得するためのコマンドです。CA_CRTを実行する際は、上記コマンド例の通り、必ず””で囲んでください。証明書の改行が失われ、設定時にエラーとなります。こちらも④以降の手順でAPI接続を設定する際に使用するため、どこかにコピーする、または表示したままにしておいてください。(図6赤枠)
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/図5-1024x724.png?resize=1024%2C724&ssl=1)
事前の準備としては完了です。ここからはCheckmkのWEB側での作業を説明します。
設定手順2:【WebGUIからの作業】
①仮ホストを作成する
データを収集するための仮ホストを作成します。セットアップ>”ホスト”>ホスト
監視する先ではなく監視するデータソースを集めるためのホストのため、IPアドレスなどはありません。ここでは「mykubernetes」とします。ホスト名は任意の名前で、IPアドレスは「No IP」を選択してください。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-18-1024x773.png?resize=1024%2C773&ssl=1)
②各オブジェクトを自動登録する先のフォルダを作成する
Kubernetesで管理しているPod、Node…などを自動登録するためのフォルダを作成します。セットアップ>”ホスト”>ホスト から「フォルダを追加」します。ここでは「k8s-objects」というフォルダ名にしました。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-19-1024x611.png?resize=1024%2C611&ssl=1)
③パスワード(トークン)と証明書の登録
次に、先ほどHelm chartの手順で設定したKubernetes API接続のためのトークンを、パスワードストアに登録します。セットアップ>”一般”>パスワード で新規登録してください。
一意のIDは英語で設定する必要があります。図9赤枠、パスワードのところに、先ほど確認したトークンを登録していきます。echo $TOKENの出力結果(図6上の赤枠)をそのままコピーして貼り付けてください。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-20-1024x746.png?resize=1024%2C746&ssl=1)
次に証明書を登録します。セットアップ>”一般”>グローバル設定の「▼サイト管理」からSSLの信頼できる認証局をクリックします。あらかじめ登録してある証明書がある場合はそれを絶対に消さないで下さい。「新しいCA証明書またはチェーンを追加します」をクリックし、先ほど確認した証明書を登録していきます。echo “$CA_CRT”の出力結果(図6下の赤枠)をそのままコピーして貼り付けてください。改行などが消えるとエラーになりますのでご注意ください。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-21-1024x730.png?resize=1024%2C730&ssl=1)
右上の変更のアクティブ化ボタンを使用し。サイトに適用してください。これで接続関連の設定はひとまず完了です。エラーが出た場合は、改行などを確認してください。
④Specialエージェントの設定
セットアップ>”エージェント”>VM, クラウド, コンテナ の画面で「Kubernetes」を設定していきます。図11を参考に設定していきます。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/図6-1-1024x672.png?resize=1024%2C672&ssl=1)
- クラスター名:任意 (ここでは「mycluster」としています)
- トークン:図9で設定したトークンをパスワードストアより選択
- APIサーバー構成:APIサーバーを記載(図11赤枠1つ目)
- ※わからない場合、CLIよりkubectl config viewコマンドで確認できます
- SSL証明書の検証:確認する
図11赤枠2つ目の設定項目はCheckmk Enterprise Edition かCloud Editionかの利用で異なります。
- Enrich with usage data:⇒※Checkmk Cloud Editionの場合のみ選択可
- 今回はCheckmkクラスターコントローラーを選択
- OpenShiftを監視したい場合は、図11吹き出しの中で
- OpenShiftを選択してください。
- ⇒※Enterprise Editionの場合はOpenShift選択不可
- 共通して、URLにはNodeポートの確認で取得した図5のURLを記載
- 情報を収集する: ここで取得したい情報を絞ることが可能です
このルールを保存する前に、画面最下部の条件欄に必ず①仮ホストを作成する(図7)で作成した仮ホストを設定してください。ここでは「mykubernetes」を選択します。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-22-1024x209.png?resize=1024%2C209&ssl=1)
この仮ホストを指定しないと、データを取得して表示する先がないので監視することができません。必ず正しく指定・選択してください。ここまで完了したら、保存し、アクティベートを行います。
⑤mykubernetesのサービス再取得
エージェントが登録出来たら、仮ホストのサービスを再取得します。最初はIPアドレスもない何も取得していない箱の状態でしたが、エージェントでAPI接続がうまくいくと、以下のようにAPI状態、CPUやメモリ、Node数Pod数などのサービスを自動取得することができます。監視したいものを追加しましょう。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-23-1024x639.png?resize=1024%2C639&ssl=1)
これで、いわゆるクラスターコレクターとしてのホストが1つ登録された状態になりました。これでも監視は始まっていますが、Node・Pod数の把握だけでなくそれぞれのNodeやPodをホストとして個々に追加し、さらにそれぞれの状態を詳細に監視できるよう、Checkmkでルールを登録していきます。
⑥動的ホスト管理の設定
セットアップ>”ホスト”>動的ホスト管理 から接続を追加していきます。こちらも一意のIDは日本語の設定ができないため、英語で設定してください。
ここでは一意のIDを「connection_1」、タイトルを「k8s_object」としました。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-24-1024x704.png?resize=1024%2C704&ssl=1)
おそらくデフォルトは図14のような画面になっているかと思われますので、[新しい要素を追加する]ボタンをクリックします。すると、図15のような入力項目がでてきます。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-25-1024x638.png?resize=1024%2C638&ssl=1)
ピギーバックデータとは、クラスターコレクタからCheckmkにデータを取り込むための独自の仕組みのことです。必ず以下の通り設定してください。
- ソースホストを制限する: 図13のホスト(データ収集している仮ホストを必ず指定)
- ピギーバック作成オプション:ホストを作成する:図8で作成済のフォルダを作成先に指定
- 消えたホストを制限する: これにチェックを入れておくと、対象のPodなどを削除した場合に
- 自動的にホストを削除するよう設定できます。
- サービスディスカバリ: 作成中にサービスを発見する にチェックを入れておくと、
- 1台ずつ手動で取得する必要がありません。
以上で設定は完了です。保存し、アクティベートを行います。
早ければ、アクティベート実行時にクラスターコレクタで取得できたPodや名前空間などが自動的にホストに登録されます。すぐに登録されない場合、図15画面の「監視間隔」に設定した時間のとおり自動検出されますので、ピギーバックデータを取得する間隔が(デフォルト1分)経過するのを待ち、再度確認してください。
![](https://i0.wp.com/blog.jtc-i.co.jp/wp-content/uploads/2024/06/image-26-1024x682.png?resize=1024%2C682&ssl=1)
それぞれの詳細な監視項目(サービス)については、前回のブログ「【Checkmk KB】コンテナKubernetesを監視する<概要編>」に画面一覧と説明を記載しています。あわせてご確認ください。
ホスト一覧を確認すると、以下の通りkubernetesで監視できるオブジェクト、Node、Pod、DaemonSet…などがホストとして登録されたことがわかります。
以上で、監視設定についての解説は完了です。
おわりに
Kubernetsクラスターは、個々のコンポーネントの数や場所に大きく影響を受ける可能性があります。Kubernetes環境の監視対象が大量にある場合は、さらに効率よく監視するためにKubernetesだけを監視するための別サイトを作成することもおすすめしております。
Checkmkは1つのライセンスで複数のサーバーを立てることが可能なため、別サイトにに切り出した先で監視しているデータも、分散監視機能によりセントラルサイトへ接続して統合監視すことができます。より快適な監視方法をご検討ください。
お問合せ
Checkmkにご興味のある方は、以下のリンクから弊社までお問合せください。
30日間無償でご利用いただける評価版を以下のダウンロードリンクにてご用意しております。簡単に検証が開始できますので、お気軽にお試しください。