AWS:EC2のメモリ・ディスク使用率監視

Date:

Share post:

前回の投稿で予告したように、今回はEC2のメモリ・ディスク使用率に関する情報をCloudWatchで確認できるようにする方法について書きたいと思います。
具体的には「CloudWatchエージェント」という機能をEC2にインストールし、同機能が各種メトリクスをCloudWatch側に送信するという形をとります。

CloudWatchエージェントインストール

まずはCloudWatchエージェントをインストールします。
OSやCPUによって指定が異なるかと思いますが、今回はOSはUbuntu、CPUはXeon(またはAMD)系の環境を想定します。

具体的には以下のように実行します。

wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb
dpkg -i -E ./amazon-cloudwatch-agent.deb

UbuntuはDebian系なのでパッケージ管理にdpkgを使用しています。
上記で指定しているオプションですが、「-i」は「インストール」を意味し、「-E」は「同バージョンが既にインストール済みの場合は再インストールしない」ということを指定するものです。

なお、上記でCloudWatchエージェント自体のインストールは完了なのですが、サーバの状態に関する情報の採取自体は別のソフトを使用するようになっており、特にメモリ・ディスクに関する情報はcollectdなるソフトを使用して収集するようです。
よって、このソフトを合わせてインストールしておきます。

apt install collectd

CloudWatchエージェント設定

インストールしたCloudWatchエージェントに関する設定を行います。
以下のように実行します。

/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

以降様々な選択を求められますので、適宜回答して行きます。

On which OS are you planning to use the agent?
1. linux
2. windows
3. darwin
default choice: [1]:
1
Are you using EC2 or On-Premises hosts?
1. EC2
2. On-Premises
default choice: [1]:
1
Which user are you planning to run the agent?
1. root
2. cwagent
3. others
default choice: [1]:
1
Do you want to turn on StatsD daemon?
1. yes
2. no
default choice: [1]:
2
Do you want to monitor metrics from CollectD?
1. yes
2. no
default choice: [1]:
1
Do you want to monitor any host metrics? e.g. CPU, memory, etc.
1. yes
2. no
default choice: [1]:
1
Do you want to monitor cpu metrics per core? Additional CloudWatch charges may apply.
1. yes
2. no
default choice: [1]:
2
Do you want to add ec2 dimensions (ImageId, InstanceId, InstanceType, AutoScalingGroupName) into all of your metrics if the info is available?
1. yes
2. no
default choice: [1]:
1
Would you like to collect your metrics at high resolution (sub-minute resolution)? This enables sub-minute resolution for all metrics, but you can customize for specific metrics in the output json file.
1. 1s
2. 10s
3. 30s
4. 60s
default choice: [4]:
4
Which default metrics config do you want?
1. Basic
2. Standard
3. Advanced
4. None
default choice: [1]:
1
Are you satisfied with the above config? Note: it can be manually customized after the wizard completes to add additional items.
1. yes
2. no
default choice: [1]:
1
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]:
2
Do you want to monitor any log files?
1. yes
2. no
default choice: [1]:
2
Do you want to store the config in the SSM parameter store?
1. yes
2. no
default choice: [1]:
2

大半はデフォルト値のままで良いので、その場合は値を指定せずにリターンだけでも良いです。

Do you want to turn on StatsD daemon?」に関しては「StartsD」という「collectd」とは別の用途の情報採取ソフトを使うかどうかと言うことですが、今回は不要なので「2. no」を選択します。

Do you want to monitor cpu metrics per core? Additional CloudWatch charges may apply.」に関してはCPUコア単位での使用率取得を行うかどうかを設定しますが、追加費用が発生する場合があるようなので、「2. no」としておきます。

Do you want to monitor any log files?」に関してはログの情報収集を行うかどうかを設定しますが、今回は不要なので「2. no」を選択しています。
ログに関しては別投稿で書いたように「CloudWatch Logs エージェント」を使用して収集する設定を既に実施済みです。ただ、最初から本機能を使用すればログに関してもまとめて収集できていたのかもしれません。
次に機会があれば「CloudWatch Logs エージェント」を使用せず、こちらの機能の使用を試してみたいと思います。

「Do you want to store the config in the SSM parameter store?」ですが、SSM(AWS Systems Manager)はマネジメントコンソール上からEC2やオンプレミスサーバのリソース管理ができるようになる機能のようで、これを使用できるように設定するかどうかと言うことのようです。
便利そうですし、ネット上でのCloudWatchエージェントの設定に関する説明ではほぼ「1. yes」を選択するようになっていますが、そもそもSSMを使えるようにするための前準備が必要になりますし、使わなくても目的は達成できますので、今回は「1. no」としておきます。

上記実行結果は「/opt/aws/amazon-cloudwatch-agent/bin/config.json」なるファイルに保存されます。

CloudWatchエージェントの起動

設定が終わったらCloudWatchエージェントを起動します。

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

上記を実行するとCloudWatchのカスタム名前空間「CWAgent」としてメモリ使用率「mem_used_percent」とディスク使用率「disk_used_percent」なるメトリクスが採取されるようになります。ディスクに関しては1つのEC2に対して複数デバイスそれぞれの情報が記録されますが、「path」が「/」の情報が通常に使用しているディスク容量を示す情報と考えて良さそうです。

総括

前回の投稿でも書きましたが、メモリ・ディスク使用率のような基本的な情報が標準的に収集されるようになっていない点は大いに疑問ですが、とりあえずはこれら情報をCloudWatchで確認できるようになりました。

設定においてはよく分からずにデフォルト値を採用しただけの部分もありますので、しっかり理解して使えば、もっと便利に使えるようになるかもしれません。
その辺の研鑽は今後の課題ということで。

Related articles

EC-CUBE 4系のプラグイン開発について その...

前回、プラグインを一旦有効化させて管理...

EC-CUBE 4系のプラグイン開発について その...

以前から作成したいと考えていたのですが...

Laravel Filamentを使用した管理画面...

前回Breezeをインストールしたこと...

Laravel Filamentを使用した管理画面...

前回、filamentでのリソース作成...