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つの方法が用意されています。
- サイドカー形式 Pod runtime injection
- コンテナビルド形式 Container Biuld-time injection
要するに、まとめると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 が分かれています
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で修正される予定です