Amazon Web Services ブログ

Amazon CloudWatch がダッシュボードにアラームを追加

Amazon CloudWatch は、AWS のリソースに関するメトリックス、ログ、イベントをリアルタイムで提供および収集することで、アマゾン ウェブ サービスで実行しているアプリケーション、システム、ソリューションをモニタリングできるサービスです。CloudWatch では、リソースのレイテンシー、エラー発生率、CPU 使用率などの主要メトリックスが自動的に測定されます。さらにお客様から提供されたログやシステムデータに基づくカスタムメトリックスのモニタリングも可能です。昨年 11 月、Amazon CloudWatch に新しいダッシュボードウィジェットが追加され、すべてのメトリックスのデータを視覚化できるようになりました。CloudWatch に追加されたダッシュボードのアラームにより、お客様は AWS で実行しているソリューションやリソースの状態を把握しやすくなりました。このアラームの追加により、アラームとメトリックスを同じダッシュボードウィジェットで確認して、データに基づくトラブルシューティングと分析を行うことができます。

CloudWatch のダッシュボードは、複数のリージョンにまたがる AWS リソースを統合されたビューでモニタリングする際の可視性を高めるためのものです。CloudWatch のダッシュボードは高度にカスタマイズ可能であるため、ユーザーは独自のダッシュボードを作成して使用率、パフォーマンス、請求予定額、そして今回のアラーム状態など、さまざまなメトリックスのデータをグラフィカルに表示できます。アラームは、各メトリックスの値と指定したしきい値の関係を経時的に追跡します。アラームの状態が変わると、Auto Scaling ポリシーなどのアクションが実行されます。または、Amazon SNS に通知が送信されます。ダッシュボードにアラームを追加するという新たな方法により、CloudWatch のユーザーは、複数のリージョンにまたがって AWS のリソースやアプリケーションをモニタリングして事前にアラートを受け取る手段が増えました。さらに、ダッシュボードに追加されたアラームでは、メトリックスのデータをグラフで確認できます。アラームには次の 3 つの状態があります。

  • OK: アラームのメトリックス値はしきい値に達していない
  • INSUFFICIENT DATA: データ不足。最初にトリガされたアラームのメトリックス値は、データ不足のため、[OK] 状態か [ALARM] 状態か判定できない
  • ALARM: アラームのメトリックス値はしきい値に達している

ダッシュボードでは、[ALARM] 状態は赤、[INSUFFICIENT DATA] 状態はグレイ、[OK] 状態は無色で表示されます。ダッシュボードのアラームは、Line、Number、Stacked area の各ウィジェットで表示できます。

  • Number ウィジェット: 目的のメトリックスの最新の値をすばやく効率的に確認できます。最新のメトリックスデータに応じてアラームの状態が変わるたびに背景色が変わります。
  • Line ウィジェット: 選択したメトリックスのコレクションの実値を線グラフで表示します。ダッシュボードにアラームのしきい値と状態が水平線で示されます。この水平線を境に、しきい値に達しているかどうかが一目でわかります。
  • Stacked area ウィジェット: 選択したメトリックスのコレクションについて正味の合計結果をグラフで表示します。Stacked area ウィジェットは、メトリックスの上に別のメトリックスをロードして、メトリックスの分布と貢献度を示します。オプションとして、メトリックスの貢献度をパーセントで表示することもできます。アラームのしきい値と状態も水平線で表示されます。

現在、アラームに関連する複数のメトリックスを同じウィジェットに追加する作業が進行中です。この機能はお客様からのフィードバックに基づいて進化しています。

ダッシュボードにアラームを追加する CloudWatch
ダッシュボードでアラームを使用する方法を簡単に確認しましょう。AWS コンソールで、CloudWatch サービスに移動します。CloudWatch コンソールで、[Dashboards] を選択します。[Create dashboard] ボタンをクリックして CloudWatchBlog ダッシュボードを作成します。

