はじめに
当該記事は事例として公開させていただいている、KDDI アジャイル開発センター様の案件で取り組んだ、CloudWatch Metric Streams への移行に伴い Datadog 側での注意事項を纏めた記事になります。
導入事例はこちら：https://cloudpack.jp/casestudy/265.html
当該事例の AWS 側の構築については KDDI アジャイル開発センター様にてご対応いただきました。
移行時の注意事項については KDDI アジャイル開発センター様のブログ記事で紹介されておりますので、ぜひご覧ください。
記事はこちら：https://developers.kddi.com/blog/pEl6yM2G0MQpnpd4mBNS2
概要
CloudWatch Metrics Streams のリリースとほぼ同時期に Datadog のメトリクスの収集がCloud Watch Metric Streams で可能になりました。
その導入のメリットであるレイテンシーの減少に伴うものをはじめとして注意事項が3点ありましたので、以下に纏めます。
詳細
注意事項の3点は以下となります。
- CloudWatch Metric Streams 導入による Datadog Monitor の Delay
- API Polling と CloudWatch Metric Streams で0埋めの挙動
- AWS インテグレーションタイルの挙動
【CloudWatch Metric Streams 導入による Datadog Monitor の Delay の変更】
API Polling を利用する前提では、Datadog の公式ドキュメントの通り Delay 値は15分が推奨値となっております。
※ Delay が何を指しているか？という部分については、クラウドプロバイダー毎のクローラーの遅延時間が記載されているこちらを参照ください。
この遅延時間が CloudWatch Metric Streams 導入により短縮化されますので、今回の目的であるアラート検知時間の改善を要する場合、 Datadog の Monitor で評価する delay 値の調整が必要です。当該環境では Monitor の delay 値を5分に変更し、アラート検知時間を改善しました。
Datadog で定義している CloudWatch Metric Streams への変更後の delay の推奨値というのは無く、メトリクスによって少々遅れるケースもあるようなので、適用に当たっては事前に挙動をご確認いただくことをオススメします。
【API Polling と CloudWatch Metric Streams で0埋めの挙動】
0埋めの挙動が何を指しているか説明します。
0埋めの挙動
Datadog ではメトリクスによって、値がないことをデータがない(Nodata)と判定する場合と、値として0を収集する場合、があります。
例えば、前者のパターンですと、値が0のときにアラートを出したい、としていても、0の場合データが無いと判定され、収集されないため、Datadog の Monitor 設定では Nodata で通知するような設定をしておかないと、アラートはでません。
CloudWatch Metric Streams への移行に伴う影響
上記した0埋めの挙動に違いが出るか(以前は0として収集していたものが Nodata とならないか)、を改めて確認しました。
実際に0埋めの挙動が異なるメトリクスがあり、今まで0で収集できていたものが Nodata となる仕様になるメトリクスを確認できました。
そのため、値が0でアラートを出す、という運用をしているメトリクスがある場合、 CloudWatch Metric Streams へ変更後の挙動について、Datadogのサポートへ確認することをオススメします。
挙動が異なる場合の対策
もし Nodata でないと検知ができない場合、Datadog の Monitor の default_zero が有効です。
こちらを利用することで Monitor 上で 値が無い状態を 0 で値を埋める挙動をするため、従来のアラート条件と同じ条件で運用をすることが可能です。
※ default_zero はクエリの記載による制御のため、Monitor のクエリの変更が必要になりますので、ご注意ください。
【AWS インテグレーションタイルの挙動】
AWS インテグレーションタイルは Datadog で AWS インテグレーションする場合の設定画面を指しております。
通常の挙動
通常、こちらで Datadog で収集する対象の AWS サービスを絞ること、EC2 などの Resource についたタグを利用した収集対象の制限(Limit Metric Collection to Specific Resources)が可能です。
こちらを利用することで、必要最低限の AWS サービス に対して メトリクスを収集するような設定が可能になります。
※以下サンプルです
CloudWatch Metric Streams への移行に伴う影響
CloudWatch Metric Streams を利用することで、API Polling でのメトリクスの収集が止まり、CloudWatch Metric Streams でのメトリクスの収集に自動で切り替わりますが、API Polling を利用したカスタムタグや他のメタデータの収集は行い続けます。
ただ、この環境への適用時は、インテグレーションタイルの Limit Metric Collection to Specific Resources による制限については、利用出来ない状態となっておりましたので、導入時はご確認ください。
まとめ
Datadog 側の注意事項としては細かい部分ではございますが、考慮できない場合、障害発生時にすばやく検知できない、そもそも検知できない、といった事象に繋がりかねないものでした。
監視という分野について、表に出る機会が増えており今後も改善や技術共有について需要があると考えております。
改善に繋がるような活動について、今後も引き続き積極的に取り組んでいきたいと考えております。
今回の仕組みを構築する中で、KDDI アジャイル開発センター様と密に連携をとる必要がありました。
ご協力いただいた結果、意図した結果を出すことができ、大変良いケースになったと考えております。ありがとうございました。
