IBM Cloud Monitoring with Sysdigで、IBM Cloud Kubernetes Service(IKS)の環境をモニタリングしてみる

はじめに

IBM Cloudでは、システムのモニタリングサービスとして「IBM Cloud Monitoring with Sysdig」(以降Sysdig）を提供しています。クラウドネイティブ、マイクロサービスの領域では、可観測性（Observability）が重要とされますが、SysdigはIBM Cloudでの可観測性を支援するサービスの1つとなります。

Sysdigでは、CPU・メモリ・ディスク・ネットワークの使用率や、IBM Cloud Kubernetes Service(IKS)、Red Hat OpenShift on IBM Cloudのコンテナを監視し、取得したメトリクスをダッシュボードとして表示したり、設定したしきい値を超えた場合にメール、Slackなどで通知するといったことが可能です。

Sysdigは、ライト・プランであれば（限定的な内容ではありますが）30日間無料で使用することができるため、IBM Cloudで、特にIKSやOpenShiftといったコンテナ環境の監視をしたいということであれば、まずはSysdigを試してみるのがよいかと思います。

当記事では、「QuarkusアプリをIBM Cloud Kubernetes Service(IKS)で動かしてみる」で作成したIKS環境をSysdigで監視してみます。

※上記リンク先記事を全て実施しなくても、IKSのクラスター、および、クラスター上で動作する何らかのコンテナ(素のnginxなど)があれば試せます。

Sysdigインスタンスの作成

IBM Cloudにログインし、画面左上のハンバーガーメニューを展開し、「プログラム識別情報」をクリックします。

「IBM Cloud Monitoring with Sysdig」をクリックします。

IKSと同じリージョンを選択し（無料のIKSクラスターの場合、ダラスを選択）、「ライト」プランを選択します。

画面下部で、「IBM platform metrics」を「Enable」に設定します。（IKSのモニタリングだけであれば不要ですが、他のサービスもモニタリングする場合は有効にしておく必要があります）
それ以外はデフォルトのままで、画面右側の「作成」ボタンをクリックします。

以下のように、Sysdigのインスタンスが作成されました。

IKSへのエージェントの追加

次に、IKSクラスターの監視ができるように、Sysdigのエージェントを導入していきます。
Kubernetesに対するSysdigのエージェントはDaemonSetとして実装されており、各ノードで1個ずつ稼働します。
今回監視対象とする無料のIKSクラスターはノード(Worker Node)が1個しかないため、DaemonSetとして稼働するPodも1つになります。

Sysdigインスタンス作成直後の画面（既に閉じている場合はこちら）で、対象のSysdigインスタンスの「ソースの編集」リンクをクリックします。

以下の画面が表示されますので、画面の指示の通り実行します。

ターミナルを立ち上げ、IBM Cloudにログインします。

ibmcloud login -a cloud.ibm.com -r us-south -g Default

以下のコマンドを実行します。

# IKSの無料クラスターの場合、Cluster Nameはデフォルトで「mycluster-free」
ibmcloud ks cluster config --cluster <Cluster Name または Cluster ID>

kubectlの対象コンテキストが正しいことを確認します。

kubectl config current-context

正しくない場合、以下のコマンドでコンテキスト一覧を確認し、変更します。

# コンテキストの一覧
kubectl config get-contexts

# コンテキストの変更
kubectl config use-context <コンテキスト名>

以下の画面の、「プライベート・エンドポイント」、「パブリック・エンドポイント」に記載されているコマンドを順に実行します。

# プライベート・エンドポイント
curl -sL https://ibm.biz/install-sysdig-k8s-agent | bash -s -- -a xxxxxxxxxxxxxxxxxxxxxxxxxxx -c ingest.private.us-south.monitoring.cloud.ibm.com -ac 'sysdig_capture_enabled: false'

# パブリック・エンドポイント
curl -sL https://ibm.biz/install-sysdig-k8s-agent | bash -s -- -a xxxxxxxxxxxxxxxxxxxxxxxxxxx -c ingest.us-south.monitoring.cloud.ibm.com -ac 'sysdig_capture_enabled: false'

実行完了後、SysdigエージェントのPodが稼働していることを確認します。

❯ kubectl get pods -n ibm-observe
NAME                 READY   STATUS    RESTARTS   AGE
sysdig-agent-ffrss   1/1     Running   0          39m

Sysdigモニタリングの確認

それでは、IKSがどのようにモニタリングされるかを見てみましょう。

IBM Cloudのモニタリングのページにアクセスします。

対象のSysdigインスタンスの「Sysdigの表示」リンクをクリックします。

画面左側のメニューの「Dashboards」→「My Dashboards」→「Overview by Container」をクリックします。

すると、以下のようなダッシュボードが表示されます。
これから負荷をかけてどのような表示になるかを確認していくため、データの取得範囲を直近10分間に変更します。以下のスクショの下部、赤枠で囲った「10M」をクリックします。

それでは負荷をかけていきます。負荷ツールとして hey (オープンソース、Apache License 2.0) を使用します。
MacでHomebrewが導入されている場合、以下のコマンドで簡単にインストールできます。

brew install hey

hey を使用し、「QuarkusアプリをIBM Cloud Kubernetes Service(IKS)で動かしてみる」で稼働させたQuarkusアプリに負荷をかけていきます。50スレッドで3分間、指定のURLに対して負荷をかけます。

hey -z 3m -c 50 http://<Worker NodeのパブリックIPアドレス>:<NodePortサービスのポート番号>/hello

実行完了後、以下のような結果が表示されました。
1秒間に270リクエストのスループットで、平均レスポンスが0.18秒という結果でした。

Summary:
  Total:	180.1693 secs
  Slowest:	1.9096 secs
  Fastest:	0.1488 secs
  Average:	0.1845 secs
  Requests/sec:	270.8453
  
  Total data:	243990 bytes
  Size/request:	5 bytes

Response time histogram:
  0.149 [1]	|
  0.325 [47549]	|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.501 [255]	|
  0.677 [821]	|■
  0.853 [56]	|
  1.029 [49]	|
  1.205 [45]	|
  1.381 [15]	|
  1.557 [3]	|
  1.734 [0]	|
  1.910 [4]	|


Latency distribution:
  10% in 0.1556 secs
  25% in 0.1632 secs
  50% in 0.1748 secs
  75% in 0.1817 secs
  90% in 0.1904 secs
  95% in 0.2056 secs
  99% in 0.5391 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0004 secs, 0.1488 secs, 1.9096 secs
  DNS-lookup:	0.0000 secs, 0.0000 secs, 0.0000 secs
  req write:	0.0000 secs, 0.0000 secs, 0.0010 secs
  resp wait:	0.1841 secs, 0.1487 secs, 1.5515 secs
  resp read:	0.0000 secs, 0.0000 secs, 0.0011 secs

Status code distribution:
  [200]	48798 responses

実行完了後のダッシュボードの状態です。
「quarkus」というコンテナが負荷をかけた対象ですが、ネットワークのバイト数、コネクション数は影響ありましたが、CPU、メモリについては影響が分かりませんでした。

Quarkusのコンテナだけを詳細に見てみます。画面左側の「Explore」をクリックします。

Quarkusコンテナのイメージ（赤枠）をクリックします。

すると、コンテナイメージ単位のデータを表示することができます。
負荷をかけていた時間帯、若干ではありますがCPUの使用率が上昇していることが分かります。

以上です。