CloudWatchBlog ダッシュボードを作成すると、このダッシュボードにウィジェットを追加するためのダイアログボックスが表示されます。ここでは、ウィジェットを追加する手順をスキップして、ダッシュボードにアラームを追加する手順に進むことにします。したがって、[Cancel] ボタンをクリックして、CloudWatch コンソールの [Alarms] セクションに進みます。

CloudWatch コンソールの [Alarms] セクションでは、現在のリージョンのすべてのアラームとその状態が一覧表示されます。

既に述べたように、アラームには 3 種類の状態があります。上に示したコンソールには、アラームごとに状態が表示されています。必要に応じて、コンソールのフィルタを使って状態の種類別にアラームを表示することもできます。たとえば、状態が [ALARM] のアラームだけを確認するとします。この場合は、現在のリージョンで状態が [ALARM] のアラームをフィルタで絞り込みます。

これで、現在の状態が [ALARM] になっている 2 つのアラームだけが表示されます。1 つは、Amazon DynamoDB テーブルのプロビジョニングされた書き込みキャパシティーユニットをモニタリングするためのものであり、別の 1 つは、アクティブな Amazon Elasticsearch インスタンスの CPU 使用率をモニタリングするためのものです。

CloudWatchBlog ダッシュボードをトラブルシューティング手段として利用し、Elasticsearch ソリューションとそのインスタンスの問題を特定して診断するシナリオを検討してみましょう。まず、Amazon Elasticsearch の CPU 使用率のアラームとして [ES Alarm] を [CloudWatchBlog] ダッシュボードに追加します。アラームを追加するには、目的のアラーム (この例では [ES Alarm]) の横にあるチェックボックスを選択します。次に、アラームを選択した状態で、[Add to Dashboard] ボタンをクリックします。

表示された [Add to dashboard] ダイアログボックスで、CloudWatchBlog ダッシュボードを選択できます。ここで、アラームを表示するウィジェットの種類を選択することもできます。ES Alarm を Line ウィジェットで表示することにし、[Add to dashboard] ボタンをクリックして、このアラームをダッシュボードに追加します。

[ES Alarm] が [CloudWatchBlog] ダッシュボードに正常に追加されると、確認メッセージが CloudWatch コンソールに表示されます。

コンソールの [Dashboards] セクションに移動して [CloudWatchBlog] ダッシュボードを選択すると、[ES Alarm] アラームの Line ウィジェットがダッシュボードに表示されます。[ES Alarm] ウィジェットをダッシュボードの一部として保存するには、[Save dashboard] ボタンをクリックして、このウィジェットのダッシュボードへの追加を確定します。

既に説明したように、CloudWatch ダッシュボードを使用する利点の 1 つは、さまざまなリージョンからの複数のアラームをダッシュボードに追加できることです。この例では、ダッシュボードを Elasticsearch ソリューションのトラブルシューティング手段として利用しているので、このソリューションに関連するいくつかのアラームとメトリックスを [CloudWatchBlog] ダッシュボードに表示することにします。そのため、Elasticsearch インスタンス用に別のアラームを作成してダッシュボードに追加します。まず、コンソールの [Alarms] セクションに戻り、[Create Alarm] ボタンをクリックします。

[Create Alarm] ダイアログボックスが開いて、このリージョンで現在利用可能なすべてのメトリックスが表示されます。メトリックスの要約で、Elasticsearch のために 21 のメトリックスが追跡中であることを簡単に確認できます。[ES Metrics] リンクをクリックして、アラームの作成に使用できる各メトリックスを表示します。

Elasticsearch インスタンスのために表示された個別のメトリックスの中から、新しいアラームを関連付けるメトリックスを選択します。[WriteLatency] メトリックスを使うことにして、このメトリックスの横にあるチェックボックスを選択して [Next] ボタンをクリックします。

