CloudWatchメトリクスを長期的に保存する！with Amazon Data Firehose(旧Amazon Kinesis Data Firehose)

CloudWatchメトリクスには保存期間が存在する

以下の記事がとてもわかりやすいです。

AWS CloudWatchのメトリクスデータの保持期間には制約があります。AWSの公式サイトに、以下のような保持期間が設定されていると記載があります。

60秒未満のデータポイント: 3時間
1分間隔のデータポイント: 15日間
5分間隔のデータポイント: 63日間
1時間間隔のデータポイント: 15か月間

このため、1分間隔のデータポイントは15日間のみ保存され、その後はデータがロールアップされてしまいます。これにより、保持期間を超えたデータポイントは失われてしまいます。

結構な落とし穴ですよね・・・。

今回は、記事で紹介されていた、Cloudwatchメトリクスを、Metric Streams → Data Firehose経由でs3に保存する方法を試してみようと思います！

参考：
メトリクスストリームは、AWS Data FirehoseやDatadogなどにメトリクス情報をストリームするサービスです。

AWS Data Firehoseは、S3やRedshiftなどにストリームデータを加工・投げ込んでくれるサービスです。

動作確認

Data Firehose → S3の動作確認

バケット、Firehose用IAMロールを準備する

メトリクスログを保存するS3バケットを準備します。

下記ドキュメントを参考に、Data Firehoseにアタッチするサービスロールを作成します。

こんな感じのポリシーを持つロールを作りました。

policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:PutObject",
                "s3:ListBucketMultipartUploads",
                "s3:ListBucket",
                "s3:GetObject",
                "s3:GetBucketLocation",
                "s3:AbortMultipartUpload"
            ],
            "Effect": "Allow",
            "Resource": [
                "${aws_s3_bucket.main.arn}",
                "${aws_s3_bucket.main.arn}/*"
            ]
        }
    ]
}

Firehoseストリームを作成する

準備ができたので、Firehoseストリームを作成します！

マネコンに移動する

「Firehose ストリームを作成」をクリックします。

ソースと送信先を選択する

ソースをクリックします。

Direct PUTを選択します。
CloudwatchメトリクスStreamを作成すると、そのリソースがPUT APIを叩いてくれます。

送信先はS3を選択します。Datadogとか触ってみたいなー。

Firehose ストリーム名を設定する

任意のストリーム名を入力します。アカウント内で一意である必要があります。

（任意）レコードの変換設定を行う

今回はスキップします。SAAの試験で良く問われるやつですね。

送信先の設定を行う

作成したS3バケットを設定します。

詳細設定を行う

簡単な動作確認なのでログ出力は無効化しておきます。

選択したIAMロールを使用するよう設定します。

設定内容に問題がなければ、「Firehose ストリームを作成」をクリックします。

ストリームがアクティブになることを確認する

ストリームの作成には最大5分かかるらしいです。少し待ちます。

1分くらいで作成が完了しました。

デモデータでテストする

ストリーム詳細画面を下にスクロールします。

「デモデータの送信を開始」ボタンでデモデータをストリームに送信します。

少し待った後、送信を停止します。

デフォルトでは、ストリームは300秒に1度、配信先にデータを配信します。

少し待機し、S3を見に行きます。
それっぽいプレフィックスがきられています。

デフォルトでは、ストリームは「YYYY/MM/dd/HH」プレフィックスでオブジェクトを保存します。

デフォルトプレフィックスでオブジェクトが保存されていますね！！

中身は意味不明ですが、動いていそうです。
Data Firehose → S3の動作確認ができたので、CloudWatchメトリクスをこのストリームへ配信するためのリソースを作成していきます。

CloudWatch Metric Streams → Data Firehoseの動作確認

Metric Streams用IAMロール、メトリクスを収集したいリソースを準備する

下記ドキュメントを参考に、Metric Streamsにアタッチするサービスロールを作成します。

