CloudWatch Logsエージェント環境にCloudWatch統合エージェントへウィザードを使って設定を引き継いだ場合の挙動を確認する

いわさ

2021.11.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

CloudWatch Logsへログを転送したい場合、エージェントを設定することで簡単にログ転送を行うことが可能です。
このエージェントには、CloudWatch Logs エージェントとCloudWatchエージェントの２種類があります。

昔はCloudWatch Logs エージェントが使われていましたが、現在はCloudWatchエージェントでログ転送もメトリクス取得も統合されています。（この記事では便宜上、前者を旧エージェント、後者を新エージェントと呼びたいと思います。）

旧エージェントが稼働している環境に新エージェントをセットアップする場合にログ転送設定を引き継ぐことが出来ます。
その際にどういう動きをするのか観察してみました。

設定はどう引き継がれるのでしょうか。
また、旧エージェントは無効化されるのでしょうか。

先にまとめ

構成ウィザードを使うことでログ転送設定は引き継ぐことが出来る
旧エージェントの実行は無効化されないので、停止や削除は別途行う必要がある

確認したこと

Amazon Linux2環境にApacheをセットアップしアクセスログ(/var/log/httpd/access_log)を旧エージェントで転送する環境を用意します。
その後、その環境に新エージェントを設定を引き継ぐ形で導入します。

旧エージェントセットアップ

パッケージマネージャーでawslogsをインストールします。
その後、/etc/awslogs/awslogs.confにApacheログを転送する設定を追記します。
また、東京リージョン利用のために/etc/awslogs/awscli.confのリージョンを修正します。
事前にCloudWatch Logsへの設定は不要ですが、EC2のインスタンスプロファイルには相応の権限が必要です。

sh-4.2$ sudo yum install -y awslogs
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
amzn2-core                                                                                                                                            | 3.7 kB  00:00:00
Resolving Dependencies
--> Running transaction check
---> Package awslogs.noarch 0:1.1.4-3.amzn2 will be installed
--> Processing Dependency: aws-cli-plugin-cloudwatch-logs for package: awslogs-1.1.4-3.amzn2.noarch
--> Running transaction check
---> Package aws-cli-plugin-cloudwatch-logs.noarch 0:1.4.6-1.amzn2.0.1 will be installed
--> Finished Dependency Resolution

/etc/awslogs/awslogs.conf

