CloudWatch Metricsを利用した監視の基本
はじめに
こんにちは！NE株式会社の tatsuo48 です。
みなさん、作ったアプリケーションの監視していますか？
今回はCloudWatch Metricsを題材にして、各種統計値の意味や監視設定の勘所についてまとめます。
対象とするメトリクス
今回はALBのRequestCountとTargetResponseTimeを例として考えてみます。
こちらのデータは
Elastic Load Balancing は、ロードバランサー経由でリクエストが伝達される場合にのみ、メトリクスを CloudWatch にレポートします。ロードバランサーを経由するリクエストがある場合、Elastic Load Balancing は 60 秒間隔でメトリクスを測定し、送信します
とあるとおり、60秒に1回、直近の60秒間に計測した値を記録します。
以降では、具体的に記録される値やその見方についてみていきましょう。
RequestCount
どんなリクエストだとしてもリクエスト数としては1になるので、値は常に1です。
例えばとある日の9:45~10:15までの様子を統計:最大にしたらこんな感じになります。
値は常に1なのでその最大も当然1となり、あまり面白いグラフではないですね。。多くの人がRequestCountをみる時はリクエスト数が見たいからだと思います。リクエスト数を見るためには 統計:合計にします。
こうすることでリクエストごとに記録される値(1)を全てのリクエスト数分足し合わせた数≒リクエスト数をみることができました。
TargetResponseTime
レスポンスタイムはリクエストによって当然ばらつきがあります。
よって同じく統計:最大のグラフにすると以下のようになります。
- 最大
RequestCountとは逆に、こちらのメトリクスの場合は統計:合計で見てしまうと各リクエストのTargetResponseTimeを足し合わせたものとなってしまい、あまり使い道がないものとなってしまいます。
このように、利用するメトリクスによって見るべき統計値は変わってきます。
AWSのドキュメントには
統計: 最も有用な統計は Sum です。
のようにメトリクスごとにどれが有用か？を載せてくれているので参考にすると良いでしょう。
統計値の2大要素
統計値を考える上で重要な要素となるのが
- 集計期間
- 集計方法
の2要素です。
集計期間
はじめに考えるべきは集計の対象とする期間です。
集計期間が異なることで得られる統計値もかわります。
例えば集計期間を5分とすると、直近5分間のデータを使って統計値をもとめます。
RequestCountを元にしたこちらのグラフだと、５分間の統計:合計を表示しています。よって5分ごとの値の合計=リクエスト数が計算されていることになります。
集計方法
次に考えるべきは集計方法です。
代表的なものとして
- 平均値
- 中央値
- パーセンタイル値
があります。
平均値
集計期間中のデータの合計をデータポイントの数で割ったものです。
TargetResponseTimeを元にしたこちらのグラフだと、５分間の統計:平均を表示しています。よって直近5分間のデータに対して値の平均が計算されていることになります。
中央値
集計期間中のデータを小さい方から順に並べた時に、ちょうど真ん中にあたる値です。
TargetResponseTimeを元にしたこちらのグラフだと、５分間の統計:IQMを表示しています。よって直近5分間のデータに対して値の中央値が計算されていることになります。
極端に分布が偏っているデータの場合は中央値と平均値に大きな差がうまれるので注意が必要です。
たとえば、TargetResponseTimeでいうと、平均値は上がらなくても中央値が上がる場合、特定のユーザや機能へのリクエストだけ極端に遅くなっている可能性があります。
※平均値と中央値の話題としては最近こんな面白い話もありました。
パーセンタイル値
集計期間中のデータを小さい方から順に並べた時に、ちょうどn番目にあたる値です。
例えば100個のデータがあり、n=99とした場合は下から99番目の値となります。
200個であれば198番目です。
TargetResponseTimeを元にしたこちらのグラフだと、５分間の統計:p99を表示しています。よって直近5分間のデータに対して値の99パーセンタイル値が計算されていることになります。
監視の勘所
得られた統計値を元に監視を行う上で考えるべきことについてまとめます。
監視を行うためにはアラートを発生させる条件を考える必要があります。
- 閾値
- 評価サイクル
- 閾値超えの回数
が主な考えるべき要素となります。
閾値
こちらは単純にどのような値を超えたら（下回ったら）アラートを発生させるか？です。
過去データ及び障害の記録などが残っていれば、そこから考えて妥当な値を算出するのが良いでしょう。
過去のデータが全くない場合はいったん仮で決めてみて、様子をみながら値を調整すると良いです。
評価サイクル
評価サイクルとは集計期間、集計方法で指定した計算をどのようなサイクルで行い、閾値との比較をするか？です。
たとえば同じように集計期間5分,集計方法:合計値だとしても
- 1分ごとに計算を行う
- 5分ごとに計算を行う
だと５分間に得られるデータポイント数が前者は5つ、後者は1つと異なってきます。
監視においてこれを言い換えると
- 1分ごとに計算を行えば5分間で5回、閾値との比較評価されるタイミングがある
- 5分ごとに計算を行えば5分間で1回、閾値との比較評価されるタイミングがある
ということになります。
基本的には異常には早く気づきたいと思うので、評価サイクルに関しては出来るだけ短い方が良いでしょう。
※CloudWatch Alermの場合は評価サイクルは1分に固定されているようです。
閾値超えの回数
TargetResponseTimeのp99などのようにユーザのリクエストによって大きく値が変動するものに関して、単純に閾値のみをアラート条件としてしまうと、ユーザ全体に大きな影響がないのにアラートが頻発しアラート疲れにつながります。
そのような場合は、直近n回の評価サイクルのうち閾値を超えた回数が何回でアラートを発生させるか？という回数を決めることも有用です。
例えば、TargetResponseTimeのp99であれば直近5回の評価サイクルで閾値を全て超えたらのような条件にしても良いでしょう。
ただし、評価サイクルが長い（例えば5分に1回）の時に直近5回の評価サイクルで全て超えたらにしてしまうと、最初に閾値を超えたタイミングから5*5=25分程度はアラート発生までかかってしまうのでこの辺りのバランスも考えることが大事です。
まとめ
監視における統計値、および統計値を使った監視方法までまとめました〜！
みなさんの素敵な監視ライフの一助になればと思います。
お読みいただきありがとうございました！！
Discussion