次の画面で、アラームの詳細として、名前、説明、アラームのしきい値、時間、アラームのアクションを入力します。新しいアラームの名前を ES Latency Alarm とし、他の残りのフィールドにも入力します。[Create Alarm] ボタンをクリックして、新しいアラームの作成を終了します。

アラームの追加が正常に終了すると、Alarms コンソールの上部に確認メッセージボックスが表示され、新しく作成したアラームの状態がアラームリストに表示されます。

次に、[ES Latency Alarm] を [CloudWatchBlog] ダッシュボードに追加します。アラームの横にあるチェックボックスを選択して [Add to Dashboard] ボタンをクリックします。

[Add to Dashboard] ダイアログボックスが開いたら、今回は [Stacked area] ウィジェットを選択します。このウィジェットを使用して [ES Latency Alarm] を [CloudWatchBlog] ダッシュボードに表示します。[Add to Dashboard] ボタンをクリックして、[ES Latency Alarm] ウィジェットをダッシュボードに追加します。

コンソールに戻ると、ウィジェットが正常に追加されたことを確認するメッセージが表示されます。[Dashboards] セクションで [CloudWatchBlog] ダッシュボードをクリックすると、ダッシュボードに 2 つのウィジェットが表示されます。このウィジェットをダッシュボードに保存するには、[Save dashboard] ボタンをクリックします。

最後に、CloudWatch の新しい機能であるダッシュボードのアラームでは、他のリージョンのアラームやメトリックスをダッシュボードに追加して全体をトラブルシューティングの対象にすることができます。アラームウィジェットを使ってダッシュボードにメトリックスを追加してみましょう。コンソール内で、現在のリージョンである米国東部 (オハイオ) から、米国東部 (バージニア北部) リージョンに移動します。

CloudWatch コンソールの [Metrics] セクションに進みます。このセクションに、米国東部 (バージニア北部) リージョンで使用されるサービスのメトリックスが表示されます。

Elasticsearch ソリューションは、Lambda 関数をトリガーして EmployeeInfo DynamoDB データベースの CRUD (作成、読み込み、更新、削除) のすべての変更を DynamoDB ストリーム経由でキャプチャし、それらの変更を Elasticsearch ドメインである taratestdomain 内に書き込みます。したがって、DynamoDB のテーブルメトリックスを追跡するためにメトリックスを [CloudWatchBlog] ダッシュボードに追加します。

そこで、[EmployeeInfo] データベースの [ProvisionedWriteCapacityUnits] メトリックスを [CloudWatchBlog] ダッシュボードに追加します。

[Add to Dashboard] ダイアログで、[CloudWatchBlog] ダッシュボードを選択し、このメトリックスを [Number] ウィジェットで表示することを選択します。

これで、米国東部 (バージニア北部) の [ProvisionedWriteCapacityUnits] メトリックスが [CloudWatchBlog] ダッシュボードに追加され、その Number ウィジェットが米国東部 (オハイオ) のアラームと一緒にダッシュボードに表示されます。この更新をダッシュボードに保存するには、もうおわかりだと思いますが、[Save dashboard] ボタンをクリックします。

 

まとめ
ダッシュボードの開始方法は簡単です。アラームを前もってモニタリングする新たな手段としてリージョンをまたいでダッシュボードのアラームを使用し、トラブルシューティング計画を策定して、目的のメトリックスを確認できます。また、最初にメトリックス UI でメトリックスを選択し、次にメトリックスの視覚化に適したウィジェットの種類に変更することもできます。ダッシュボードのアラームは、Line、Stacked area、Number の各ウィジェットで表示できます。さらに、ダッシュボードでアラームと並んでいる Text ウィジェットを使用して、アラームの状態の変更を処理する方法に関するステップや所見を追加することもできます。

Amazon CloudWatch のウィジェットおよびその他のダッシュボードのウィジェットの詳細については、Amazon CloudWatch ドキュメントおよび CloudWatch の「開始方法」を参照してください。

– Tara