接続されたデータソースに基づいてアラームを作成する - Amazon CloudWatch
接続されているデータソースのアラームに関する詳細

接続されたデータソースに基づいてアラームを作成する

CloudWatch にないデータソースのメトリクスを監視するアラームを作成できます。これら以外のデータソースへの接続を作成する方法の詳細については、「他のデータソースにあるメトリクスへのクエリ」を参照してください。

接続しているデータソースのメトリクスに関するアラームを作成するには

  1. CloudWatch コンソール (https://console.aws.amazon.com/cloudwatch/) を開きます。

  2. ナビゲーションペインで、[Metrics]、[All metrics] を選択します。

  3. [マルチソースクエリ] タブを選択します。

  4. [データソース] で、使用するデータソースを選択します。

  5. クエリビルダーから、アラームに使用するメトリクスを取得するためのクエリに必要な情報の入力を求められます。ワークフローはデータソースごとに異なり、データソースに合わせて調整されます。例えば、Amazon Managed Service for Prometheus と Prometheus データソースの場合、PromQL クエリエディタボックスがクエリヘルパーと共に表示されます。

  6. クエリの作成が完了したら、[グラフクエリ] を選択します。

  7. サンプルグラフが期待どおりになったら、[アラームの作成] を選択します。

  8. [メトリクスと条件の指定] ページが表示されます。使用しているクエリが複数の時系列を生成する場合は、ページの上部に警告バナーが表示されます。その場合は、[集計関数] で時系列の集計に使用する関数を選択します。

  9. (オプション) アラームの [ラベル] を追加します。

  10. [your-metric-name が次の時...] で、[より大きい]、[以上]、[以下]、または [より低い] から選択します。次に、[... よりも] で、しきい値の数値を指定します。

  11. [Additional configuration (追加設定)] を選択します。[Datapoints to alarm (アラームを発生させるデータポイント数)] で、アラームをトリガーするために ALARM 状態を維持する必要がある評価期間 (データポイント) の数を指定します。2 つの値が一致する場合は、該当する数の連続した期間でしきい値を超過したときに ALARM 状態に移行するアラームを作成します。

    N 個中 M 個のアラームを作成するには、2 番目の値よりも小さい数字を最初の値に指定します。(詳細については、アラームの評価 を参照してください)。

  12. [Missing data treatment] (欠落データの処理) で、一部のデータポイントが欠落している際のアラームによる対処方法を選択します。詳細については、「CloudWatch アラームの欠落データの処理の設定」を参照してください。

  13. [Next] を選択します。

  14. [通知] で、アラームが ALARM、OK、または INSUFFICIENT_DATA 状態に遷移するときに通知するための Amazon SNS トピックを指定します。

    1. (オプション) 同じアラーム状態または異なるアラーム状態について複数の通知を送信するには、[Add notification] (通知の追加)を選択します。

      注記

      [アラーム] 状態になったときだけでなく、[データ不足] 状態になったときにもアクションを実行するようにアラームを設定することをお勧めします。これは、データソースに接続する Lambda 関数に関する多くの問題により、アラームが [データ不足] に遷移する可能性があるためです。

    2. (オプション) Amazon SNS の通知を送信しない場合は、[削除] を選択します。

  15. アラームに伴って Auto Scaling、EC2、Lambda、または Systems Manager アクションを実行するには、該当するボタンを選択し、アラーム状態と実行するアクションを選択します。Lambda 関数をアラームアクションとして選択する場合、関数名または ARN を指定し、オプションで関数の特定のバージョンを選択できます。

    アラームは、ALARM 状態になったときにのみ、Systems Manager のアクションを実行できます。Systems Manager のアクションの詳細については、「アラームから OpsItems を作成するように CloudWatch を設定する」および「Incident creation」を参照してください。

    注記

    SSM Incident Manager アクションを実行するアラームを作成するには、特定のアクセス許可が必要です。詳細については、AWS Systems Manager Incident Manager のアイデンティティベースのポリシーの例を参照してください。

  16. [Next] を選択します。

  17. [Name and description] (名前と説明) にアラームの名前と説明を入力し、[Next] (次へ) をクリックします。アラーム名には UTF-8 文字のみを使用する必要があり、ASCII 制御文字は使用できません。説明にはマークダウン形式を含めることができます。マークダウン形式は、CloudWatch コンソールのアラームの [詳細] タブにのみ表示されます。マークダウンは、ランブックや他の内部リソースへのリンクを追加するのに役立ちます。

    ヒント

    アラーム名には UTF-8 文字のみを使用する必要があります。ASCII 制御文字を含めることはできません。

  18. [Preview and create] (プレビューと作成) で、アラームの情報と条件が正しいことを確認し、[Create alarm] (アラームの作成) をクリックします。

接続されているデータソースのアラームに関する詳細

  • CloudWatch はアラームを評価するとき、アラームの期間が 1 分を超えていても、1 分ごとにアラームを評価します。アラームが機能するためには、Lambda 関数が期間の長さの倍数だけでなく、任意の分から始まるタイムスタンプのリストを返すことができなければなりません。これらのタイムスタンプは、1 つの期間の長さの間隔を空ける必要があります。

    したがって、Lambda によってクエリされたデータソースが期間の長さの倍数のタイムスタンプしか返せない場合、関数は取得したデータを「再サンプリング」して、GetMetricData リクエストで期待されるタイムスタンプと一致させる必要があります。

    例えば、5 分間隔のアラームは、毎回 1 分ずつシフトする 5 分のウィンドウを使用して 1 分ごとに評価されます。この場合は以下のようになります。

    • 12:15:00 のアラーム評価では、CloudWatch は 12:00:00、12:05:00、12:10:00 のタイムスタンプを持つデータポイントを予想します。

    • 次に、12:16:00 のアラーム評価では、CloudWatch は 12:01:00、12:06:00、12:11:00 のタイムスタンプを持つデータポイントを予想します。

  • CloudWatch がアラームを評価すると、Lambda 関数によって返されるデータポイントのうち、予想されるタイムスタンプと一致しないものはすべて削除され、残りの予想されるデータポイントを使用してアラームが評価されます。例えば、12:15:00 でアラームが評価されると、12:00:00、12:05:00、12:10:00 のタイムスタンプを持つデータを予想します。12:00:00、12:05:00、12:06:00、12:10:00 のタイムスタンプを持つデータを受信すると、12:06:00 からのデータは削除され、CloudWatch は他のタイムスタンプを使用してアラームを評価します。

    次の 12:16:00 での評価では、12:01:00、12:06:00、12:11:00 のタイムスタンプを持つデータを予想します。タイムスタンプが 12:00:00、12:05:00、12:10:00 のデータしかない場合、これらのデータポイントはすべて 12:16:00 で無視され、アラームは、指定されている欠落データの処理方法に従って状態に遷移します。詳細については、「アラームの評価」を参照してください。

  • いくつかの Lambda 関数の失敗ユースケースでは、設定されているアラームによる欠落データの処理方法に関係なく、アラームが INSUFFICIENT_DATA に遷移するため、これらのアラームを作成して、INSUFFICIENT_DATA 状態に遷移したときにアクションを実行することをお勧めします。

  • Lambda 関数がエラーを返すか、部分的なデータを返す場合:

    • Lambda 関数の呼び出しでアクセス権限の問題が発生した場合、アラームの作成時に欠落データを処理するように指定した方法に従って、アラームは欠落データの遷移を開始します。

    • Lambda 関数が 'StatusCode' = 'PartialData' を返した場合、アラームの評価は失敗し、3 回試行した後、アラームは INSUFFICIENT_DATA に遷移します。これには約 3 分かかります。

    • Lambda 関数から発生するその他のエラーにより、アラームは INSUFFICIENT_DATA に遷移します。

  • Lambda 関数によってリクエストされたメトリクスに遅延があり、最後のデータポイントが常に欠落している場合は、回避策を使用する必要があります。N 個中 M 個のアラームを作成するか、アラームの評価期間を長くすることができます。N 個中 M 個のアラームについては、「アラームの評価」を参照してください。