目次
- 目次
- はじめに
- こんな方へおすすめの記事です
- CloudWatch Metric Streams 構築前提
- AWS使用リソース&DataDog使用コンソール
- CloudWatch Metric Streams 構築してみた
- メトリクス反映時間についての所感
- コストへのアプローチ
- おわりに
- お知らせ
はじめに
こんにちは、クラウド事業部の清水(駿)です！
7月に入り猛烈に暑い日が続きますね..無理せず頑張っていきましょう。
今回はAWS CloudWatch Metric Streamsを利用したDataDogメトリクス監視について紹介いたします。
AWS～DataDog間でメトリクス監視をする場合、デフォルトのAPIポーリングでDataDogのコンソールに反映されるまでに10分以上時間を要してしまいます(時間かかりすぎ......)
シンプルに監視だけならそのまま使用しても問題ないですが、クリティカルな障害が起きた場合は初動対応に遅れが生じてしまいます。10分以上ラグがあるって怖いですよね(;´∀｀)
解決策としてデフォルトのAPIポーリングからAWS CloudWatch Metric Streamsを使用するとAPIポーリングでDataDogのコンソールに反映されるまでに数分ほどに改善することができます。
こんな方へおすすめの記事です
- DataDogについて学習されている方
- AWSメトリクスをDataDogで監視検討している方
- 現状の監視方法で満足いっていない方
CloudWatch Metric Streams 構築前提
・AWSが使用可能な状態であること
・DataDogが使用できる状態であること
※DataDog未登録の方は2週間無料、クレジットカード登録不要で使用することができるので試して登録してみてはいかがでしょうか。
AWS使用リソース&DataDog使用コンソール
AWS
・Kinesis Firehose
・CloudWatch Metric Streams
・S3(事前作成済)
DataDog
・APIキー(事前作成済)
・メトリクスモニター
・AWSインテグレーション
CloudWatch Metric Streams 構築してみた
私が現場でCloudWatch Metric Streams を使用したのが2022年11月でしたので当時と現在では状況も大きく変化しているので最新情報を含めながら構築を進めてまいります。
バッファサイズ、細かい数値辺りは現場判断となるためデフォルトで設定されているものを採用します。
構築手順はこちらの公式サイトを参考に進めていきます。
docs.datadoghq.com
Kinesis Firehose構築
CloudWatch Metric Streamsを構築する前に土台となるKinesis Firehoseを構築します。 ここでは対象のDataDogにメトリクスを送る設定、エラーが吐かれたときにログを送信するS3などを設定します。
・Firehoseコンソールへ移動して【Firehoseストリームを作成】をクリック
・ソースを【Direct Put】、送信先を【Datadog】、Firehoseストリーム名を好みの名前にする
・【レコードを変換】は選択しない
・送信先の設定でHTTPエンドポイントURLを【DataDogメトリクス】を選択
※今回は送信先がAP1リージョン(東京)のためAP1となる。ほかにも米国や欧州があるため設定に注意が必要でここを間違えるとDatadogに送信ができなくなる
・認証には【APIキーを使用】を選択し、事前に作成したAPIキーを設定する。
・コンテンツエンコーディングには【GZIP】、再試行時間は【60秒】を選択
★事前作成済：DataDogコンソールよりAPIキー作成
・パラメータ は特に触らない、バッファもデフォルトのまま設定する
・バックアップの設定は【失敗したデータのみ】を選択※現場の判断で【すべてのデータ】を選んでも問題なし
・バックアップバケットは事前に作成済のものを設定
・バッファサイズ、バッファ間隔もデフォルトのまま設定する
・データレコードの圧縮は【gzip】を選択※現場の判断でほかのタイプを選んでも問題なし
・データレコードの暗号化は【S3 バケットの暗号化設定を使用】を選択
・詳細設定はセキュリティを担保するため【Firehose ストリームのソースレコードのためにサーバー側の暗号化を有効にする】をクリック、暗号化タイプを【AWS が所有するキーを使用】を選択する
・Amazon CloudWatch エラーのログ記録を【有効】を選択
・サービスアクセスで新規でIAMロール作成を選択※事前に作成したものを割り当てても問題ない。むしろ命名規則や管理上ではIAMロールは事前作成がおすすめ
・すべて記載できたら【Firehoseストリーム作成】をクリック
無事に作成できました！
CloudWatch Metric Streams 構築
それでは本題のCloudWatch Metric Streams 構築へと進んでいきます！
DataDog 事前確認
★DataDog AWS IntegrationコンソールでまだCloudWatch Metric Streamsが設定されていないことを確認
★AWS~DataDog間のメトリクス収集はすべてのリソースで【disabled】にしています。
AWS&DataDog側コストが跳ね上がるのを防ぐためと監視対象以外のメトリクスの送信を防ぐためで監視するリソースはすべてCloudWatch Metric Streamsに集約します。
この状態を作るとDataDog側にはAWSからメトリクスは送信されなくなりCloudWatch Metric Streamsを経由したものだけが送信されます
構築
Cloudwatchコンソールから【ストリーム】タブを選択し【メトリクスストリームの作成】をクリック
・DestinationでFirehoseと連携をするので【Custom setup with Firehose】を選択
・Select your Amazon Data Firehose streamは前項で作成したFirehoseを指定
・Service access to write to Amazon Data Firehoseは【新しいサービスロールを作成して使用します】を選択※事前に作成したものを割り当てても問題ない。むしろ命名規則や管理上ではIAMロールは事前作成がおすすめ
・出力形式は【OpenTelemetry 0.7】を選択※ Datadog へのメトリクスストリーミングは現在、OpenTelemetry v0.7 出力フォーマットのみをサポートしているため
・Select metrics you wish to streamは【Select metrics】で監視したいメトリクスのみに絞る
・Select namespaces and metrics that you want to streamは【Include】を選択
→自分が監視したいサービスを選択する。特定のメトリクスまで絞ることができるが今回はAll metrics nameとした。
・【統計をさらに追加】は入力しない
・【カスタムメトリクスストリーム名】は任意の名前を記載
・記載漏れがないことを確認後、【メトリクスストリームの作成】をクリック
作成できていることを確認
5分~10分ほど待つと選んだリソースのMetricsがアップデートされていることも確認できた。
DataDog事後確認
★5分~10分ほど待つとDataDog AWS IntegrationコンソールでCloudWatch Metric Streamsも設定されていないことを確認できました！
これで選択したリソースのみがDataDogに送られていることになります。
DataDog メトリクス確認
DataDog メトリクスコンソールから試しに【aws.ec2.cpuutilization】を確認したところしっかりCloudWatch Metric Streams経由で拾えていることを確認できました！
メトリクス反映時間についての所感
今回は送信先が2023年に開設したAP1リージョン(東京)で構築しています。
DataDog公式では数分と記載、他社のエンジニアの方が書いているブログでは3-4分と記載されているものが確認できますが私の環境では7-8分ほどメトリクス反映に時間がかかりました。
恐らく、DataDog公式での数分という基準は各リージョンで少しギャップがあるのかなと感じました。
コストへのアプローチ
現場で体験したことなのですが、CloudWatch Metric Streamsで対象のメトリクスを絞ってDatadogに送信してもCloudwatch自体の料金がそこそこ高くなってしまうことでした。
■原因
絞っているけど、実際の現場環境だと単純にリソース量が多いからです。例えば、環境にEC2,RDSが1-2個なら別に問題ないですが100個ならその分、送信量が増えますよね。結果、Cloudwatch自体の料金が高くなってしまうのです。
■対策
商用は常に監視する必要があるのでCloudWatch Metric Streamsは停止する。リソースの多い検証アカウントのCloudWatch Metric Streamsは基本停止としていました。監視試験や確認したいことがある際に再開ボタンをポチっと押すだけで再開できるのでコスト削減にはお勧めです。
私はインフラもしくはアプリメンバーがいつでも停止/再開できるように手順書を作成して共有してコスト削減対応をしておりました！
★停止
★再開
おわりに
DataDogって奥が深くて面白いのですが、公式を読んでも手順は基本文字ベースなので少し取っつきにくい印象なのでキャプチャ付きで紹介させてもらいました！
CloudWatch Metric Streamsを利用したDataDogメトリクス監視構築を考えている方やDataDog学習を進めている方の助けになることができれば幸いです。
お知らせ
APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。
その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp
https://www.ap-com.co.jp/service/utilize-aws/
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
