DynatraceによるKubernetesアプリケーションの監視

# はじめに

こちらはの記事は[とっても簡単！DynatraceによるKubernetesの監視の仕方（2021年版） \- Qiita](https://qiita.com/sukatsu1222/items/43651f84e70e664763fb)の続きになります。
前回の記事を見ていない方はまずは前回の記事を読むことをお勧めします。

前回の記事では、Ubuntu上に構築したmicrok8sのクラスタにDynatrace Operatorをインストールする方法について紹介しました。
本記事では、Kubernetes上でデモアプリケーションを動かし、Dynatraceではどのように見ることができるのか、どのように役立つのかを紹介していきます。

複数のコンテナを活用してアプリケーションを展開するKuberntesでは、監視というのは重要な要素となりますので、ぜひ実際に体感してみてください。

# Dynatrace Operatorの構成

デモアプリケーションを動かす前に少しだけDynatrace Operatorがどのように構成されているのか解説したいと思います。
今回構築した環境は、[公式サイト](https://www.dynatrace.com/support/help/setup-and-configuration/setup-on-container-platforms/kubernetes/)でいうところの**Classic full-stack injection**というものになります。

![image.png](https://dt-cdn.net/images/screen-shot-2021-01-26-at-12-12-46-1004-ec737341a9.webp)

実際には以下のような構成になっています。

```bash
$ 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](https://github.com/sukatsu1222/easytravel-k8s)
こちらのリポジトリをクローンして、README.mdに記載の通り以下のコマンドを実行します。

```bash
git clone https://github.com/sukatsu1222/easytravel-k8s.git
cd easytravel-k8s/
./deploy-easytravel.sh
```

microk8s上で動かしている場合は、`ingress`もデプロイしておきます。（ingressがいない環境ではマニフェストファイルを修正してServiceの`type: LoadBalancer`を`type: NodePort`に変更する必要があります）

```bash
./deploy-ingress.sh
```

# DynatraceにおけるKubernetesビュー

左のメニューから`Infrastructure` - `Kubernetes`を開きます。
監視しているクラスタのサマリ情報を一覧することができます。**登録したクラスタ名**をクリックすることでさらに詳細を確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65441/d8827ece-e2b9-7ef1-3fee-405a33e36388.png)

クラスタの詳細情報を確認できます。この環境では

* CPUは全部で4コアあり、リクエストは2.1コア分されており、残り1.9コア利用可能、メモリも全部で15.2GBあり3.63GBリクエストされていて、11.6GB利用可能というのことが確認できます。
* 7つのネームスペースに16個のワークロードがあり、内訳はデプロイメントが11、デーモンセットが3、ステートフルセットが2で16 Pods稼働しているのが望ましい状況で、16 Pods 実行しているということがわかります。

Kubernetes環境で**重要なCPU、メモリのリクエスト量および利用可能量**が一目で確認できるのでリソース不足になる前に対応することが可能です。また、現在のワークロードも確認することができるので、クラスタの状況把握に役立てることができますね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65441/58117d9a-1840-d65c-9050-816c3d3b2d38.png)

`Cluster utilization`ではクラスタのCPUとメモリをグラフで確認することができます。requests, limits, availableを選択することで情報の切り替えも簡単に行えます。下のグラフですと15時45分頃にMemory requestsが急激に上昇していることがわかりますが、その後は元の水準に戻っていることが確認できます。この辺のグラフ表示も**Dynatraceであれば難しい設定を行うことなく**実現することができています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65441/5d560f4d-a07d-7355-41b6-264493e4fdb5.png)

`Cluster workloads`ではどれぐらいのワークロードが実際に稼働しているのか、Podsはどれぐらいなのかが時系列グラフで表示されています。`kubectl`コマンドではそのときそのときのワークロードは確認できても時系列に確認はできないですし、namespaceを横断して確認するのもシェルをうまく利用しないといけないので、**デフォルトで表示**されているのはうれしいですね。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65441/82cf4bf9-184f-2c65-1308-42d5017ff102.png)

画面をスクロールすると`Event`の情報も確認することができます（解像度によっては右側に表示されている場合もございます）。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65441/52bd039d-f2e8-958b-b6a0-4eaf0fe7ef20.png)

通常の運用では見逃しがちな**BackOffの発生**もここから簡単に見つけることが可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65441/901ce2aa-d64a-f351-45a7-3055368b1474.png)

## ワークロードの詳細

`Cluster workloads`にあるネームスペース欄から詳細を確認したいネームスペースをクリックすることでさらに詳細を見ていくことができます。
（ネームスペース数が多い場合、ネームスペースの一覧は表示されないため`view all workloads`ボタンから絞りこむ必要があります）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65441/ccda3007-3fd2-5acf-fcb7-724eba101b2f.png)

ネームスペース毎の詳細を見たいときはこちらが便利です。例えばeasytravelネームスペース内の情報として以下の図の情報を得ることができます。
CPUのリクエスト・リミットの値はいくつになっているのか。また、本来稼働していなければならないPodsの数と実際に実行しているPodsに開きはないかが時系列グラフで表示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65441/b9c4b11a-b29f-5a11-2670-7ddbbde1dbc2.png)

さらにワークロードの詳細も確認することも可能です。下の図では、このDeploymentがどれぐらいのCPU、メモリを消費しているのかを表しています。ドリルダウンメニューを変更することでthrottledの値など様々な値を確認可能です。通常であれば取得のためのメトリクス設定などが必要になるケースも多い中、Dynatraceでは自動取得してきてくれます。
これ以外にもワークロードに対するネットワークに関連した以下のメトリクスも自動で取得してきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/65441/0ea790c7-cd4e-84f2-270e-c431fe58fc55.png)


# まとめ

今回の記事では主にDynatrace上ではKuberntesの情報はどのように見ることができるのかを紹介しました。通常のコマンドラインでは取得できないような**時系列のデータも標準でグラフ化**して表示されるので、いつ何が起きたのか過去に遡って確認するということが大変簡単にできます。さらにそれがクラスタ単位だけでなくワークロード単位で確認することができるので、様々なワークロードが動いている環境では非常に役に立つのではないでしょうか。

次回の記事では、Observabilityに必要なメトリクス、ログ、分散トレーシングについて紹介していきたいと思います。