Amazon CloudWatch アラームの設定値について

お久しぶりです。サカタです。 今回はAWSのお話です。最近業務でClo

お久しぶりです。サカタです。

今回はAWSのお話です。
最近業務でCloudWatchアラームに関して、実機を触ってようやく理解できたものがあったのでアウトプットします。

1. 起きたこと

システムには、ログに「ERROR」という文字列が吐かれるとアラーム状態になる(そこからメール通知する)機能があります。
これは、ログメトリクスフィルターとCloudWatch アラームを組み合わせて作成されています。
具体的な設定値は以下です。

ログメトリクスフィルター

  • フィルターパターン:ERROR
  • メトリクス値:1
  • デフォルト値:0
  • Unit:カウント

CloudWatchアラーム

  • 統計:最小
  • 期間:5分
  • 条件:以上
  • 閾値:1
  • アラームを実行するデータポイント:1/1

この機能のテストとして、ログストリームに対して直接「ERROR」を含むログを送信し、アラーム状態となり、メールが送られてくることを確認するテストを行っていました。

しかし、メールが送られてこないどころかアラーム状態にすらなっていなかったのです。

2. 解決方法

メトリクスフィルター+アラームに詳しい方は読んでて、そりゃアラーム状態にならんでしょ。と思っていることと思います。

そうですね、アラーム側の統計を「最大」や「合計」に修正することで解決できます。

別解として、メトリクスフィルター側のデフォルト値を外す(設定しない)と、これでも解決できます。ただ、統計を最小とするときの思想とずれる気がするので個人的には違うかなと思います。

3. 原因

メトリクスフィルターのデフォルト値が0で、かつアラームの統計が最小になっていることが原因です。

デフォルト値は、パターンが一致しないときに発行されるメトリクスの値です。
つまりこの設定では、「ERROR」が含まれない正常なログは全て0として記録されます。

そして統計は、メトリクスデータを指定した期間で集計したものです。
今回、期間には5分を指定しているため、アラームは5分の期間中の最小値を常に監視することになります。

この2つの設定によって、「ERROR」が含まれるログが何回出ようが、5分間のうちに1回でも「ERROR」が含まれないログが出力されると、デフォルト値0がメトリクスとして記録されます。
そして、その期間の統計データは最小値である0となってしまうため、閾値の1以上を超えず、アラーム状態にならなかったのです。

4. 難しかった理由

理解した今となってはそこまで難しく感じませんが、知識がない状態だとリファレンス読むだけじゃなかなか理解しきれませんね。

用語が難しい

アラームを作成するときに、CloudWatch がアラームの状態を変更するタイミングを評価できるように 3 つの設定を指定します。

・[期間] は、アラームの各データポイントを作成することを目的として、メトリクスや式を評価するために使用する期間です。これは秒単位で表されます。
・[Evaluation Periods (評価期間)] は、アラームの状態を決定するまでに要する最新の期間またはデータポイントの数です。
・[Datapoints to Alarm (アラームを実行するデータポイント)] は、アラームが ALARM 状態に移るためにしきい値を超過する必要がある評価期間内のデータポイントの数です。しきい値を超過したデータポイントは連続している必要はありません。しかしすべてが Evaluation Period に相当する直近のデータポイント数に含まれている必要があります。

期間が 1 分以上の場合、アラームは 1 分ごとに評価され、評価は [期間] と [評価期間] で定義されている時間枠に基づいて行われます。例えば、[期間] が 5 分 (300 秒) で、[評価期間] が 1 の場合、5 分終了時に、アラームは 1 分~5 分のデータに基づいて評価されます。続いて、6 分終了時に、2 分~6 分のデータに基づいてアラームが評価されます。
アラーム期間が 10 秒、20 秒、または 30 秒の場合、アラームは 10 秒ごとに評価されます。

https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html

って当時はなっていました。

特に「評価期間」。どちらさまですか?そんな設定項目ないんですが。。。
他にもデータポイントとか、統計とかもそうですね。
公式ドキュメントももう少し図とかがあるとわかりやすいんですけどね。

ちなみにこちらは非常にわかりやすかったです。

アラームの画面のグラフとメトリクスの画面のグラフは別物

アラームの詳細画面ではでかでかとグラフが表示されるのですが、そのグラフはメトリクスの画面でメトリクスを選択した際に表示されるグラフと同じものだと思っていました。

あながち間違ってはいないのですが、メトリクスの画面に表示されるグラフは「グラフ化したメトリクス」タブより、統計や期間を自由に変更できるようになっています。

そのため、統計と期間がアラームと同じ設定になっていれば同じグラフが表示されますが、私の場合は異なる設定になっていたので全然違うグラフが表示されていました。
同じものが表示されるのだと思っていたので普通にぶっ壊しちゃったかと思いました。

グラフには1つ1つのメトリクスが表示されているわけではない

というかそもそも、メトリクスの画面に表示されているグラフには、すべてのメトリクスが表示されているものだと思っていました。ここが大きな間違いでした。

メトリクス画面でメトリクスを選択したときに出てくるグラフも、統計および期間に基づいて集計したデータポイントのグラフなんですよね。

つまり期間が1分なら1分間にログを100個送ってもそれらを集計した1つのデータポイントになるんですが、私はここで100個ポイントが打たれると勘違していたんですよ。カー!恥ずかしいね。

5. おわりに

CloudWatchは私が担当しているサービスではないのですが、この障害対応のおかげでログメトリクスフィルター、メトリクス、アラームまわりに詳しくなれたので、良かったかなと思います。

小ネタ

ログストリームに対して直接「ERROR」を含むログを送信し、アラーム状態となり、メールが送られてくることを確認するテストを行っていました。

中略

「ERROR」が含まれるログが何回出ようが、5分間のうちに1回でも「ERROR」が含まれないログが出力されると、デフォルト値0がメトリクスとして記録されます。

ここで違和感を覚えた人、いますか?

私のテストではあくまで「ERROR」を含むログしか送信していないので、この説明だと0のメトリクスは記録されず、アラーム状態になるはずです。

しかしアラーム状態にならなかったのは、対象のリソースがALBからヘルスチェックを受けており、ERRORが含まれないアクセスログを吐き続けているからでした。

ヘルスチェックがなかったら恐らくこのテストは成功しており、この障害は検知できなかったかもしれません。LB君ありがとう。

コメントを残す

メールアドレスが公開されることはありません。