Ubuntuのディスク使用率100%になっていたのでCloudWatchのアラートを追跡・解決してみた
どうもさいちゃんです。
Ubuntu インスタンスのディスク使用率を監視したところすぐにしきい値を超えてアラーム状態になってしまいました。
今回は起こった事象の原因と対処法についてまとめています。
起きた事象
Ubuntu インスタンスを作成し、CloudWatchAgent を使用してディスク使用率の監視をすることにしました。
いざアラームを作成してみると、すぐアラームが出ました。
まだほとんどインスタンスは使用していないのでアラームを見に行ってみると
ディスク使用率が 100 パーセントになっていました。
そんなはずはないと思い、実際のディスク使用率を確認してみることにしました。
原因調査
インスタンスにアクセスして df コマンドで確認してみると、実際にはほとんどボリュームが使われていませんでした。
user@hostname:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 290G 5.4G 285G 2% /
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 3.1G 900K 3.1G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
efivarfs 128K 3.8K 120K 4% /sys/firmware/efi/efivars
/dev/xxx 881M 137M 683M 17% /xxx
/dev/xxx 105M 6.1M 99M 6% /xxx
tmpfs 1.6G 12K 1.6G 1% /run/user/1000
CloudWatchAgent の設定ではすべてのディスクを監視対象に含めていたので、コンソール側からもどのディスクが 100%になっているのか確認してみることにしました。
該当のインスタンスのモニタリングタブからディスク使用率を確認してみます。
下記のように実際に使用率が 100%になっているのはループバックデバイスであることが分かります。
ファイル名を見る限り、ssm-agent や Ubuntu のベースシステムなどの、プリインストールされたシステムコンポーネントのループバックデバイスです。
これらは、Ubuntu の基本的な機能を提供するコアシステムパッケージとして、最初からインストールされています。
なぜこのようなことになったのでしょうか?
Ubuntu はプリインストールシステム関連のパッケージを snap でインストールしているようです。試しに Ubuntu で snap パッケージを表示してみます。
$ snap list
Name Version Rev Tracking Publisher Notes
amazon-ssm-agent 3.3.131.0 7993 latest/stable/… aws✓ classic
core18 20240612 2829 latest/stable canonical✓ base
core22 20250110 1748 latest/stable canonical✓ base
snapd 2.63 21759 latest/stable canonical✓ snapd
思った通り、amazon-ssm-agent や core22、snapd などが snap でインストールされていますね。
snap パッケージは squashfs という圧縮ファイルシステムを使用しています。
このファイルは、ループバックデバイスを通じてシステムにマウントされるため、snap でインストールを行う際にループバックデバイスが出来ます。
この時作成されたループバックデバイスはイメージ全体を「使用済み」と認識するため、常に 100%使用されているように見えてしまいます。
本来監視する必要がないこのループバックデバイスの使用量を監視してしまっていることが原因でアラートが出てしまっています。
この時使っていた CloudWatchAgent 設定ファイルはウィザードから作成していたものでした。
ウィザードで CloudWatchAgent の設定ファイルを作成するとデフォルトですべてのディスク使用率を取るようになってしまっています。
対処法
そういうことなら CloudWatchAgent の監視対象を絞りましょう!
監視対象の絞り方は2種類あります。
1.squashfs を明示的に拒否
明示的に squashfs を監視対象外とする方法です。
squashfs 以外はすべてのディレクトリを対象にディスク使用量の監視を行います。
メリットとしては、今後ボリュームが増えた場合でも CloudWatchAgent の設定変更は必要がないので管理が楽です。
しかし、カスタムメトリクスはメトリクス当たりのコストがかかるので不要なものまで監視してしまう恐れがある、squashfs 以外にも今回同様に不要なアラートが発生する可能性があります。
"disk": {
"measurement": ["used_percent"],
"resources": ["*"],
"ignore_file_system_types": ["squashfs"]
}
2.特定のデバイスのみを監視
90%以上になった時対処が必要なもののみに監視対象を絞る方法です。
不要なコストやアラートが発生しないのが一番大きなメリットです。
しかし、新たにボリュームをマウントした際に手直しが必要なので頻繁にディスクの追加が起こる様なシステムでは管理の手間がかかってしまいます。
"disk": {
"measurement": ["used_percent"],
"resources": ["/", "/boot", "/home"]
}
こんな感じで作成していますが、単純な EBS 1つをアタッチしているような場合は / だけを監視するでも問題ないと思います。
最終的に私は2つ目の方法で下記のようなCloudWatchAgent設定ファイルを作成しました。
{
"agent": {
"run_as_user": "root"
},
"metrics": {
"aggregation_dimensions": [["InstanceId"]],
"append_dimensions": {
"AutoScalingGroupName": "${aws:AutoScalingGroupName}",
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}"
},
"metrics_collected": {
"mem": {
"measurement": ["mem_used_percent"]
},
"disk": {
"measurement": ["used_percent"],
"resources": ["/"]
}
},
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
}
}
}
上記設定をインスタンスに反映させると無事アラートは消え、意図したディスク使用率を取ることが出来ました。
最後に
今回は Ubuntu インスタンスのディスク使用率を正常な値をとってくるための CloudWatchAgent の記述方法についてご紹介しました。
Ubuntu に限らずカスタムメトリクスでディスク使用率を取る場合は監視範囲を絞ってあげると不必要なアラートやコストがかからないということが分かりました。CloudWatchAgent の設定ファイルをウィザードから作る場合はディスク使用率の監視範囲に少し気を付けておくのがいいかもしれないですね。