AWS Lightsailで構築した環境にCloudWatch監視つけてみた話
前回Lightsailで作成した環境に「監視つけて。CPUとメモリとディスク使用量。CloudWatchに実行ログ転送もセットで」とのお達しを受けて、
例によってハイヨロコンデーと作業しまして。
……あとでトラブったのでちょっとそこもコミでメモ。
- やることはだいたいEC2と同じ。
⇒CloudWatchエージェント入れて設定して、CloudWatchエージェントを使うためにIAMユーザーを作成してLightsailにロール設定する。
⇒EC2でCloudWatchエージェントを設定した場合と、Lightsailで設定した場合ではメトリクス名と項目の紐づきが異なる。
- CPUはLightsailでアラート設定できる
⇒インスタンス→メトリクスからアラートが設定できるようになってるので、そっちで設定するのがラク。
[root@ip-HOG-EH-OG-IP logs]# cat /opt/aws/amazon-cloudwatch-agent/bin/config.json { "agent": { "metrics_collection_interval": 60, "run_as_user": "root" }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/messages", "log_group_name": "messages", "log_stream_name": "{local_hostname}", "retention_in_days": -1 }, { "file_path": "/var/www/char.gelgoog.jp/storage/logs/*.log", "log_group_name": "Lightsail/log/prod/laravel/web", "log_stream_name": "{local_hostname}", "retention_in_days": -1 }, { "file_path": "/var/www/char.gelgoog.jp/storage/logs/form/*.log", "log_group_name": "Lightsail/log/prod/laravel/web", "log_stream_name": "{local_hostname}_form", "retention_in_days": -1 }, { "file_path": "/var/www/char.gelgoog.jp/storage/logs/form2/*.log", "log_group_name": "Lightsail/log/prod/laravel/web", "log_stream_name": "{local_hostname}_form2", "retention_in_days": -1 }, { "file_path": "/var/log/httpd/*_log", "log_group_name": "Lightsail/log/prod/httpd/access", "log_stream_name": "{local_hostname}", "retention_in_days": -1 }, { "file_path": "/var/log/php-fpm/error.log", "log_group_name": "Lightsail/log/prod/php-fpm/error", "log_stream_name": "{local_hostname}", "retention_in_days": -1 } ] } } }, "metrics": { "metrics_collected": { "cpu": { "measurement": [ "cpu_usage_idle", "cpu_usage_iowait", "cpu_usage_steal", "cpu_usage_guest", "cpu_usage_user", "cpu_usage_system" ], "metrics_collection_interval": 60, "resources": [ "*" ], "totalcpu": true }, "disk": { "measurement": [ "used_percent" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "diskio": { "measurement": [ "io_time", "write_bytes", "read_bytes", "writes", "reads" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "mem": { "measurement": [ "mem_used_percent" ], "metrics_collection_interval": 60 }, "net": { "measurement": [ "bytes_sent", "bytes_recv", "packets_sent", "packets_recv" ], "metrics_collection_interval": 60, "resources": [ "*" ] }, "netstat": { "measurement": [ "tcp_established", "tcp_time_wait" ], "metrics_collection_interval": 60 }, "swap": { "measurement": [ "swap_used_percent" ], "metrics_collection_interval": 60 } } } }
log_stream_nameが{hostname}でなく{local_hostname}なのは、EC2ではなくLightsailのため。
{hostname} はEC2メタデータからホスト名を取得するため、Lightsailでは動作しないのです。
……これが原因でトラブル発生。
ログ転送は動いているものの、CloudWatchのアラームにメモリとディスクの使用率が届かなくなりました。
データ不足の表示になってアラートがブガーブガー。
(゜々。)<あれー、おっかしーなー?
ここでミソなのが、 上記の『EC2でCloudWatchエージェントを設定した場合と、Lightsailで設定した場合ではメトリクス名と項目の紐づきが異なる』ってとこ。
- EC2はインスタンスIDでCloudWatchアラームと紐づけする
- LightsailはEC2ではないのでインスタンスIDは無い
- LightsailのCloudWatchアラームはインスタンスIDで紐づけられていない
- LightsailのCloudWatchアラームはhostnameで紐づけられている
(੭ ᐕ)<おまえログ転送設定直すついでに何やった?
……はい、hostname変更しましたね……。
CloudWatchのメトリクスを見てみると、実際変更したhostnameでメモリとディスク使用率を送ってきてました。
で、あれば、と当該CloudWatchアラームのhostnameを変更するとデータ不足表示は解消されてアラートも鳴り止みました。
『LightsailだとCloudWatchアラームとインスタンスIDでの紐づけがない』
ので
『LightsailではCloudWatchアラームを設定後にhostnameを変更するとダメ』
という失敗談でございました。
……誰かのせいにしたいが自分の顔しか思い浮かばない。
Y.W 2024年4月26日
関連記事
『今度の開発はPHP8.0環境にLaravel8でソース組んでるんでインフラもそ…
← 前の投稿
AWSのアーキテクチャー図の自動生成次の投稿 →
花残月 2024