はじめに
- 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環境における監視の業務をイメージすることができた