CloudWatchエンドポイントがIPv6に対応したのでCloudWatchエージェントからカスタムメトリクスを送信しました
目次
ブログの状況
昨年の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を設定して、デュアルスタックエンドポイントに送信するようにしました。
|
1 2 3 |
"metrics": { "endpoint_override": "monitoring.ap-northeast-1.api.aws", |
上記の設定を/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.jsonに追記して、CloudWatchエージェントを停止して、開始しました。
停止
|
1 2 |
amazon-cloudwatch-agent-ctl -a stop |
開始
|
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を設定します。
|
1 2 3 4 5 |
"append_dimensions": { "AutoScalingGroupName": "${aws:AutoScalingGroupName}", "InstanceId": "${aws:InstanceId}", }, |
こうしておかないと、例えば次のようなメモリ使用量を取得した場合、その次の画面のようにすべてのインスタンスから送信されたカスタムメトリクスが区別なく表示されるので本来のモニタリングの目的を果たせなくなります。
|
1 2 3 4 5 |
"mem": { "measurement": [ "mem_used_percent" ], |
そこで、append_dimensionsを設定します。
すると、次のエラーが/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.logに出力されました。
|
1 2 3 4 5 6 7 8 9 |
{ "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のパラメータは次のようになりました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
{ "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" } } } } |
最後までお読みいただきましてありがとうございました!
「AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル 改訂第2版」という本を書きました。
「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー 改訂第3版」という本を書きました。
「ポケットスタディ AWS認定 デベロッパーアソシエイト [DVA-C02対応] 」という本を書きました。
「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。
「AWSではじめるLinux入門ガイド」という本を書きました。
開発ベンダー5年、ユーザ企業システム部門通算9年、ITインストラクター5年目でプロトタイプビルダーもやりだしたSoftware Engineerです。
質問はコメントかSNSなどからお気軽にどうぞ。
出来る限りなるべく答えます。
このブログの内容/発言の一切は個人の見解であり、所属する組織とは関係ありません。
このブログは経験したことなどの共有を目的としており、手順や結果などを保証するものではありません。
ご参考にされる際は、読者様自身のご判断にてご対応をお願いいたします。
また、勉強会やイベントのレポートは自分が気になったことをメモしたり、聞いて思ったことを書いていますので、登壇者の意見や発表内容ではありません。
ad
ad
関連記事
-
-
EC2 Auto Recovery機能を設定しておいた
以前EC2インスタンスのリタイア対象になったこともあり、というより、やっておいて …
-
-
「Amazon EKS Workshop」の環境準備とクラスター作成
今はアーカイブになっている1つ前のEKS Workshopの環境準備記録です。 …
-
-
ブログの画像を別アカウントのS3に移動するためにIAMロールでクロスアカウントアクセス
ずっと先延ばしにしていたのですが、このブログの画像はEC2から直接配信しています …
-
-
EC2にSystems MangerからCloudWatchエージェントをインストール
CloudWatchエージェント EC2の標準メトリクスでは収集できないメモリの …
-
-
CloudTrailイベントのコストしか発生していないリージョンのコスト発生源を調査しました
調査のきっかけ ふと検証用AWSアカウントのCostExplorerを見てました …
-
-
VyOSにSSMエージェントをインストールしました
VyOSにSSHでログインするのも面倒なので、SSMエージェントをインストールし …
-
-
CodeBuildで執筆原稿データをまとめた
今書いている原稿に対して編集者さんから、「できればで構わないのですが、章ごとにマ …
-
-
Amazon Linux2(EC2)にEC-CUBE 4をインストール
こちらのHOMEお知らせ・コラムAmazon Linux2にEC-CUBE4.0 …
-
-
API Gateway Lambdaプロキシ統合で渡されるリクエストを確認しました
API Gatewayの統合リクエストでLambdaを指定するときにプロキシ統合 …
-
-
AWS Toolkit for EclipseからLambda関数を直接作成できずにMavenでパッケージ化して作成
AWS Toolkit for EclipseからLambda関数を直接作成 チ …


