はじめに

AWS Hands-on for Begginersのひとつ、監視編サーバーのモニタリングの基本を学ぼうを先日実施したので、振り返りも含めたアウトプット資料として記事に残したいと思います。

CloudWatch Metrics

CloudWatchで発行されたメトリクスを収集＋統計を取得

メトリクス監視で測定すべき項目

リソース監視（CPUやメモリの使用率）
アプリケーションの性能管理（アプリケーションの処理時間）

用語

メトリクス
名前空間
ディメンション
メトリクスを一意に識別する名前や値のペアのこと

メトリクスの種類

標準メトリクス
カスタムメトリクス

画面例

CloudWatchより、メトリクス > すべてのメトリクスと選択する

名前空間：EC2 > インスタンス別メトリクス と選択する

検索ボックスよりCPU Utilizationのメトリクスに絞る
画面上部の時間軸から、グラフの幅を調整する
Customから、タイムゾーンの表示設定を変更できる
ALBのタイプ別、TG別メトリクスの表示例
RDSのメトリクス表示例

RDSはデフォルトで取得している値は1分間隔
必要に応じて、期間を変更することでグラフの表示間隔を更新する
細かい粒度で確認できる

数値で表示した例

CloudWatch Agentの表示例

WEBサーバ#1のメトリクスdisk_used_percentを確認したいときの例

CloudWatch Alarms

条件を指定することで、自動アクションを実行◎
アラートメールの通知など

状態は以下の3種類

OK
正常値
ALARM
異常値（しきい値を上回る）
INSUFFICIENT_DATA
判定不能（データ不足）

CloudWatch Logs

AWSサービスや顧客システムのログを監視・保存・アクセスを提供する

ディレクトリ階層がある
ロググループ・ログストリーム・ログイベント

ログを集約することで受けるメリット

サーバ数が増加した際に確認が大変
障害・容量不足によるログイン×

オンプレミス環境で行うようなログ検索も◎

CloudWatch Logs Insights

ログ分析することで受けるメリット

集約データの中から必要となる情報を抽出し、改善へとつなげる

送信されるログ毎に3つのフィールド

フィールド	説明
@message	未解析のログイベント
@timestamp	ログイベントが追加された時間
@logStream	追加先のログストリーム名

VPC、Route53、Lambdaは自動フィールド検出されるので簡易的に分析◎

クエリ構文

コマンド	説明
fields	指定フィールドをログイベントから抽出する
filter	クエリ結果を条件によってフィルタリング
stats	ログフィールド値により集約統計を計算する
sort	取得したログイベントをソートする
limit	クエリから帰ってくるログイベント数を制限する
parse	ログフィールドからデータ抽出＋エフェメラルフィールドを作る

アクセスログの分析

ログの中身

クエリを編集してログ分析する

クエリのヘルプから対象のクエリ構文を選択し、「適用」を選択することでクエリ構文に追加できる

CloudWatch Dashboards

コンソール画面でカスタマイズできる
異なるリージョンでも1つのダッシュボードに集約◎

Automatic Dashboard

推奨するベストプラクティスに基づいたダッシュボード
自動的に作成してくれる

CloudWatch Events

リソース変更のイベントに対するアクションを実行
EC2が【停止】→自動的に【イベント】を生成→【ルール】の条件に一致
→【アクション】実行（SNS.Lambdaなど）

ユースケース

EC2のrunningイベントをトリガーにし、指定されたタグがない場合にterminate
スケジュール式をトリガーにした、EBSスナップショット取得

まとめ

実際に手を動かすことで、資格勉強や知識だけではイメージしづらいCloudWatchの機能を理解することができた
以前運用保守の部署で監視の業務に携わった経験があるので、当時を思い出しながらAWS環境における監視の業務をイメージすることができた