[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/messages

[/var/log/httpd/access_log]
datetime_format = [%a %b %d %H:%M:%S.%f %Y]
file = /var/log/httpd/access_log
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /var/log/httpd/access_log

[/var/log/httpd/error_log]
datetime_format = [%a %b %d %H:%M:%S.%f %Y]
file = /var/log/httpd/error_log
buffer_duration = 5000
log_stream_name = {instance_id}
initial_position = start_of_file
log_group_name = /varlog/httpd/error_log

/etc/awslogs/awscli.conf

[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-1

設定完了後、awslogsdを実行し、サイトにアクセスしましょう。
少し待つとAWSマネージメントコンソール上からもCloudWatch Logsへログが転送されていることが確認出来ると思います。

sh-4.2$ sudo systemctl start awslogsd
sh-4.2$ sudo systemctl enable awslogsd.service

ログ転送されていることが確認出来ました。

新エージェントのセットアップ

次に、新エージェントをセットアップします。

今度はパッケージマネージャーでamazon-cloudwatch-agentをインストールします。
その後、amazon-cloudwatch-agent-config-wizardを実行し、対話形式でCloudWatchエージェントの設定ファイルを作成します。

その過程でCloudWatch Log Agentが使われているか問われるので、yesを選択します。(下記ハイライト部分）

sh-4.2$ sudo yum install amazon-cloudwatch-agent
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Resolving Dependencies
--> Running transaction check
---> Package amazon-cloudwatch-agent.x86_64 0:1.247347.4-1.amzn2 will be installed
--> Finished Dependency Resolution

...省略...

sh-4.2$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

...省略...

Do you have any existing CloudWatch Log Agent (http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) configuration file to import for migration?
1. yes
2. no
default choice: [2]:
1
What is the file path for the existing cloudwatch log agent configuration file?
default choice: [/var/awslogs/etc/awslogs.conf]
/etc/awslogs/awslogs.conf
Do you want to monitor any log files?
1. yes
2. no
default choice: [1]:
2
Saved config file to /opt/aws/amazon-cloudwatch-agent/bin/config.json successfully.

ウィザード完了後、config.jsonに選択した内容で設定がされています。

/opt/aws/amazon-cloudwatch-agent/bin/config.json

{
    "agent": {
        "metrics_collection_interval": 60,
        "run_as_user": "root"
    },
    "logs": {
        "force_flush_interval": 5,
        "logs_collected": {
            "files": {
                "collect_list": [
                    {
                        "file_path": "/var/log/httpd/access_log",
                        "log_group_name": "/var/log/httpd/access_log",
                        "log_stream_name": "{instance_id}"
                    },
                    {
                        "file_path": "",
                        "log_group_name": ""
                    },
                    {
                        "file_path": "/var/log/httpd/error_log",
                        "log_group_name": "/varlog/httpd/error_log",
                        "log_stream_name": "{instance_id}"
                    },
                    {
                        "file_path": "/var/log/messages",
                        "log_group_name": "/var/log/messages",
                        "log_stream_name": "{instance_id}",
                        "timestamp_format": "%b %d %H:%M:%S"
                    }
                ]
            }
        }
    },
    "metrics": {
        "append_dimensions": {
            "AutoScalingGroupName": "${aws:AutoScalingGroupName}",
            "ImageId": "${aws:ImageId}",
            "InstanceId": "${aws:InstanceId}",
            "InstanceType": "${aws:InstanceType}"
        },
        "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"
            }
        }
    }
}

後述しますが、一部不正な情報とログ転送部分以外は本検証の範囲外なので一旦削除しました。
先程の構成ウィザードでSSMパラメータストアへ登録するよう最後に選択していると同じ形式でパラメータが登録されていますので不要部分を削除します。

以下のように変更しました。

SSM Parameter

{
    "agent": {
        "metrics_collection_interval": 60,
        "run_as_user": "root"
    },
    "logs": {
        "force_flush_interval": 5,
        "logs_collected": {
            "files": {
                "collect_list": [
                    {
                        "file_path": "/var/log/httpd/access_log",
                        "log_group_name": "/var/log/httpd/access_log",
                        "log_stream_name": "{instance_id}"
                    },
                    {
                        "file_path": "/var/log/httpd/error_log",
                        "log_group_name": "/varlog/httpd/error_log",
                        "log_stream_name": "{instance_id}"
                    },
                    {
                        "file_path": "/var/log/messages",
                        "log_group_name": "/var/log/messages",
                        "log_stream_name": "{instance_id}",
                        "timestamp_format": "%b %d %H:%M:%S"
                    }
                ]
            }
        }
    }
}

パッと見、旧エージェントで設定していた内容が反映されていますね。
設定後、以下を参考に、SSMからRun Commandでエージェントを起動しました。

Run Commandの実行結果が正常終了していたら、CloudWatch Logsを確認してみましょう。

同一ログが重複して出力されていますね。
予想出来ていたかもしれませんが、旧エージェントと新エージェント両方からログ転送がされている状態になっていました。
やはり構成ウィザードでは設定ファイルの生成までで、旧エージェントの停止や削除をしてくれるものではありませんでした。

旧エージェントを停止しましょう。

sudo service awslogsd stop

停止後、ログは重複出力されなくなりました。

config.jsonの調整

構成ウィザード実行後のconfig.jsonそのままだとRun Commandでのエージェント起動に失敗しました。

不要なロググループの記述がある

この部分を削除しました。

ログ転送設定以外で記述上の問題ありそう（未解決）

パース時にエラーが発生していました。
目視で確認した限りログ転送部分は問題なさそうだったので、カスタムメトリクスは今回の検証範囲には不要ということでメトリクス部分は削除しました。

さいごに

CloudWatchエージェントの導入記事はいくつかあったのですが、

Do you have any existing CloudWatch Log Agent

で、デフォルトの2.noを選択している記事が多かったので、実証は大事ということで確認してみました。
製品によっては移行ウィザードで旧製品が停止したり削除されたりするものもありますしね。
結果としては予想どおりだったかもしれません。

旧エージェントは今後廃止予定ということで賞味期限の短い記事になりそうですが、まぁ残しておくかということで記事にしておきました。

CloudWatch Logsエージェント環境にCloudWatch統合エージェントへウィザードを使って設定を引き継いだ場合の挙動を確認する

先にまとめ

確認したこと

旧エージェントセットアップ

新エージェントのセットアップ

config.jsonの調整

不要なロググループの記述がある

ログ転送設定以外で記述上の問題ありそう（未解決）

さいごに

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

CloudWatch Logsエージェント環境にCloudWatch統合エージェントへウィザードを使って設定を引き継いだ場合の挙動を確認する

先にまとめ

確認したこと

旧エージェントセットアップ

新エージェントのセットアップ

config.jsonの調整

不要なロググループの記述がある

ログ転送設定以外で記述上の問題ありそう（未解決）

さいごに

イベント

EVENT【5/29（水）大阪】Alteryxの使い方から導入メリットまですべてがわかるセミナー＆ワークショップ

EVENT【5/15（水）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜フィンテック / リテール 業界案件特集〜 を開催します

EVENT【5/28（火）】AWSを最大活用するための1dayカンファレンス

EVENT【5/17（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

関連記事

[小ネタ]CloudWatch Agent で Agent 自身のプロセス監視を行なう

AWS Systems Manager Maintenance Windows を使って定期的なソフトウェアアップデートを行う

Act/Stb 構成のインスタンスのメトリクスを繋げてみた

[アップデート]Amazon EMRリリース 7.0.0よりクラスタのAmazon EC2をデフォルトでAmazon CloudWatch監視できるようになったので試してみた

EVENT【5/8リモート】クラスメソッドのフリーランスエンジニア会社説明会〜フィンテック / リテール業界案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！