DynatraceのKubernetes監視についてまとめてみました

お客様含め、いろいろな方面から、「DynatraceのKubernetes監視って、ヘルプガイドを見てもちょっと分からないんだけど、結局どういうやり方があるんですかね？」と聞かれることがちょいちょいあります。まぁ、確かにヘルプには英語の記載しかありませんので、Kubernetesの知識＋Dynatraceの知識＋Operatorの知識＋Helmの知識など、各方面の知識の前提条件がある程度クリアされていないと、読んでもよく分からないという状況に陥ることがあろうかと想像します。そんなみなさんの疑問・悩みに答えるべく、今回はDynatraceのKubernetes監視についてまとめることにしました。なお、今回のブログだけではカバー出来ませんので、以下5回のシリーズに分けてまとめることにしました。複数回のシリーズに分けてブログを書けば、ずぼらな私も定期的かつ必然的に記事を書かなければならなくなるため、書く側から見ても一定の強制力が働き良いと勝手に思っています。

DynatraceでのKubernetes監視の4つのモデルについて（←いまココ）
Kubernetes監視のFull stack監視について（全部見るパターン）
Kubernetes監視のKubernetes監視について（K8sだけ見るパターン）
Kubernetes監視のApplication監視について（アプリだけ見るパターン）
Kubernetes監視のHost監視について（K8s のホストノードだけを見るパターン）

ということで、第一回目のブログでは「3つの監視モデル」についてまとめていきたいと思います。

Dynatraceにおける3つの監視モデルとは？

DynatraceはKubernetesの監視において、いくつかのオプションを用意しています。大別すると全部で3つあります。Dynatraceのヘルプガイドの「Deploy」>「Kubernetes」>「Deployment」をクリックすると最初に表示されるこの図が、その3つを表現しています。

ただ、この絵を見てもピンと来ないため、ここからそれを分かりやすく解説してきます。

3つの監視オプションを表形式で表現し直してみる

これら3つの監視オプションを、縦軸を監視コンポーネント、横軸を監視オプションにしてみると、分かりやすくなります。表現し直すと、こうなります。でも、これを呼んだ方は気付かれると思います。3つの監視オプションがあるのに、なので表は4つ目があるの？と。いい気付きですね。ちゃんと説明しますので、ご安心下さい。なお、4つ目はオプション扱いのため、上記の図の中では表現が割愛されています。。。

凡例：
✅：監視する
❌：監視しない

監視対象コンポーネント	(1) FULL KUBERNETES Observability	(2) KUBERNETES Observability	(3) APPLICATION Observability	(Other) HOST Monitoring
Application	✅	❌	✅	❌
Kubernetes	✅ Container版のActiveGateがDeployされる	✅ Container版のActiveGateがDeployされる	✅ Container版のActiveGateがDeployされる	❌
Host node	✅ Host nodeにOneAgentがDeployされる	❌	❌	✅ Host nodeにOneAgentがDeployされる
Deployment のやりかた	2つ方法あり	1つだけ	1つだけ（例外あり）	1つだけ
Deployment の名称	Classic full stack, Cloud native full stack	Kubernetes platform monitoring	Application-only monitoring	Host monitoring
Help Document Link	Classic full stack, Cloud native full stack	Kubernetes observability	Application observability	Host monitoring
どうやって動作するか	Classic full stack Cloud native full stack	Kubernetes platform monitoring	Application-only monitoring:auto-injection Application-only monitoring: Pod runtime injection Application-only monitoring: Container build-time injection	Host monitoring

（例外あり）
APPLICATION Obervability（or Application-only monitoring）は、Operatorを使ってアプリにのみOneAgentをInjectする方法が標準です。ただし、Operatorを使用しないケースでも対応できるように、アプリをDeployする際にサイドカー形式でInjectする方法と、コンテナとしてBuildする際にInectする2つの方法が用意されています。

要するに、まとめるとDynatraceのK8s監視は、4種類あることになります。

FULL Kubernetes Observability
- K8sをホストからアプリまで全部見ますよ、と言っています
- アプリを見るので、サーバサイドも見えますし、フロントエンドも見えます
- コンテナ版の ActiveGate がDeployされ、それを使ったK8sのメトリクスも収集します
- この方式だけ、2つのDeployment方法があります
  - Classic full stack（CSIドライバーを使わず、OneAgentをアプリにInjectするやり方）
  - Cloud native full stack（CSIドライバーを使って、OneAgentをアプリにInjectするやり方）
KUBERNETES Observability
- K8sのみを監視しますよ、と言っています
- コンテナ版の ActiveGate がDeployされ、それを使ったK8sのメトリクスを収集します
APPLICATION Observability
- アプリとK8sの両方を監視しますよ、と言っています
- もし、Dynatrace Operatorを使わない場合は、これとは別に下記2つのやりかたがありますと、言っています
  - Pod runtime injection
  - Container build time injection
