CloudWatchエンドポイントがIPv6に対応したのでCloudWatchエージェントからカスタムメトリクスを送信しました

2026/01/02 2026/01/03

追記

翌日のブログで、CloudWatchエージェントのアップデートにより、CloudWatchとEC2両方のデュアルスタックエンドポイントを使用できる方法を記録しています。
素早く対応方法を知りたい方はそちらをご覧ください。

CloudWatchエージェントがEC2サービスエンドポイントのデュアルスタックに対応したのでIPv6だけでカスタムメトリクス送信できた！

ブログの状況

昨年の1月頃にこのブログのパブリックIPv4アドレスをなくしました。
当時はPutMetricDataの送信先のCloudWatchエンドポイントがIPv6に対応していなかったので、カスタムメトリクスは諦めました。
CloudWatch Logsは当時からIPv6に対応していたので、CloudWatchエージェントはログだけを送信していました。

CloudWatchエンドポイントのIPv6対応

Amazon CloudWatch が IPv6 のサポートを開始
昨年7月にCloudWatchエンドポイントがIPv6に対応しました！

他のサービス同様に既存のIPv4エンドポイントとは別に、IPv4とIPv6の両方に対応したデュアルスタックエンドポイントが追加されました。

東京リージョンの場合、既存エンドポイントはmonitoring.ap-northeast-1.amazonaws.comで、デュアルスタックエンドポイントはmonitoring.ap-northeast-1.api.awsです。

CloudWatchエージェントの設定

CloudWatchエージェントのパラメータのmetricsセクションで、endpoint_overrideを設定して、デュアルスタックエンドポイントに送信するようにしました。

"metrics": {
    "endpoint_override": "monitoring.ap-northeast-1.api.aws",

"metrics": {

"endpoint_override": "monitoring.ap-northeast-1.api.aws",

上記の設定を/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.jsonに追記して、CloudWatchエージェントを停止して、開始しました。

停止

amazon-cloudwatch-agent-ctl -a stop

1 2	amazon-cloudwatch-agent-ctl -a stop

開始

amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json

1 2	amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json

動的なディメンションが追加できない問題が残りました

従来、カスタムメトリクスではmetricsセクションにディメンションとして、オートスケーリンググループの名前やインスタンスIDを設定します。

"append_dimensions": {
    "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
    "InstanceId": "${aws:InstanceId}",
},

"append_dimensions": {

"AutoScalingGroupName": "${aws:AutoScalingGroupName}",

"InstanceId": "${aws:InstanceId}",

こうしておかないと、例えば次のようなメモリ使用量を取得した場合、その次の画面のようにすべてのインスタンスから送信されたカスタムメトリクスが区別なく表示されるので本来のモニタリングの目的を果たせなくなります。

"mem": {
    "measurement": [
        "mem_used_percent"
    ],

"mem": {

"measurement": [

"mem_used_percent"

そこで、append_dimensionsを設定します。
すると、次のエラーが/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.logに出力されました。

{
    "caller": "ec2tagger/ec2tagger.go:465",
    "msg": "ec2tagger: Unable to describe ec2 tags for initial retrieval",
    "kind": "processor",
    "name": "ec2tagger",
    "pipeline": "metrics/host",
    "error": "RequestError: send request failed\ncaused by: Post \"https://ec2.ap-northeast-1.amazonaws.com/\": dial tcp 99.77.62.122:443: i/o timeout"
}

{

"caller": "ec2tagger/ec2tagger.go:465",

"msg": "ec2tagger: Unable to describe ec2 tags for initial retrieval",

"kind": "processor",

"name": "ec2tagger",

"pipeline": "metrics/host",

"error": "RequestError: send request failed\ncaused by: Post \"https://ec2.ap-northeast-1.amazonaws.com/\": dial tcp 99.77.62.122:443: i/o timeout"

}

EC2のサービスエンドポイントhttps://ec2.ap-northeast-1.amazonaws.com/へリクエスト送信してエラーになっています。
EC2にもec2.ap-northeast-1.api.awsというIPv6対応のデュアルスタックエンドポイントはありますが、${aws:InstanceId}などを設定した際に、CloudWatchエージェントのリクエスト先をそちらへ向ける方法がわかりません。

CloudWatch Logsのログストリームのように、”{instance_id}”と設定してメタデータから取得してくれればいいのですが、これもできないようです。

このAWSアカウントの東京リージョンでは、このブログのオートスケーリンググループしか起動していないので、ディメンションなしでもいいかもしれませんが、ひとまず今日はここまでとして、また解決しましたら別ブログに記録します。
最終的に現在のamazon-cloudwatch-agent.jsonのパラメータは次のようになりました。

{
  "agent": {
    "metrics_collection_interval": 60
    "run_as_user": "root"
  },
  "logs": {
    "endpoint_override": "logs.ap-northeast-1.api.aws",
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/nginx/access.log",
            "log_group_name": "/blog/nginx-access",
            "log_stream_name": "{instance_id}"
          },
          {
            "file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
            "log_group_name": "/blog/cwagent",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  },
  "metrics": {
    "endpoint_override": "monitoring.ap-northeast-1.api.aws",
    "metrics_collected": {
      "collectd": {
        "metrics_aggregation_interval": 60
      },
      "disk": {
        "measurement": ["used_percent"],
        "metrics_collection_interval": 60,
        "resources": ["*"]
      },
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "statsd": {
        "metrics_aggregation_interval": 60,
        "metrics_collection_interval": 10,
        "service_address": ":8125"
      }
    }
  }
}