はじめに
AWSハンズオン for Beginnersシリーズとして提供されている「AWS Hands-on for Beginners 監視編 サーバーのモニタリングの基本を学ぼう」を実施した際のメモです。
運用しているサーバが今どの状態にあるのか監視することはサーバが提供している可用性を担保するため、重要な作業です。また、サーバが異常時や高負荷を検知し、サーバの再起動、スケーリングを行うことも同様です。
AWSにはこれらを行うサービスとしてAmazon CloudWatchというサービスがあります。
本ハンズオンではこのCloudWatchを使用し、WordPressをホストしているEC2インスタンスやDBサービスであるRDS、ロードバランサであるELBを監視します。
そして、各サービスが高負荷の場合や異常時をシミュレーションして検知するなども行います。
アジェンダ
- 監視アーキテクチャの概要
- 基礎知識のおさらいと事前準備
- Amazon CloudWatchの概要
- Amazon CloudWatchのハンズオン ①EC2、ALB、RDSのメトリクス確認
- Amazon CloudWatchのハンズオン ②EC2のディスク使用率90%以上時のアラート発報
- Amazon CloudWatchのハンズオン ③WordPressのアクセスログ、エラーログ確認
- Amazon CloudWatchのハンズオン ④WordPressのアクセスログの分析
- Amazon CloudWatchのハンズオン ⑤WordPressの監視ダッシュボード作成
- Amazon CloudWatchのハンズオン ⑥EC2インスタンス停止時の通知
- 本コースのまとめ、リソース削除
メモ
ゴール
- EC2、ELB、RDSの監視方法を学びます。
監視について
監視の目的
ユーザーエクスペリエンスを保つため、リソースの不足や稼働を確認します。
代表的な監視項目
- リソース
- ログ
- APM（アプリケーション性能管理）
- シンセティック監視（リアルユーザーを想定したモニタリング手法）
- セキュリティ
- コスト
代表的な監視サービス
- Amazon CloudWatch
- Amazon X-Ray
CloudWatchの主な機能
- Metrics
- Logs
- Alarms
- Logs Insights
- Dashboards
CloudWatchメトリクス
メトリクス関連の用語
CloudWatchメトリクスとは、CloudWatchに発行された時系列のデータポイントのセットです。CPU使用率、メモリ使用量などがあります。
メトリクスは名前空間によって区別できます。名前空間はメトリクスのコンテナであり、名前空間が異なると同じ名前のメトリクスも別のものと判断できます。
メトリクスはディメンションによって一意に識別できます。
ディメンションとは、メトリクスを一意に識別する名前と値のペアを指します。
メトリクスの種類
メトリクスには標準メトリクスというAWS側ですでに用意されているものがあり、これらは特に設定不要で収集されます。
用意されていないメトリクスはカスタムメトリクスと呼ばれ、設定すると収集が可能になります。
マネジメントコンソールからのメトリクスの参照について
CloudWatchメトリクスのデフォルトのタイムゾーンはUTCなので注意が必要です。マネジメントコンソールのメトリクスを参照できる画面からお好きなタイムゾーンに変換して閲覧可能です。
画面からは各メトリクスに紐づく値をグラフで可視化できます。時間範囲の指定も可能で、EC2の場合はインスタンス別にメトリクスを見ることができます。
CloudWatch Alarm
アラート機能があると、メトリクスに異常があった場合、自動通知や自動復旧でき、運用が楽になります。
CloudWatch Alarmはメトリクスの正常値、異常値の閾値を設定し、異常になった場合、Amazon SNSでの通知やEC2インスタンスの停止などのアクションを定義するサービスです。
CloudWatch Logs
ログを集約する理由
監視対象のサーバが多数ある場合、1台づつログインしてログなどを確認する方法だと運用が煩雑になります。また、監視対象のサーバがディスク不足やCPU不足の場合、そもそもログインできず、ログの確認ができないなどの問題があります。ログは1ヶ所に集約することでこれら問題に対応できます。
CloudWatch Logsがこれらに対応するサービスです。
CloudWatch Logsのコスト注意点
CloudWatch Logsはログの保存量などではなく、転送量に対して課金されるため、不必要なログは出力しない方がコストパフォーマンスが良いです。
EC2のログをCloudWatch Logsに送信
EC2のログをCloudWatch Logsに転送するには、EC2インスタンスにCloudWatch Agentをインストールする必要があります。（インスタンスタイプによっては既にインストールされているものもあります）
Agentインストール後、EC2インスタンス内のどのログファイルのログをCloudWatch Logsのどのロググループ、ログストリームに転送するかを設定ファイルに指定します。
CloudWatch Logs Insights
ログを分析する理由
ログを分析することで、ビジネス、アプリケーションの改善に繋げることができます。例えば、CPU使用率を時間毎に出力し、サーバのスケールアップやスケールインのタイミングを調整し、コスト削減などの検討材料にできます。
CloudWatch Logs Insightsは、ログを対話的にクエリし、可視化する機能です。これを使用することで、ログの分析が容易になります。
クエリコマンド
Insightsは送信ログ毎に@message, @timestamp, @logStreamの3つのフィールドを生成します。また、VPCフローログ、Route53、Lambdaログにはそれぞれ固有のフィールドが定義されています。これらフィールドをクエリコマンドのフィルタ条件や出力項目として指定します。クエリコマンドはInsights独自で定義されています。
実際に分析する場合、ログをパースした後、フィールドの値をフィルタすることが多いです。以下がパースとフィルタリングのコマンド例です。
parse '* - * [] " * *" * * * *' as host, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes, referrer, userAgent
| filter statusCode like /(4¥d¥d)/
CloudWatch Dashboard
ダッシュボードが必要な理由
ダッシュボードを使用することで、サービス、プロダクトの状況を効率的に参照できます。
CloudWatch Dashboardは、CloudWatchの一機能であるダッシュボード機能です。リージョンを跨いで1つのダッシュボードでモニタリングが可能です。
Amazon EventBridge
Amazon EventBridgeは、AWSリソースの変更を表すシステムイベントのストリームを提供します。システムイベントをトリガーとして、LambdaやSNSなどをターゲットにし、イベントを処理する設定ができるサービスです。
本ハンズオンから大分UIが変わっているため、以下を参考にルールを設定しました。
ハンズオンの感想
AWSを使用した開発の場合、必ず触るであろうサービスCloudWatchの初歩的な使い方を学ぶことができました。
CloudWatchは多数の機能があり、ハンズオン前では頭の中で整理できていない状態でした。ハンズオンを通して、Metrics、Logs、Alarms、Logs Insights、Dashboardsがそれぞれどの機能と対応しているのか理解できました。
ただ、ハンズオンで使用した機能はCloudWatchの機能の一部であるため、このハンズオンをとっかかりに他の機能にも触れたいです。