Host Monitoring
- K8sのホストノードのみを監視しますよ、と言っています
- K8sのホストノードのみを監視するため、OneAgentは infra-only mode で動作します

DynatraceでK8sの監視をはじめる場合、まずはこの4つの監視方法の違いを正しく理解しておく必要があります。そのうえで、どのやりかたでK8sを監視するのが最適かを考えると、取っつきやすいと思います。

Dynatrace の K8s 監視のセットアップ手順

まずは、Operatorを使ってK8sの監視を始めるのが、基本中の基本です。DynatraceのOperatorを使用することで、アプリケションがK8sプラットフォーム上に、Deployされると、自動的にOneAgentがInjectされるため、アプリの監視が大変便利です。アプリをDeployする側から見ると、特にK8s監視の存在を意識することなく、アプリ側のマニフェストを変更しなくても、いつものようにアプリをDeployすれば良いからです。この辺がDynatraceのK8s監視の敷居の低さだと思います。

なお、先ほど説明した4つの監視オプションのどのやりかたであっても、Operatorを使用します。その手順は、基本的にすべて同じで、以下の3つのステップで行います。

DynatraceのOperatorを最初にインストールする
- インストールする方法は2つあり、1つ目は「Helmパッケージ」を使う方法で、もう1つは「マニフェスト」を使う方法です
- サーバにhelmがインストールされている場合、hub を search オプションに指定し helm search hub dynatrace-operator と実行して表示されるものが、Dynatrace Operatorです
K8s監視用の scecret を作成する
- OneAgentをEnvironmentからダウンロードしてDeployしたり、K8s APIを経由して取得したメトリクスをそのEnvironmentにInjestするための scecret
- 「dynakube」とい名称（name）の secret を作成しますが、そこに Operator token と Metirc ingest token の2つを定義します
- それぞれのTokenのScopeは、ヘルプのこちらに記載があります
- Access tokens and permissions
Dynakubeと呼ばれるCRD（Custom Resource Definition）をDeployする
- Dynatraceの公式GitHub上から、CRD YAML を監視オプションに合わせてダウンロードし、カスタイズしたのち、apply する
- このCRDのテンプレートは、Dynatraceの公式GitHubサイトにあります。それぞれのDeploymentパターンに合わせて manifest yaml が分かれています
  - Class full stack 用の CRDファイル
  - Cloud native full stack 用の CRDファイル
  - Kubernetes Platform monitoring用のCRDファイル
  - Application-only monitoring用のCRDファイル
  - Host monitoring用のCRDファイル

DynatraceのK8s監視オプションのまとめ

いかがだったでしょうか？DynatraceのK8s監視は、Operatorを使うことによってと非常に簡単かつ手軽にモニタリングが開始できます。にも関わらず、難しく見えるのは、ドキュメントヘルプに記載されている内容を読んでも、よく分からないからではないのかな？と勝手に思っています。今回のこのブログを通じて、少しはDynatraceのK8s監視のオプションや、そのDeployment方法について、理解が進めば大変嬉しいです。
今回は、K8s監視の全体像を捕らえる話しかしていませんので、次回以降のブログでそれぞれの監視オプションごとに実際にDeployする手順と、DeployしたあとにDynatraceのUIのどこにデータがどういう形で見えるのか含めてきちんとまとめていきたいと思います。
まずは、次回弊社のRecommended方式でもある「Full stack監視（Kubernetes Full Observability）」についてまとめたいと思います。

ちなみに、今回のK8s監視シリーズで使う、Kubernetes Distribution はRKE2です。Rancher Kubernetes Engine (RKE)は、Dynatraceが正式にサポートするDistributionのひとつなので、トラブルもなく、自身のLaptopでも動くライトなK8sなのでそれを使っていく予定です。

まだ、Dynatraceを触ったことがない方、このブログを見てやってみたいと思われた方は、下記フリートライアルにてお試し下さい。↓↓↓

Dynatraceフリートライアル → https://www.dynatrace.com/ja/trial/

追加情報

Dynatrace Operator を helm search した結果
- helm search hub で検索すると、こんな風に見えます

❯ helm search hub dynatrace-operator
URL                                                     CHART VERSION   APP VERSION     DESCRIPTION                                      

https://artifacthub.io/packages/helm/dynatrace/...      1.3.0           1.3.0           The Dynatrace Operator Helm chart for Kubernete..

Dynatrace Operator v1.3.0（最新版）の不具合
- ActiveGate がK8sのメトリクス情報のデータギャップ（data gap）が起きる問題が報告されています
- https://community.dynatrace.com/t5/Heads-up-from-Dynatrace/Activegate-with-Kubernetes-monitoring-managed-by-the-Dynatrace/ta-p/258149
- Workaroundは、ひとつの前のバージョン v1.2.2 を使うことです
- この問題は、v1.3.1で修正される予定です