はじめに
こちらはの記事はとっても簡単！DynatraceによるKubernetesの監視の仕方（2021年版） - Qiitaの続きになります。
前回の記事を見ていない方はまずは前回の記事を読むことをお勧めします。
前回の記事では、Ubuntu上に構築したmicrok8sのクラスタにDynatrace Operatorをインストールする方法について紹介しました。
本記事では、Kubernetes上でデモアプリケーションを動かし、Dynatraceではどのように見ることができるのか、どのように役立つのかを紹介していきます。
複数のコンテナを活用してアプリケーションを展開するKuberntesでは、監視というのは重要な要素となりますので、ぜひ実際に体感してみてください。
Dynatrace Operatorの構成
デモアプリケーションを動かす前に少しだけDynatrace Operatorがどのように構成されているのか解説したいと思います。
今回構築した環境は、公式サイトでいうところのClassic full-stack injectionというものになります。
実際には以下のような構成になっています。
$ kubectl -n dynatrace get all
NAME READY STATUS RESTARTS AGE
pod/dynatrace-operator-8577b46ffc-g8fnd 1/1 Running 0 6d21h
pod/dynakube-classic-4k8nh 1/1 Running 0 6d21h
pod/dynakube-routing-0 1/1 Running 0 6d21h
pod/dynakube-kubemon-0 1/1 Running 0 6d21h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/dynakube-routing ClusterIP 10.152.183.55 <none> 443/TCP 6d21h
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/dynakube-classic 1 1 1 1 1 <none> 6d21h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/dynatrace-operator 1/1 1 1 6d21h
NAME DESIRED CURRENT READY AGE
replicaset.apps/dynatrace-operator-8577b46ffc 1 1 1 6d21h
NAME READY AGE
statefulset.apps/dynakube-routing 1/1 6d21h
statefulset.apps/dynakube-kubemon 1/1 6d21h
OneAgentはdynakube-classicという名前のdaemonsetで、KubernetesのAPIからメトリックを取得するのはdynakube-kubemonというstatefulsetになります。dynakube-routingというstatefulsetはOneAgentが取得したメトリックを収集し、Dynatrace Clusterへ送るActiveGateの役割を担います。
デモアプリのデプロイ
それでは、早速デモアプリのデプロイを行っていきます。今回はDynatrace社が用意しているeasyTravelというアプリケーションのKubernetes版を利用したいと思います。
sukatsu1222/easytravel-k8s
こちらのリポジトリをクローンして、README.mdに記載の通り以下のコマンドを実行します。
git clone https://github.com/sukatsu1222/easytravel-k8s.git
cd easytravel-k8s/
./deploy-easytravel.sh
microk8s上で動かしている場合は、ingressもデプロイしておきます。（ingressがいない環境ではマニフェストファイルを修正してServiceのtype: LoadBalancerをtype: NodePortに変更する必要があります）
./deploy-ingress.sh
DynatraceにおけるKubernetesビュー
左のメニューからInfrastructure - Kubernetesを開きます。
監視しているクラスタのサマリ情報を一覧することができます。登録したクラスタ名をクリックすることでさらに詳細を確認できます。
クラスタの詳細情報を確認できます。この環境では
- CPUは全部で4コアあり、リクエストは2.1コア分されており、残り1.9コア利用可能、メモリも全部で15.2GBあり3.63GBリクエストされていて、11.6GB利用可能というのことが確認できます。
- 7つのネームスペースに16個のワークロードがあり、内訳はデプロイメントが11、デーモンセットが3、ステートフルセットが2で16 Pods稼働しているのが望ましい状況で、16 Pods 実行しているということがわかります。
Kubernetes環境で重要なCPU、メモリのリクエスト量および利用可能量が一目で確認できるのでリソース不足になる前に対応することが可能です。また、現在のワークロードも確認することができるので、クラスタの状況把握に役立てることができますね。
Cluster utilizationではクラスタのCPUとメモリをグラフで確認することができます。requests, limits, availableを選択することで情報の切り替えも簡単に行えます。下のグラフですと15時45分頃にMemory requestsが急激に上昇していることがわかりますが、その後は元の水準に戻っていることが確認できます。この辺のグラフ表示もDynatraceであれば難しい設定を行うことなく実現することができています。
Cluster workloadsではどれぐらいのワークロードが実際に稼働しているのか、Podsはどれぐらいなのかが時系列グラフで表示されています。kubectlコマンドではそのときそのときのワークロードは確認できても時系列に確認はできないですし、namespaceを横断して確認するのもシェルをうまく利用しないといけないので、デフォルトで表示されているのはうれしいですね。
画面をスクロールするとEventの情報も確認することができます（解像度によっては右側に表示されている場合もございます）。
通常の運用では見逃しがちなBackOffの発生もここから簡単に見つけることが可能です。
ワークロードの詳細
Cluster workloadsにあるネームスペース欄から詳細を確認したいネームスペースをクリックすることでさらに詳細を見ていくことができます。
（ネームスペース数が多い場合、ネームスペースの一覧は表示されないためview all workloadsボタンから絞りこむ必要があります）
ネームスペース毎の詳細を見たいときはこちらが便利です。例えばeasytravelネームスペース内の情報として以下の図の情報を得ることができます。
CPUのリクエスト・リミットの値はいくつになっているのか。また、本来稼働していなければならないPodsの数と実際に実行しているPodsに開きはないかが時系列グラフで表示されます。
さらにワークロードの詳細も確認することも可能です。下の図では、このDeploymentがどれぐらいのCPU、メモリを消費しているのかを表しています。ドリルダウンメニューを変更することでthrottledの値など様々な値を確認可能です。通常であれば取得のためのメトリクス設定などが必要になるケースも多い中、Dynatraceでは自動取得してきてくれます。
これ以外にもワークロードに対するネットワークに関連した以下のメトリクスも自動で取得してきます。
まとめ
今回の記事では主にDynatrace上ではKuberntesの情報はどのように見ることができるのかを紹介しました。通常のコマンドラインでは取得できないような時系列のデータも標準でグラフ化して表示されるので、いつ何が起きたのか過去に遡って確認するということが大変簡単にできます。さらにそれがクラスタ単位だけでなくワークロード単位で確認することができるので、様々なワークロードが動いている環境では非常に役に立つのではないでしょうか。
次回の記事では、Observabilityに必要なメトリクス、ログ、分散トレーシングについて紹介していきたいと思います。