##概要
サービス形態 ー SaaS
・AWSの監視マネージドサービス
・AWSリソースの状態を監視する
・条件に合致した場合、アラームで通知を行う
→ (例)EC2のCPU使用率が90％など高負荷まで上がったら通知を出すなど
・条件に合致した場合、アクションを設定できる
##全体像
収集、監視、アクション、分析といった機能がある
###収集
AWSのリソースの状態(EC2やRDSなど各種サービスのCPU使用率)をはじめとした様々な情報を収集する。
ログファイルなども収集できる
この収集する情報のことを メトリクス と言う
###監視
CloudWatchのエージェントをインストールすれば、オンプレのサーバーも同じ仕組みで監視できる
CPU使用料が90%(しきい値)を超えるとサービスが安定稼働できない
→ 監視条件を設定するのがAlarmの役目
###アクション
Alarmが起動したら様々なアクションを設定できる
条件の設定ができて、それぞれの場面、重要度に応じた設定も作成できる
・メール通知、AWS Lambdaを自動的に発動
・EC2のAuto Scalingを発動
・EC2アクションの停止、削除、再起動も設定で発動できる
###分析
収集した情報をグラフなどで可視化したものをダッシュボードで表示
##使用すべき理由
・自動でメトリクスを収集する
AWSリソースを作成した時点でデフォルトのメトリクスが収集される
EC2ならCPU使用率やディスクの読み書きのパフォーマンス、ネットワークの流入出の量もデフォルトで収集される
・従量課金性
メトリクスを補完しすぎると補完使用料金が別途かかる(課金対象となる可能性あり)
独自で監視システムを構築するというスタートダッシュ時の料金がオンプレ(★)で構築する監視システムの場合と比べてメリットがある
・高解像度の監視可能
基本は5分感覚でメトリクスを取得するのは無料だが、
詳細モニタリングといった1分間や、1秒間といった高解像度の監視も可能(追加料金)
・オンプレも監視可能
サーバーにCloudWatchのエージェントを入れることにより、一元管理(クラウドもオンプレも)できる
既にオンプレで監視システムを動かしている場合移行は難しいケースも多い可能性もあるが、検討してみる価値あり
##メトリクス
CloudWatchで収集した情報のこと
###標準メトリクス
あらかじめAWSが用意したメトリクス
(例)CPU使用率、NWパフォーマンス,Disk I/Oなど
###カスタムメトリクス
ユーザーが独自に設定したメトリクス
自分でCloudWatchに送る設定を行う必要がある
(例)メモリ使用率、ディスク使用率など
###(補足)CloudWatchエージェント
・CloudWatchエージェントをEC2にインストールする
・EC2にIAMロールをアタッチする
・適切なネットワークルートを設定する
##アラーム評価
###評価軸
設定には3つの評価軸がある
1,Period・・・評価感覚
2,Evaluation Period・・・直近、何個のPeriodを評価対象とするか(評価期間)
3,Datapoints to Alarm・・・評価対象のうち、何個のPeriodがしきい値を超過したか
(例)
しきい値 - CPU使用率が30%以上
Period - 1分間隔
Evaluation Period - 3個
Datapoints to Alarm - 3個
1分間隔(Period)でCPU使用率を計測し、評価期間中(Evaluation Period)に何回越えたか(Datapoints to Alarm)という設定となる
###アラームのステータス
OK・・・しきい値内の値
ARARM・・・しきい値外の値
INSUFFICIENT・・・収集し始めた場合などの理由により、アラームの状態を判断するのには不十分な値
###欠落データの取扱
欠落データ・・・CloudWatchになぜか１分感覚で設定されているのに、データが送信されてこない状態のこと
この時CloudWatchがどのように振る舞うのか設定できる
Missing・・・見つかりません→ 直近のアラームの状態が保持される
Good・・・適正→ 欠落データはしきい値内である
Ignore・・・無視→ 過去のデータポイントに遡る
Bad・・・不正→ 欠落データはしきい値外である
サーバーがダウンしてメトリクスが全て欠落した場合
Missing・・・見つかりません→ INSUFFCIENT(OKでもNGでもなく判断できない状況)
Good・・・適正→ OK状態
Ignore・・・無視→ 現在のステータスを保持
Bad・・・不正→ アラーム状態
(例1)
CPU使用率ならBadを設定するのが良い
→ なんらかの不具合によってメトリクス自体を送信できていない可能性があるのでそこを検知するため
(例2)
エラーが発生した場合のみにメトリクスが作成される場合
→ 欠落データをGood(適正)するのが良い
#参考
この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com