Metric Streamsは、メトリクスをstream形式で配信してくれるサービス、という認識で大丈夫です。

こんな感じのポリシーを持つロールを作りました。

policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "firehose:PutRecordBatch",
                "firehose:PutRecord"
            ],
            "Effect": "Allow",
            "Resource": "${aws_kinesis_firehose_delivery_stream.stream.arn}"
        }
    ]
}

次に、メトリクスを収集したいリソースを準備します。
今回は、複数のEC2のCPUUtilizationとNetworkOutを収集しようと思います。

適当にEC2を起動しました。

Metric Streamsを作成する

準備が終わったので、Metric Streamsを作成し、メトリクスをstream形式でData Firehoseに配信してみます！！！

マネコンに移動する

cloudwatchのマネコンから、「ストリーム」をクリックします。

メトリクスストリーム作成画面に移動する

「メトリクスストリームの作成」をクリックします。

セットアップ方法を選択する

セットアップ方法が表示されます。

デフォルトのクイックセットアップでは、DataFirehoseまで一緒に作られてしまうので、右端の「Custom setup」を選択します。

先ほど作成したDataFirehoseのストリームを選択します。

サービスロールを選択します。デフォルトから変更します。

先ほど作成したIAMロールを選択します。

出力フォーマットを変更する

今回はログファイルの中身をそのまま確認したいので、JSON形式を選択します。

ストリームするメトリクスを設定する

ストリーム対象のメトリクスを選択します。デフォルトでは全てのメトリクスが対象になっています。

名前空間を指定します。今回はEC2を対象とします。
Select metrics → Include → EC2 の順に選択します。

メトリクスを指定します。
任意のものを指定可能です。

メトリクスストリーム名を設定する

任意の名前を設定します。

リソースを作成する

「メトリクスストリームの作成」をクリックします。

正常に作られました。

S3にストリームが保存されることを確認する

5~10分ほど待機し、S3を確認します。

来てますね！
中身を確認します。以下のようなjsonが得られました。

{"metric_stream_name":"my-metric-stream","account_id":"123456789012","region":"ap-northeast-1","namespace":"AWS/EC2","metric_name":"CPUUtilization","dimensions":{"InstanceId":"i-05528977c4a5b0e40"},"timestamp":1726301400000,"value":{"max":0.3416780559351978,"min":0.2249962500624989,"sum":0.5666743059976966,"count":2.0},"unit":"Percent"}
{"metric_stream_name":"my-metric-stream","account_id":"123456789012","region":"ap-northeast-1","namespace":"AWS/EC2","metric_name":"NetworkOut","dimensions":{"InstanceId":"i-05528977c4a5b0e40"},"timestamp":1726301400000,"value":{"max":19653.0,"min":19203.0,"sum":38856.0,"count":2.0},"unit":"Bytes"}
{"metric_stream_name":"my-metric-stream","account_id":"123456789012","region":"ap-northeast-1","namespace":"AWS/EC2","metric_name":"CPUUtilization","dimensions":{"InstanceId":"i-00b59eb5cdf98b054"},"timestamp":1726301400000,"value":{"max":0.3584169639582569,"min":0.2248089124244392,"sum":0.5832258763826961,"count":2.0},"unit":"Percent"}
{"metric_stream_name":"my-metric-stream","account_id":"123456789012","region":"ap-northeast-1","namespace":"AWS/EC2","metric_name":"NetworkOut","dimensions":{"InstanceId":"i-00b59eb5cdf98b054"},"timestamp":1726301400000,"value":{"max":23298.0,"min":19131.0,"sum":61704.0,"count":3.0},"unit":"Bytes"}

めっちゃ良い感じ！！！
動作確認は以上です。簡単にメトリクスの保存ができました。

おわりに

メトリクスは永続的に保存されないことを知らず、
障害を復旧させた後、メトリクスを確認しようとしたら、メトリクスが消えていた・・・という経験があります。
今回のような対応で、しっかり永続化しておきたいですね。