こんにちは、SCSKの嶋谷です。
AWSサービスの監視は、Amazon CloudWatchアラームで監視対象のメトリクス(CPU使用率やディスク使用率等)に関するアラート条件を設定してAmazon SNS(Simple Notification Service)を用いてメール等に送信する方法が一般的ではないでしょうか。CloudWatchを用いた方法は監視対象毎にアラート条件を設定して管理する必要があり、とても大変ではないでしょうか。また、サービスを組み合わせてアラーム作成を自動化することも可能ですが、この手法を構築することも大変ではないでしょうか。今回はAWSでの通知方法を監視サービス「Mackerel」で代替したときの設定方法や通知内容が気になり、実際に検証してみました。今回の検証ではアラートの通知先をメールとしています。
AWSでのアラート通知方法
まずは、AWSでのアラート通知方法について説明します。今回はAmazon EC2のCPU使用率が80%を超えた時にアラート通知が送信されるように設定します。
(1)AWSのコンソールにログインし、左上の検索バーで「CloudWatch」と入力し、エンターを押す
(2)左側タブの「すべてのアラーム」をクリックし、「アラームの作成」をクリック
(3)「メトリクス選択」をクリックして監視対象EC2の「CPUUtilization」メトリクスを選択
(4)条件を設定(今回はCPU使用率の5分間の平均値が80%を超えているときにアラート通知を送信)
(5)トピックの作成
通知先をメールにするため、「新しいトピックの作成」を選択して、トピック名と通知先アドレスを
入力して「トピックの作成」をクリック。この設定でSNSのトピックとサブスクリプションが自動的
に作成されます。
(6)通知先アドレスに届いたメール「Confirm subscription」をクリック
(7)アラーム名を設定して作成が完了
AWSでのアラート通知が設定できたので、実際にメールが来るかを検証してみます。
下記コマンドを使用して疑似的にCPUへ負荷をかけて検証しました。
# yes > /dev/null
CPUが80%を超えると下記のようなメールが届きました。メールの内容は、メールが送信された理由(CPU使用率が80%を超えた)とアラートの詳細(アラーム名やアカウント情報)について記載されています。
これにてAWSでの設定からテストまで完了しました。特に詰まることなく作業を完了することができました。
Mackerelでのアラート通知方法
次にMackerelで設定する方法について解説していきます。
Mackerelで通知するためにはまずAWSのサービスを監視対象としてMackerelに登録する必要があります。MackerelではAWSインテグレーション機能を利用することでAWSサービスを作成するだけでMackerelのコンソール上にAWSサービスがホスト名で登録されます。AWSインテグレーションについては下記をご参照ください。MackerelへのEC2登録後の作業を説明します。
Mackerel で AWS のサーバーレスサービスを監視してみた
(1)サービス・ロールを作成
サービスはECサイトシステム、ロールはECサイトシステムのDB機能やWeb機能のように考えれば
イメージが湧きやすいです。サービス・ロールの詳細については下記をご参照ください。ただ、サー
ビス・ロールについてはMackerelを使用する上で肝になる部分だと思っているので、次回のブログ
で説明したいと考えています。
「サービス」「ロール」とは
Mackerelコンソールの左側タブのサービスをクリックした後、「サービスを追加する」をクリック
してサービス名を入力するとサービスが作成できます。作成したサービスを選択し、「ロールを新規
作成」をクリックしてロール名を入力するとロールが作成できます。
(2)Mackerelコンソール上に登録されている監視対象ホストにロールの割り当て
ホスト一覧画面の監視対象ホストの「サービス・ロール」欄をクリックすると下記の画面が出力され
るので、(1)の手順で作成したロールを割り当てる。
(3)監視ルール(アラートを検知する条件)を作成
今回は前章と同様に5分間のCPU使用率が80%超えるとアラートが出るように設定します。
ここで監視対象を絞り込むことが重要です。絞り込まないとMackerelに登録されている全ホストが
監視対象になってしまいます。検証の際に1度目の設定時に絞り込みを忘れ、監視対象以外のホスト
のアラートが出てしまい、監視対象のアラートをMackerel上で発見するのに苦労しました。
(4)通知グループ(通知条件)を作成して通知チャンネル(通知先)を紐づけ
通知グループ・通知チャンネルについては下記をご参照ください。
監視・通知を設定する – Mackerel ヘルプ
まず通知チャンネルを作成します。今回はメールによる通知を行うため「メール通知」を選択して
通知先のメールアドレスを選択して作成します(Mackerelではメール以外にもTeamsやSlackなどの
さまざまなサービスを通知先として選択できます)。次に通知グループを作成します。
サービスとして(1)の手順で作成したサービスを、通知先として(4)の手順で作成した通知チャンネル
を選択します。
Mackerelでアラート通知設定ができたので、前章と同じようにCPUに負荷をかけてメールが来るかを検証してみました。
CPUが80%を超えると下記のようなメールが届きました。メールの内容は、CPU使用率のグラフとアラート発生時のCPU値とアラート条件のCPU値が記載されています。
これにてMackerelでの設定からテストまで完了です。メールにグラフが表示されるのは、使用率の推移がメールで理解できるので便利だなと思いました。
EC2を増加させたときの方法
これまではEC2を1台作成したときのAWS・Mackerelでの通知設定の方法について説明しました。システムを構築していくうえでサーバ(EC2)は1台とは限らず、2,3,4台のように複数台で構成されるのが一般的だと思います。その場合のAWSやMackerelでの設定方法について説明します。(今回は監視要件が同じ場合を対象としています。)
AWSの場合
①今回の記事内容のように1台ずつCloudWatchのアラームを作成
個々のEC2に対して手動でCloudWatchアラームを作成する方法です。この方法では、監視要件や通知先が同じ場合にアラーム名が異なるCloudWatchアラームをEC2それぞれで作成する必要があるため、手間がかかります。私は②の方法で自動化しました。
②他サービスを連携してアラーム作成を自動化
Amazon EventBridgeとLambdaを利用してEC2の作成をトリガーとしてCloudWatchアラームを自動で作成する方法です。構成図を以下に示しております。今回はソースコードなどの掲載は省略します。
①の方法では、EC2を作成するたびにCloudWatchアラームを作成する必要があり手間でした。②の方法を実装することでユーザはEC2を作成するだけで通知設定が自動で完了するため、とても便利な方法です(②の手順を実装することに時間がかかりますが・・・)。サーバの台数が少ない場合は①の手順でアラームを作成する方法でも問題ないかもしれません。
Mackerelの場合
Mackerelでは、サービスやロールはEC2を1台作成した際に作成済であるため、新しく作成する必要はありません。そのため、2章の(2)の作業のようにロールを割り当てるだけで2台目以降は簡単に通知設定を完了させることができます。今回の検証においても時間をかけることなく2台目以降の通知設定を完了させることができました。
AWSとMackerelでの実装を終えて
AWSでは複数のサービスを連携することでアラート通知の設定を自動化することができるため、作成するまでの苦労を乗り越えれば後から楽ができるなと感じました。
Mackerelでは通知設定を1つ作成してしまえば、後からは1作業(ロール割り当て)で設定が完了するためこの方法も楽だなと感じました。
AWS・Mackerelでの通知方法については両サービスそれぞれの特徴があると思うので、状況によって使い分けるべきだと思いました。
ただ、どちらの方法も容易かつ便利であることは同じだと思いました。
まとめ
今回はAWSサービスの監視をAWSサービスを使用して実装する方法とMackerelで実装する方法の2種類を検証してみました。どちらの手法も簡単な操作で実装することができました。今回はEC2を増加させた場合についての実装方法を記載しましたが、次回はサービスの増減・アラート条件の変更・通知先の変更などの実際の運用現場を想定した実装方法についてMackerelの「サービス・ロール」に絡めながら記載したいと思います。