Amazon CloudWatchとは ― メトリクス・ログ・アラームの役割

Amazon CloudWatchは、AWSのリソースとAWS上のアプリをリアルタイムで監視するサービスです。EC2のCPU使用率が上がり続けている、アプリがエラーを出しているといった状態に、すぐ気づけるようにします。AWS公式ドキュメントは、性能・運用上の健全性・リソースの使用状況を把握できるサービスだと説明しています。

中心になる機能は、メトリクス・ログ・アラーム・ダッシュボードの4つです。メトリクスは数値を、ログは文字列の記録を保存します。アラームはしきい値と比較して、通知や自動の動作を実行します。ダッシュボードは、それらを1画面に並べます。メトリクスとログを組み合わせて遅さの原因を調べる手順は、オブザーバビリティの記事で説明しています。

CPU使用率のように時間とともに変わる数値は、メトリクスとして保存します。アプリケーションが出力するエラーメッセージのような文字列は、ログとして保存します。アラームは、主にメトリクスを監視します。

ログの内容をアラームに使いたいときは、メトリクスフィルタを使えます。メトリクスフィルタは、ログから数値を取り出してメトリクスにする機能です。図の点線が、この流れです。

メトリクスとは、CloudWatchに送られた、時刻付きの数値の並びです。たとえば、あるEC2インスタンスのCPU使用率は、EC2が送るメトリクスの1つです。

AWSの多くのサービスは、メトリクスを自動でCloudWatchに送ります。EC2・EBS・RDSなどの基本のメトリクスは、既定では無料です。データが届く間隔は、サービスと設定で変わります。

メトリクスには、どのサービスのものかを表す名前空間があります。AWSのサービスのメトリクスは、EC2なら AWS/EC2 のように、AWS/サービス名 の名前空間に入ります。

ディメンションは、メトリクスを絞り込む名前と値の組です。EC2では InstanceId を指定すると、特定のインスタンスのメトリクスだけを取り出せます。メトリクスは、作られたリージョンにだけ存在します。リージョンの考え方は、リージョンとAZの記事で説明しています。

メトリクスのデータは、間隔が細かいほど、そのままの間隔で取り出せる期間が短くなります。短い間隔で送ったデータは、時間がたつと集約されて粗い間隔になります。

EC2が標準で送るメトリクスの一覧に、メモリ使用率はありません。メモリやディスク使用量のようなOS内部の値は、CloudWatchエージェントを導入して送信します。同じエージェントは、オンプレミスのサーバーに導入して使うこともできます。

エージェントは、利用者がインスタンスに導入して設定します。ゲストOSの管理が利用者側にあることは、責任共有モデルの記事で説明したとおりです。

詳細モニタリングや、自分で送るカスタムメトリクスは有料です。料金の考え方は、料金の記事にまとめています。

CloudWatch Logsは、ログファイルを監視・保存・参照するための機能です。EC2インスタンスやCloudTrail、Route 53などのログを扱えます。システムごとに散らばるログを、1か所に集めて検索できます。

既定では、ログは無期限に残り、期限切れになりません。保存期間はロググループごとに、1日から10年、または無期限の中から選べます。期間を過ぎたログは、自動で削除されます。

ログを対話的に検索・分析できるCloudWatch Logs Insightsもあります。クエリの書き方は省略します。

アラームとは、メトリクスをしきい値と比較し続け、結果に応じて状態を変える仕組みです。状態は次の3つのどれかになります。

• OK：メトリクスがしきい値の範囲内にある状態
• ALARM：メトリクスがしきい値の範囲外にある状態
• INSUFFICIENT_DATA：アラームを作った直後の状態。メトリクスが届かない状態や、判定に足りるデータがない状態も含みます

状態が変わると、アラームは動作を実行します。動作には、Amazon SNSのトピックへの通知・EC2の動作・Auto Scalingの動作などがあります。SNSは通知を配信するサービスで、メールでの通知にも使えます。SNSのトピックと購読者の仕組みは、SQSとSNSの記事で説明しています。

アラームの状態が変わると、そのイベントがAmazon EventBridgeにも届きます。そのため、ルールで別の処理につなげられます。

動作が実行されるのは、状態が変わったときだけです。Auto Scalingの動作だけは、新しい状態が続く間、1分に1回実行され続けます。

アラームを作るとき、いつ状態を変えるかを3つの設定で決めます。

• Period：1つのデータポイントを作るために使う時間。秒で指定します。
• Evaluation Periods（評価回数）：判定に使う、直近のデータポイントの数。
• Datapoints to Alarm（超える回数）：評価回数のうち、しきい値を超えているとALARMになるデータポイントの数。連続していなくてもかまいません。

