Mackerel を触ってみる（AWS インテグレーション編）
2024.08.27はじめに
こちらのブログの続編になります。
オーガニゼーション作成～ホストを監視対象に含めるところまでの過程を知りたい方は、まずはこちらをご覧ください。
前提知識
Mackerel の AWS インテグレーションを設定すると、AWS クラウド製品を Mackerel のホストとして管理し、メトリックを監視することが可能になります。
例えば、AWS インテグレーションで連携をおこなった場合、EC2 で取得できるメトリックは以下の通りです。
やってみる
AWS インテグレーションを利用して、EC2 の監視項目を増やしてみます。
1. インテグレーション用の IAM ロールを作成する
監視対象の EC2 が存在する AWS アカウントで、インテグレーション用の IAM ロールを作成します。
まず IAM ロール作成時に必要な外部 ID をコピーします。
Mackerel 管理画面で「オーガニゼーション名」＞「AWS インテグレーション」＞「AWSインテグレーションを登録」の順にクリックします。
基本設定 ＞ AWS アカウント にある「外部 ID」をコピーします。
続けて IAM ロールを作成します。
AWS にサインインし、IAM ＞ ロールに移動し、「ロールを作成」をクリックします。
- 信頼されたエンティティタイプ：
AWS アカウント - AWS アカウント：
別の AWS アカウント- アカウント ID：
217452466226
- アカウント ID：
- オプション：外部 ID を要求する → 有効
- 先ほどコピーした「外部 ID」を入力する
上記の内容を選択・入力したら「次へ」をクリックします。
今回は EC2 の監視項目を増やしたいので、「AmazonEC2ReadOnlyAccess」を選択し、「次へ」をクリックします。
「ロール名」と「説明」を適宜入力し、内容を確認してから「ロールを作成」をクリックします。
作成したロールの詳細画面で、ARN をコピーします。
2. AWS インテグレーションを設定する
Mackerel 管理画面で「オーガニゼーション名」＞「AWS インテグレーション」＞「AWSインテグレーションを登録」の順にクリックします。
先ほどコピーした ARN を「ロール ARN」に入力します。
他、「名前」も適宜入力し、「リージョン」は監視対象 EC2 が東京リージョンに存在しているため「ap-northeast-1」を選択しました。
メトリックを収集するサービスは、一旦 EC2 のみを選択しました。
また、今回はタグを指定して登録するホストを絞り込みたいので、以下のように入力しました。
最後に「作成」をクリックします。
AWS インテグレーションが作成できました。
続けて、監視対象 EC2 にタグを付与します。
するとタグを付与してから数分後、Mackerel 管理画面上に AWS インテグレーションによるカスタムメトリックが反映され始めました。
3. 監視ルールを追加する
カスタムメトリックとして取得できる状態になったので、これを使用して監視ルールを設定します。
今回は CPU 使用率の監視ルールを追加してみます。
左メニューの「監視ルール」＞「監視ルールを追加」をクリックします。
「ホストメトリック監視」をクリックします。
監視対象で以下を設定します。
- メトリック：
custom.ec2.cpu.used - 閾値：Warning 条件として >
90%、平均値監視1点の平均値を監視 - 絞込：サービス →
EC2、ロール →*（すべて）
基本設定で以下を設定します。
- 監視ルール名：
CPU Utilization - 監視ルールのメモ：
CPU 使用率
最後に「作成」をクリックします。
すると、監視ルールの一覧に作成した CPU Utilization が表示されます。
ホスト（EC2）の詳細画面を確認すると、connectivity と追加した CPU Utilization が監視対象になったことが確認できます。
※ 監視ルール作成後、ホスト詳細画面の Monitors に反映されるまでには数分かかりました。即反映ではないので気長にお待ちください。
4. CPU 負荷テストを実施してみる
セッションマネージャー経由で EC2 にログインします。
stress-ng コマンドを使用して CPU 負荷テストを実施してみます。
実際のログ
$ sudo yum install -y stress-ng
Last metadata expiration check: 6:12:41 ago on Tue Aug 27 01:53:18 2024.
Dependencies resolved.
===========================================================================================================================================
Package Architecture Version Repository Size
===========================================================================================================================================
Installing:
stress-ng x86_64 0.15.05-1.amzn2023 amazonlinux 2.3 M
Installing dependencies:
Judy x86_64 1.0.5-25.amzn2023.0.3 amazonlinux 153 k
libbsd x86_64 0.10.0-7.amzn2023.0.2 amazonlinux 109 k
lksctp-tools x86_64 1.0.18-9.amzn2023.0.3 amazonlinux 92 k
Transaction Summary
===========================================================================================================================================
Install 4 Packages
Total download size: 2.7 M
Installed size: 9.7 M
Downloading Packages:
(1/4): Judy-1.0.5-25.amzn2023.0.3.x86_64.rpm 1.3 MB/s | 153 kB 00:00
(2/4): lksctp-tools-1.0.18-9.amzn2023.0.3.x86_64.rpm 783 kB/s | 92 kB 00:00
(3/4): libbsd-0.10.0-7.amzn2023.0.2.x86_64.rpm 878 kB/s | 109 kB 00:00
(4/4): stress-ng-0.15.05-1.amzn2023.x86_64.rpm 11 MB/s | 2.3 MB 00:00
-------------------------------------------------------------------------------------------------------------------------------------------
Total 7.0 MB/s | 2.7 MB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : lksctp-tools-1.0.18-9.amzn2023.0.3.x86_64 1/4
Installing : libbsd-0.10.0-7.amzn2023.0.2.x86_64 2/4
Installing : Judy-1.0.5-25.amzn2023.0.3.x86_64 3/4
Installing : stress-ng-0.15.05-1.amzn2023.x86_64 4/4
Running scriptlet: stress-ng-0.15.05-1.amzn2023.x86_64 4/4
Verifying : Judy-1.0.5-25.amzn2023.0.3.x86_64 1/4
Verifying : libbsd-0.10.0-7.amzn2023.0.2.x86_64 2/4
Verifying : lksctp-tools-1.0.18-9.amzn2023.0.3.x86_64 3/4
Verifying : stress-ng-0.15.05-1.amzn2023.x86_64 4/4
Installed:
Judy-1.0.5-25.amzn2023.0.3.x86_64 libbsd-0.10.0-7.amzn2023.0.2.x86_64 lksctp-tools-1.0.18-9.amzn2023.0.3.x86_64
stress-ng-0.15.05-1.amzn2023.x86_64
Complete!
$
$ date
Tue Aug 27 08:49:36 UTC 2024
$ sudo stress-ng --cpu 1 --timeout 420s
stress-ng: info: [32439] setting to a 420 second (7 mins, 0.00 secs) run per stressor
stress-ng: info: [32439] dispatching hogs: 1 cpu
stress-ng: info: [32439] successful run completed in 420.00s (7 mins, 0.00 secs)
$
するとしばらくしてアラートメールを受信しました。
Mackerel のホスト詳細画面を確認すると、これ（赤丸）を検知してアラートが発報されたことが分かります。
今回監視メトリックに指定した custom.ec2.cpu.used の取得間隔は、連携している AWS アカウントの CloudWatch の監視間隔に準じます。
連携している AWS アカウントはデフォルトの間隔なので、5 分間隔粒度でメトリックが取得されています。
そのため、stress-ng コマンドを実行した時刻（日本時間 17:49 頃）からアラートメール受信（日本時間 18:01）まで少しラグが発生していました。
しばらくすると、アラートクローズメールを受信しました。
ということで、CPU 使用率の監視ルールを追加し、異常時はアラートが発報されることが確認できました。
あとがき
本記事では AWS インテグレーション編として、AWS インテグレーションを設定することにより取得できるメトリックを使用して監視ルールを作成、テストするところまでをまとめました。
次はログ監視についてまとめたいと思います。
この記事がどなたかのお役に立てれば幸いです。
参考資料
アノテーション株式会社について
アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。
サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイトをぜひご覧ください。
