EC2、ELB、RDS を利⽤した王道パターンのWEBシステムにおいて、監視方法を学ぶことを目的としている。
なぜ監視が必要かと原点の考えを学ぶ。
そのため、メトリクスやアラームの仕様についての具体的な説明や操作については、割愛する。
-
代表的な監視項目
- 1.リソース監視
- 2.ログ監視
- 3.APM(アプリケーション性能管理)
- 4.外形監視 (シンセティック監視)
- 5.セキュリティ
- 6.コスト
-
AWSの監視サービス
- CloudWatch ～ Metrics や Logs
- X-Ray ～ Traces
1.事前準備
CloudFormation でリソースを作成し、このリソースを使って監視について見ていきます。というか復習みたいな。
https://pages.awscloud.com/rs/112-TZM-766/images/hands-on-for-beginners-aws-monitoring-hands-on-1-master.zip
CloudFormation による展開が成功したら、EC2インスタンスが2台作成されているので、DNSにアクセスし、Wordpress の設定を行う。
なお、今回は監視について復習することを目的にしているため、、Wordpress の設定などについてここでの詳しい説明は割愛する。
2.メトリクス
よくある問題として、サーバーが過負荷で応答できない場合などの問題が発生するかと思います。
このような場合、CPUやメモリ使用率 を確認するのが一般的です。
デフォルトでは、「UTC」となっているので、「標準タイムゾーン」に切り変えることで正確な時間表示にする。
一般的な監視の表示期間として「5分」間隔の平均値となる。
ただし、間隔が長ければ長くなる程、纏められてしまうため、より細かな数値を知りたい場合は、期間を「1分」にする。
3.アラーム
システムやシステムのコンポーネントの振る舞いに変化が起きた際に、ビジネスへの影響をなくすために必要です。
今回は「静的」で設定したとします。
（「異常検出」は、過去の値を元に異常があったか学び、値が外れた場合はアラーム通知をするらしいです。）
今回は、ディスク使用率（disk_used_percent）が90%を越えた場合に、メール通知するように設定してみてください。
メール通知のみではなく他に、
Auto Scalingアクション、
EC2アクション、
Systems Manager OpsCenterアクション
をとることもできる。
（Systems Manager OpsCenterアクションは、初めて聞いたような気がする。。。）
4.ログ
サーバーが増加した際に、各サーバーにログインしてログを確認する必要があり、それぞれ確認するのが辛い。
そのため、ログを集約することで、運用が簡単になります。
エージェント経由でログメッセージを Cloudwatchエンドポイントに転送します。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html
ログデータの保存期間を1日から永久保存可能です。これは↓の「失効しない」から設定可能です。
（転送されたログの容量に応じて課金されるため、何でもかんでもアップすべきではない。）
5.分析
集約したデータの中から、必要な情報を抜き出し、ビジネス、アプリケーションの改善に繋げるためには、ログの分析が必要です。
クエリの書き方などは↓を参考に。
サポートされるログと検出されるタイプ
クエリ構文
6.ダッシュボード
1つのサービス、1つのプロダクトのステータスを効率的に確認できるようにするために必要です。
異なるリージョンでも1つのダッシュボードで利用することが可能です。
手動で作成することもできるし、
＊＊Automatic Dashboard＊＊ で予めAWSのベストプラティクスにそったものを利用することも可能。
7.イベント
リソース変更のイベントに基づいて、アクションを実行する。
EC2インスタンスが停止になった場合に、メールを通帳するなど。。。