Periodが1分以上のアラームは、1分ごとに判定されます。ただし、Periodに評価回数を掛けた長さが1日を超えると、判定は1時間ごとになります。超える回数が評価回数より少ない設定は、評価回数 N のうち M 回で判定するので「M out of N」と呼びます。

CPU使用率が70%を超える状態が続いたらALARMにする場合を、計算してみます。しきい値を超えた状態が続く時間は、Periodに評価回数を掛けた長さです。超える回数は、評価回数と同じにしています。

EC2の基本モニタリングでは、データが5分ごとに届きます。Periodも5分にすると、3回続いて15分になります。詳細モニタリングやRDSなら、データは1分ごとに届きます。5回続けても5分で判定できます。

次の図は、CPU使用率が5分ごとに72%・78%・84%と届いた例です。しきい値と判定のルールを切り替えると、アラームの状態が変わります。データが届かない場合も選べます。

しきい値が高いほど、超えるデータの数は減ります。しきい値75%では、超えたデータは2つです。3回すべて超える必要があるルールでは、OKになります。3回中2回でよいルールでは、ALARMになります。

評価に使う範囲のデータが1つも届かないと、既定の設定ではINSUFFICIENT_DATAになります。このときは、しきい値と判定のルールは関係しません。

データが欠けたときの扱いは、アラームごとに選べます。選べるのは次の4つで、既定は missing です。ただし、DynamoDBのメトリクスを監視するアラームは、ignore が既定です。

EC2のメトリクスを監視するアラームは、インスタンスが正常でもINSUFFICIENT_DATAになることがあります。データがまれに欠けるだけで、そうなります。

Auto Scalingは、スケーリングポリシーで台数を増減します。そのきっかけになるのが、CloudWatchのアラームです。EC2が送るCPU使用率のメトリクスを、アラームが監視します。ALARMになると、ポリシーが実行されます。

ステップスケーリングとシンプルスケーリングでは、利用者がアラームを作って管理します。ターゲット追跡では、Auto Scalingがアラームを作って管理します。公式ドキュメントは、ターゲット追跡のアラームを利用者が編集・削除しないよう注意しています。

ダッシュボードとは、メトリクスやログのグラフを1か所に並べた画面です。AWSの多くのサービスには、CloudWatchが自動で用意するダッシュボードがあります。自分で作らなくても見られます。アカウントやリージョンをまたいで共有することもできます。

アラームをダッシュボードに追加すると、状態が色で分かります。INSUFFICIENT_DATAのときは灰色、ALARMのときは赤、OKのときは色が付きません。

CloudTrailは、AWSアカウントの監査・ガバナンス・コンプライアンスのためのサービスです。ユーザー・ロール・AWSのサービスが行った操作が、イベントとして記録されます。CloudWatchが監視するのはリソースの状態で、CloudTrailが記録するのは操作です。

CloudTrailに記録される操作の主体は、IAMの記事で説明したユーザーやロールなどです。2つは組み合わせて使えます。CloudTrailのイベントは、CloudWatch Logsに送れます。すると、特定のAPI操作をCloudWatchのアラームで通知できます。イベント履歴と証跡の違いや、AWS Configとの使い分けは、CloudTrailの記事で詳しく説明しています。

• AWS「What is Amazon CloudWatch?」（定義、ダッシュボード、CloudWatchエージェント）
• AWS「Metrics concepts」（メトリクス、名前空間、ディメンション、保存期間）
• AWS「Manage detailed monitoring for your EC2 instances」（基本モニタリングと詳細モニタリング）
• AWS「Monitoring Amazon RDS metrics with Amazon CloudWatch」（RDSのメトリクスの間隔）
• AWS「What is Amazon CloudWatch Logs?」（ログの保存と保存期間）
• AWS「Amazon CloudWatch Logs concepts」（ログイベント・ストリーム・グループ）
• AWS「Using Amazon CloudWatch alarms」（アラームの動作、ダッシュボード上の色）
• AWS「Alarm evaluation」（3つの状態、Period・評価回数・超える回数）
• AWS「Configuring how CloudWatch alarms treat missing data」（欠けたデータの扱い）
• AWS「Step and simple scaling policies for Amazon EC2 Auto Scaling」（アラームとスケーリングポリシー）
• AWS「Target tracking scaling policies for Amazon EC2 Auto Scaling」（Auto Scalingが管理するアラーム）
• AWS「What Is AWS CloudTrail?」（CloudTrailの定義とイベント履歴）