目次
記事説明
この記事では、「Management & Governance」分野の重要なサービスである、
Amazon CloudWatchについて説明します。
↓Management & Governanceの重要なサービス一覧
・Amazon CloudWatch
・AWS CloudFormation
・AWS CloudTrail
・AWS Config
・AWS Systems Manager
↓参考：【AWS Black Belt Online Seminar】Amazon CloudWatch
https://d1.awsstatic.com/webinars/jp/pdf/services/20190326_AWS-BlackBelt_CloudWatch.pdf
Amazon CloudWatchの位置づけ
Amazon Management Toolsとして、5つの機能が提供されています。
１．リソースプロビジョニング
⇒テンプレート定義によるインフラプロビジョニングの自動化
主なサービス：AWS CloudFormationなど
２．構成管理
⇒パッケージの導入、ソフトウェアとリソースのコンフィグレーション、パッチ適用
主なサービス：AWS Systems Managerなど
３．モニタリング
⇒AWSリソースやアプリケーションに対する、モニタリング、アラーム、
メトリクスダッシュボード、ログ、イベント管理
主なサービス：Amazon CloudWatch
４．ガバナンスとコンプライアンス
⇒リソースインベントリ、構成変更管理、ユーザ操作とAPI呼び出しの記録、
セルフマネージドなITカタログ
主なサービス：AWS CloudTrail、AWS Config
５．リソース最適化
⇒コスト低減、パフォーマンス向上、セキュリティの改善に対する推奨事項の自動提供
主なサービス：AWS Trusted Advisor
このうち、Amazon CloudWatchは
Amazon Management Toolsの中のモニタリング機能として用いられます。
Amazon CloudWatchの概要
概要としては、
「AWSサービスや、システムのモニタリングに関する様々な機能を提供する」
サービスで、AWSサービスだけでなく、社内のオンプレサーバや他のクラウドサーバでの監視も可能です。
CloudWatchの重要な要素として、５つ挙げられます。
１．CloudWatch Metrics
⇒CloudWatchに発行されたメトリクス（測定データ）を収集し、統計を取得します。
２．CloudWatch Alarms
⇒CloudWatch Metricsをモニタリングして、アラームを発行可能で、
条件を指定して自動アクション（通知や復旧など）を実行可能です。
３．CloudWatch Logs
⇒AWSサービスもしくはシステムのログ監視、保存、アクセスを提供します。
４．CloudWatch Dashboards
⇒CloudWatch コンソールでカスタマイズ可能なダッシュボードを作成できます。
５．CloudWatch Events
⇒リソース変更のイベントやスケジュールをトリガーとして、アクションを実行できます。
↓引用元
https://d1.awsstatic.com/webinars/jp/pdf/services/20190326_AWS-BlackBelt_CloudWatch.pdf
それでは順に説明していきます。
CloudWatch Metricsについて
CPU使用率や5XX errorなど、様々な測定データのことを、AWSではメトリクスと呼びます。
時系列のデータポイントとして、タイムスタンプと測定単位を保持します。
例）08:00にCPU使用率：85% 等
様々なメトリクスの収集、統計結果を管理するのがCloudWatch Metricsとなります。
メトリクスデータの生成
• 基本は1分、カスタムメトリクスの高解像度を利用して最短で1秒間隔で生成されます。
• EC2では基本モニタリングで5分、詳細モニタリングで1分ごとにメトリクスが生成されます。
メトリクスデータの利用可能期間
• 粒度によって利用可能期間が決まります。
• 1分未満 ⇒ 3時間、1分 ⇒ 15日、5分 ⇒ 63日
• 1時間のデータポイントだと15ヶ月(1年前のイベントとの比較に使えます)
| 高解像度 | 標準の解像度 | |||
| 取得粒度 | １分未満 | １分～ | ５分～ | １時間～ |
| 利用可能期間 | ３時間 | １５分 | ６３日 | １５か月 |
メトリクス値としては下記のようなデータが収集されます。
・Minimum ： 指定された期間に認められた最小値
・Maximum ：指定された期間に認められた最大値
・Sum ： メトリクスで加算されたすべての合計値
・Average ： 指定した期間の平均値（Sum/SampleCount）
・SampleCount ： データポイントのカウント数
・pNN,NN ： 指定されたパーセンタイルの値（パーセント値）
↓その他の機能
Metric Mathについて、
標準メトリクスでは欲しいデータを収集できない場合、
CloudWatchメトリクスに数式を使用して、新しいメトリクスを作成できます。
スナップショットグラフについて、
CloudWatchコンソールでメトリクスを表示した際のグラフをPNG画像として取得できます。
異常検知の際にグラフを添付したい際などに有用です（CloudWatch Alarmsと組み合わせ）
EC2で標準メトリクスとされるもの
• CPUUtilization（CPU使用率）
• CPUCreditBalance（獲得CPUクレジット数）
• CPUCreditUsage（CPUクレジットの使用）
• CPUSurplusCreditBalance（獲得CPUクレジットが消費された後の、余剰CPUクレジット数）
• CPUSurplusCreditsCharged（課金が発生する余剰CPUクレジット数）
• DiskReadBytes（ディスク読み取りバイト数）
• DiskReadOps（読み取り操作回数）
• DiskWriteBytes（ディスク書き込みバイト数）
• DiskWriteOps（書き込み操作回数）
• NetworkOut（送信ネットワークトラフィックのバイト数）
• NetworkPacketsOut（送信パケット数）
• NetworkIn（受信ネットワークトラフィックのバイト数）
• NetworkPacketsIn（受信パケット数）
• StatusCheckFailed_Instance（インスタンスステータスチェック 0：成功、1：失敗）
• StatusCheckFailed_System（システムステータスチェック 0：成功、1：失敗）
• StatusCheckFailed（インスタンスとシステム両方のステータスチェック 0：成功、1：失敗）
その他のメトリクスについては、カスタムメトリクスとなり、
AWS CLIの”put-metric-data”もしくは”PutMetricData” APIでデータを登録し、
監視することができます。（解像度が 1秒のデータを含む高解像度なメトリクスを発行可能）
CloudWatch で利用できるエージェント/プロトコルについて
統合CloudWatch エージェント（推奨）
• メトリクスとログの両方を単一のエージェントで収集
• クラウドでもオンプレミスでも利用可能
• Linux, Windowsの両方で稼働。手動もしくはウィザードから設定が可能。
他にも、より詳しいメトリクスを収集する場合は、下記の方法があります。
StatsD のサポート
• StatsD プロトコルを使用して、カスタムメトリクスを取得(Linux,Windows)
collectd のサポート
• collectd プロトコルを使用してカスタムメトリクスを取得(Linux)
• collectd ソフトウェアを使用してCloudWatch エージェントにメトリクスを送信
procstatプラグイン
• 個別のプロセスからメトリクスを収集
• CloudWatchエージェントで設定
CloudWatch Alarmsについて
CloudWatch Alarmsは、CloudWatch Metricsをモニタリングして、アラームを発行可能で、
条件を指定して自動アクション（通知や復旧など）を実行する機能です。
例）CPU使用率が85%以上になった際、指定されたアドレスにアラートメールを送信する
アラームの状態としては3種類あります。
１．OK
⇒定義された閾値を下回っている状態です。問題ありません。
２．ALARM
⇒定義された閾値を上回っている状態です。発報されるべき状態です。
３．INSUFFICIENT_DATA
データ不足の為、状態を判定できない状態です。
必ずしも障害を表すステータスではなく、発報されるべきか判断できません。
また、データが欠落しているときの処理として、下記の設定が可能です。
| オプション | 設定内容 |
| missing | 不明ステータスとなる。デフォルト設定。 |
| notBreaching | 欠落データポイントは閾値内として判定される。 |
| breaching | 欠落データポイントは閾値超過として判定される。 |
| ignore | 現在のアラーム状態が維持される。 |
例）breachingのユースケース
EC2上の継続的にCPU使用率を監視しているようなシステムについて、
データポイントの欠落は異常として検知する。
例）notBreachingのユースケース
DynamoDBのスロットリングを監視しているシステムについて、
データポイントは正常時に生成されないので、閾値内とする。
その他にも、アラームを発生させるデータポイント数を設定可能です。
例）１分間隔のデータポイントが３回連続で異常だった場合、アラームを生成
CloudWatch Alarmsのアクション機能について
異常（アラーム）が検知された際の挙動を設定することができます。
異常を検知するタイミングが深夜だった場合、人の手で復旧作業せずに
自動で復旧してくれると嬉しいですよね。
例）EC2インスタンスの自動復旧
CloudWatch：StatusCheckFailed_Systemのアラームをキャッチ
↓
CloudWatch Alarms（アクション）：SNSトピックを作成、EC2インスタンスの再起動
↓
SNS：Eメールで指定アドレスへ通知
CloudWatch Logsについて
AWSサービスおよびシステムのログ監視をする機能です。
エージェント経由でログをCloudWatchエンドポイントへ送信します。
※S3へのエクスポートも可能
CloudWatch Logsのディレクトリ階層については、下記のようになります。
ロググループ ＞ ログストリーム ＞ ログイベント
例）社内に3つのwebサーバがあった場合
ロググループ：webサーバ
ログストリーム：Aサーバ、Bサーバ、Cサーバ
ログイベント：それぞれのサーバでの、イベント発生時のタイムスタンプ＋メッセージ
※この場合の数的関係性は、ロググループ：ログストリーム：ログイベント＝１：３：多
収集したログについて
・ログの内容はタイムスタンプとログメッセージ（UTF-8）で構成される
・ログの保存期間は、永久保存が可能
・Amazon S3へのエクスポートが可能
・特定文字列でフィルタリング検索が可能（正規表現利用不可）
・特定文字列のエントリ頻度でアラームを作成、SNS連携が可能
・収集したログをフィルタパターンに応じて、下記のサービスに転送可能（AWS CLIからのみ）
⇒Kinesis Data Streams
⇒Kinesis Data Firehose
⇒Lambda
その他、CloudWatch Logs Insightsという、CloudWatch Logsのログデータを
専用のクエリ言語で検索して分析できる機能があり、グラフで可視化することも可能です。
CloudWatch Dashboardsについて
CloudWatch コンソールでカスタマイズ可能なダッシュボードを作成できます。
自分の監視したいメトリクスを指定して、一度に閲覧することができます。
これは、CloudWatch Alarmsと統合することで、
Alarm状態になるとウィジェットが赤に変わるため、
一目見て異常が起こっているかを監視することができます。
CloudWatch Eventsについて
リソース変更のイベントやスケジュールをトリガーとして、アクションを実行する機能です。
トリガーとなる要素は大きく分けて、２種類存在します。
１．event-base
リソースの変更を行うシステムイベントを処理させることができます。
例）EC2のRunningイベントをキャッチして、指定タグが付いていない場合は、終了する。
２．time-base
ターゲットに対して、スケジューリングを行ってイベントを処理させることが可能。
例）22:00になったら、EC2インスタンスの自動停止を行う。
まとめ
AWSのサービスの中で非常に重要な位置づけである、CloudWatchに関する記事でした。
CloudWatch Alarmsのアクション機能など、うまく活用することができれば、
運用コストを下げることができそうですね。
また、既に会社で別の監視ツールを活用しているという方もいらっしゃると思います。
現に前職では、異常があればすぐに担当者へ電話をかけてもらうような24時間365日対応の監視サービスを利用しておりました。
CloudWatchではEメールでの通知となるので、
電話ですぐに連絡してもらいたい場合などは、別のサービスを用いる方が良いかもしれません。
なので、下記のような使い分けをすれば良いと思います。
障害検知後すぐに電話での連絡を要する ⇒ 別の監視サービスを利用
障害検知から自動的にAWSのサービスのイベントを実行 ⇒ CloudWatch利用
それでは、お読みいただきありがとうございました。
