【AWS】用語を整理しながら学ぶAWS - CloudWatchアラーム 監視編 part1
はじめに
この記事では 用語を整理しながらCloudWatch を学習していく記事です。
主な内容としては実践したときのメモを中心に書きます。（忘れやすいことなど）
誤りなどがあれば書き直していく予定です。
CloudWatch アラームとは
CloudWatch の機能の一つであり、メトリクスをベースに通知を出すサービスです。
アラームには特定のしきい値を利用し、それぞれ静的と異常検出の2つのタイプが存在します。
AWSドキュメント上では以下のように説明されています。
Amazon CloudWatch は、Amazon Web Services (AWS) リソースと、AWS で実行されているアプリケーションをリアルタイムでモニタリングします。CloudWatch を使用してメトリクスを収集し、追跡できます。
要するにクラウド上でログデータを監視し、一定の基準(メトリクス)を満たした際に通知を出す監視サービスです。
アラーム？メトリクス？静的と異常検出の2つのタイプ？さてなんだろう。
用語説明
そもそもアラームとは
監視サービスと聞いて「そもそも監視とはなんぞや」ってところもあるのですが
簡単にいえば、「見張ること」だと思っていただければ問題ないです。
見張ることではあるのですが、見張るだけでなく見張った結果を受け取るようにしなければいけません。見張った結果、決められた基準を満たした時に出されるものがアラームです。
例えば、地面に書いてある白い線の外側から1cmでも出たら笛を鳴らすとします。
この時、地面に書いてある白い線が次に説明するメトリクスで、笛を鳴らす行為がアラームに該当します。そして、そのアラームを発生させる条件は外側から1cmとなります。
メトリクス
先ほどの例では地面に書いてある白い線がメトリクスであると書きましたが
つまりは、アラームを発生させる時に見るべきポイントのことです。
メトリクス=監視項目と考えておけば、OKです。
監視によるアラームはメトリクスを基準に発砲されますが、メトリクスだけではアラームを作成することはできません。
アラームを作成するにはメトリクスとそれに合わせたしきい値と条件が必要です。
しきい値と条件
アラームを作成するにはメトリクスに合わせたしきい値と条件が必要と述べました。
地面に書いてある白い線の外側から1cmでも出たら笛を鳴らす
上記の例でしきい値と条件に該当する箇所は外側から1cmという部分です。
しきい値が1cmで外側というのが条件になります。
なお、しきい値とは
境界値のことであり、監視技術においてはアラームを発生させるかさせないかの基準値のことを言います。
インフラに携わるエンジニアであれば必須の用語ですので覚えておきましょう。
では条件を満たしたらすぐにでもアラームを出すのかといえば、それは違います。
監視には期間(Period)と統計(Statistic)が存在します。
順番に見ていきましょう。
アラームが必要とする項目
期間(Period)は監視項目を評価する期間のことです。
例えば、5分に1回のアラームとするならば、期間(Period)は300秒になります。
この300秒間の監視で取得できるデータをメトリクスデータと呼び、メトリクスデータの集計結果を評価します。
メトリクスデータは指定された統計(Statistic)によって集計されます。
統計には様々な項目がありますが、統計学で使われるものと変わりません。
具体的には以下のとおりです。(一部抜粋)
- 平均値
- 合計値
- 最小値
- 最大値
要するに特定の期間(Period)で取得できるメトリクスデータを指定された統計によって取得し、しきい値を超過したらアラームを出すということになります。
ただ、しきい値を超過したらすぐにでもアラームを出すというオペレーションだと対応する側も大変ですよね。
基本的なアラームの欠点としては変則的なしきい値超えに対応することができません。
例えば、集計期間に5つの評価ポイントを設けてその期間に3回以上しきい値を超えたら
アラームを発砲するということも必要になります。
そこでデータポイントという概念が登場します。
データポイント
アラーム発砲の条件に必要なデータポイントにはEvaluationPeriodsとDatapointsToAlarmの2種類があります。
先ほどの評価期間中、5回に3回のしきい値超えであれば以下のように表現できます。
EvaluationPeriods=5つのデータポイント
DatapointsToAlarm=3つのデータポイント
なお、1つのデータポイントにつき1つの期間(Period)になる為
5つのデータポイントを設定した場合は期間(Period)は5倍になります。
期間(Period) * 5 = 実際の評価期間
少し分かりにくいと思うので具体例を出して見ていきましょう。
アラーム発生の条件を割り出してみる
ここでは実際のパラメータを読んでアラームの発生条件を計算してみます。
問題1
CPU使用率(CPUUtilization)が平均値(Average)30%のしきい値(threshold)を300秒(Period)以内に1回(1つのデータポイント)でも超過した。
また、しきい値より大きい(comparison operator)数値を観測したものとする。
上記の問題をまとめると以下のようになります。
| 項目名 | 値 |
|---|---|
| MetricName | CPUUtilization |
| Statistic | Average |
| comparison operator | > |
| threshold | 30 |
| Period | 300 |
| EvaluationPeriods | 1 |
| DatapointsToAlarm | 指定なし |
5分内の1データポイントのCPUUtilization >30 となります。
問題2
CPU使用率(CPUUtilization)が平均値(Average)30%のしきい値(threshold)を300秒(Period)以内に1回(1つのデータポイント)でも超過した。
5つのデータポイントを観測して3回しきい値を超過したらアラームを出すものとし、しきい値より大きい(comparison operator)数値を観測したものとする。
上記の問題をまとめると以下のようになります。
| 項目名 | 値 |
|---|---|
| MetricName | CPUUtilization |
| Statistic | Average |
| comparison operator | > |
| threshold | 30 |
| Period | 300 |
| EvaluationPeriods | 5 |
| DatapointsToAlarm | 3 |
この問題ではEvaluationPeriodsが5となる為
評価期間はPeriodを掛け算した値になります。つまりは
(300 / 60) * 5 = 25 となる為25分の評価期間になります。
そして、しきい値の評価ポイントは3データポイントになる為
25分内の3データポイントのCPUUtilization >30 となります。
もっと変則的なしきい値超えに対応するには
基本的なアラームと変則的なしきい値超えに対応できるようになりました。
ここまでで紹介したアラームはいわゆる、静的なしきい値によるアラームであり
複雑で変則的なしきい値超えには対応できません。
では、もっと変則的なしきい値超えに対応するにはどうしたら良いでしょうか。
そこで異常検出アラームというアラームが登場します。
異常検出アラームとは
簡単に述べると特定の異常検出モデルをベースに振れ幅を設定してメトリクスデータが振れ幅に触れた時にアラームを発砲するというものです。
最初に述べました静的なしきい値によるアラームが点を基準にするアラームであるのに対し、異常検出アラームは線を基準にアラームを発砲します。
もっと複雑な条件でアラートを出したい場合
異常検出アラームは線を基準にアラームを発砲すると述べました。
では、静的なしきい値によるアラームの条件を満たしつつ、異常検出アラームを満たした時にアラームを出したいという要件にはどのように対応したら良いでしょうか。
そこで複合アラームというアラームが登場します。
複合アラーム
アラームを組み合わせて一つのアラームとする仕組みのことです。
複数のアラームを親として複数の子アラームを持つことができます。
まとめ
CloudWatchアラームの概要に触れ、アラームの種類を見てきました。
今回はアラームをどのように設計していくかという運用設計までを述べることはできませんでしたが、そもそもCloudWatchアラームをここまで知ることはあまりないとは思います。