Kubernetes Downward APIを使ってDogStatsDにカスタムメトリクスを送れるようになる！
動機
最近、比較的モダンなモニタリングに関する本が出ていたので読みました。
- 作者: Mike Julian,松浦隼人
- 出版社/メーカー: オライリージャパン
- 発売日: 2019/01/17
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
そこで、監視(モニタリング）の定義がされていました。
監視とは、あるシステムやそのシステムのコンポーネントの振る舞いいや出力を観察し、チェックし続ける行為である。
プロバイダがGoogle Cloud Platformでなかろうと、Kuberenetesクラスタをモニタリングをするのは簡単なことではありません。
DatadogはDatadog AgentというPod(コンテナ)を配置することによって、KuberenetesのHostを中心に、クラスタ全体のメトリクスを取得、可視化、そして探求をすることができます。
今回はDatadogを使ってGoogle Kuberenets Engineクラスタを監視します。そしてDatadog APMを中心に、新しい機能があるので調査していきます。注意点として、必ずDatadog Agentをインストールする必要はなくて、API経由でもメトリクスを監視することができます。
アジェンダ
今回の記事は以下のアジェンダになっています。クラスタ作成からやるので、興味のあるセクションに飛んでもらっても大丈夫です。
- 動機
- アジェンダ
- Datadogについて
- Datadogを導入する
- アプリケーション固有のメトリクスを収集したいとき
- まとめ
- 参考文献
Datadogについて
Datadogについて、体系的にまとめようと思います。
公式サイト
以下のサイトが公式のサイトになります。
開発、運用する上で必要なドキュメントは以下の通りです。
料金
料金体系が用途によって分かれます。
- Infrastructure: Datadog Agentが集めるメトリクス
- APM: Datadog APMをつかったアプリケーションのAPM用のメトリクス
- Log Management: ログ収集、可視化
- Synthetics: E2E ユーザー体験のモニタリング
変化が大きいので、直接公式ページで参照するのが安全かなと思います。
どの用途でも14日間のフリートライアルがあるので、導入を検討するときに試してみることができます。
アーキテクチャ
Datadog Agentと呼ばれるAgentはDaemonsetとして、各ノードに配置されます。
そして、配置されたDatadog AgentがDatadog Serverにデータを集めます。
APM用のメトリクスの取得方法はまた別なので、あとのセクションで解説をします。
分解能
Datadogでは、1秒の分解能でメトリクスのデータを保存います。
Datadogを導入する
これより構築をしてみようと思います。
1. GKEクラスタの作成
まず、今回の対象となるクラスタを作成します。
gcloud container clusters create test-cluster --zone asia-northeast1 --machine-type g1-small --num-nodes 1
作成できたか、どうか確認します。
gcloud container clusters describe test-cluster --zone asia-northeast1
何か返ってきたら作成ができています。
2. Datadog Agentのデプロイ
Datadog Agent自体を実際にデプロイします。
API Keyを取得する
WebサイトでAPI Keyを取得する必要があります。「Integration」-> 「APIs」から新しく設定をすることができます。
Webサイトにアクセスして、API Keyを作成してコピーしてください。
これの次のセクションのHelmのValueとして使用します。
Helmでインストールをする
今回はHelmを使ってDatadog Agentをインストールします。特に説明することはないので説明を省きます。
デプロイされると、以下のように確認をすることができます。
試しにPodをとると、以下のようようになります。
$ kubectl get pods
すると、以下のようになります。
NAME READY STATUS RESTARTS AGE datadog-2vclk 1/1 Running 0 4m datadog-5s2hf 1/1 Running 0 4m datadog-kube-state-metrics-b5c8c4d64-7npgd 1/1 Running 0 4m datadog-l2mwj 1/1 Running 0 4m
Datadogのサイトでは以下のようになっていて、ダッシュボードを確認できるようになります。
Eventを確認
Eventはダッシュボードを誰が作成したか、設定をどう買えたかなど、Datadog内でどのようなことが起きているかを監視できるものです。
チームなどを運用しているときはオペレーションを確認したいときに便利です。
まとめると以下の表にできます。
| Timeboard | Screenboard | |
|---|---|---|
| 時間間隔 | すべてのグラフが同じ(平均化されるなど) | すべてのグラフが別々の時間間隔 |
| レイアウト | グラフがグリッド表示 | グラフはどこでも配置をすることができる |
| グラフ個別で共有できる | ✅ | ❌ |
| ダッシュボードを共有できる | ❌ | ✅ |
| リードオンリーにできる | ✅ | ✅ |
デフォルトでは、過去一時間のオペレーションが確認をすることができます。
Dashboardを作成
メトリクスを可視化するには、二つのダッシュボードがあります。２つのDashboardの違いを知るには、以下のドキュメントをご覧ください。
左のサイドメニューの「Dashboard」->「Dashboard List」でDashboard一覧を見ることができます。
ここの可視化方法は以下のリンクでご覧ください。
A. Timeboardを作成
トラブルシューティングや関係性を知るのに適しています。特に時系列に対して強いです。
どのようなことができるのかというのは、実際に作成するとわかります。
B. Screenboardを作成
データや状態を可視化して、共有することが適しています。
例えば、Host mapを選択したときに色んな可視化方法を設定できます。
Monitorを作成
Prometheusでいうアラートにあたるものです。
いくつも種類があり、ここに一覧を表示します。
Monitorの種類
Monitorにもいくつかあるので、今回はMetricsに注目しようと思います。
Metrics Monitorの設定
- Threshold Alter: ある閾値を超えたらアラートを発火させるもので、最も一般的。
- Change Alter: 変化量がある閾値を超えたら発火するアラートです。
- Anomaly Detection: アルゴリズムベースの異常検知機能。強い傾向のある繰り返しパターンを持ったメトリクスに適しています。
- Outlier Section: アルゴリズムベースの異常検知機能。グループ内の特定の個体に他とは異なる挙動がみられた際に外れ値データ(Outlier)として検出することができます。
1. メトリクスとその対象範囲(スコープ)の設定
- Metrics: 何を
以下のように最初は「どんなメトリクス」をMonitorするかを設定します。
- From: 誰の
Fromで、誰のメトリクスを取得するのかを定義します。
例えば、今選択しているのはクラスタを構成しているNodeです。
次にアラートを設定をします。特に重要なのは閾値の設定です。
次に誰に通知するか、どのように通知をするのかを設定します。
テンプレートを使用することになり、ビルドイン変数を使うことができます。
Infrastrutureを確認する
大きく以下の種類に分けることができます。
- HostMap
- Infrastruture List
- Container
- Process
- Cloud Functions
1. Host Map: GCEインスタンス(=Host)ごとのCPU使用率などを表示
2. Infrastructure List: リスト表示でNodeを表示
3. Container: コンテナごとの情報を表示
Tagやコンテナ名でソートできるなど、非常に高機能です。
Fluentdなどをはじめ、システム的なコンテナはいくつかあります。そのようなものは、ほとんど制御する機会がないので使いません。
そのため、自分がデプロイしたコンテナを使いたい場合は左のImage名で検索できる箇所があるので、自分のImageにチェックをいれます。
Notebook: 説明とグラフを一体化する
Markdownかグラフを書くことができる。
Jupyter Notebookのように、解析とNotebookの相性は非常に良いです。DatadogのNotebookもメトリクスを使うことによって使用することができるため、データを探求したいときに便利です。
他にも用途としては
- 障害や復旧手順の記述
- ドキュメント管理
- データを探求
アプリケーション固有のメトリクスを収集したいとき
やっと本題です。
DogStatsDを使うとアプリケーションのカスタムメトリクスを集計できます。別途、収集することができます。Deploymentとして別途、デプロイされるPodです。
DogStatsDは、Datadog Agent 3.0以上に同胞されているメトリクス集約サーバです。DogStatsDは、StatsDプロトコルをサポートすると共に、datadog専用の機能にも対応するよう拡張されています。
UDPポートを公開しているケースがあります。。アプリケーション側からは同PodでなければDownword APIを使って、環境変数を指定してアクセスします。
... ports: - containerPort: 8125 {{- if .Values.daemonset.useHostPort }} hostPort: 8125 {{- end }} name: dogstatsdport protocol: UDP ...
つまり、Valueファイルは以下の通りにします。
## @param useHostPort - boolean - optional ## Sets the hostPort to the same value of the container port. Needs to be used ## to receive traces in a standard APM set up. Can be used as for sending custom metrics. ## The ports need to be available on all hosts. ## ## WARNING: Make sure that hosts using this are properly firewalled otherwise ## metrics and traces are accepted from any host able to connect to this host. # # ここのコメントを外す useHostPort: true
DaemonSetsなので、必ず同Nodeにあります。もちろん同じPodであれば普段通り、開発環境と同様にアクセスしてください。
またDownwardAPIについて知らなければ、いかの記事を参照してください。
DogStatsDの主な機能は、所定の時間間隔（デフォルトでは10秒）に発生するデータポイントの情報を、単一のメトリクスに集計/集約することです。
アプリケーション側のことは、ここでは詳しく解説しませんが、いくつもライブラリがあるので、使ってみてください。
まとめ
Datadogは簡単に導入できる一方で、信頼性が高く、たかがDaemonset一つだけで済むので、非常に楽であると思いました。Nodeやコンテナの状態の可視化は、エンジニアとしては誰もが助かる要素である。
遠いところだと、アンドロイドエンジニアも、どのAPI Versionなのかをすぐ見つけられて、APIの更新があっても即座にフィードバックを受けることができる。バックエンドエンジニアも同様です。
このような面で、費用対効果が直感的なのでSRE的には導入しやすく、開発体験を向上させることができると感じました。
Cloud Runにも対応しているので、いつかCloud Run with Datadogをしようと思います。
最後まで、ありがとうございました。
