AWSでサーバーのモニタリングを基本から学習しなおす

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
![スクリーンショット 2020-11-30 19.01.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/df079949-235e-7e9b-e792-8d38ed080ab3.png)

CloudFormation による展開が成功したら、EC2インスタンスが2台作成されているので、DNSにアクセスし、Wordpress の設定を行う。

なお、今回は監視について復習することを目的にしているため、、Wordpress の設定などについてここでの詳しい説明は割愛する。


#2.メトリクス#

よくある問題として、サーバーが過負荷で応答できない場合などの問題が発生するかと思います。
このような場合、*CPUやメモリ使用率* を確認するのが一般的です。
![スクリーンショット 2020-11-30 19.36.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/c8ed94f7-c1ea-b027-517e-5fefff58845e.png)

デフォルトでは、「UTC」となっているので、「標準タイムゾーン」に切り変えることで正確な時間表示にする。
![スクリーンショット 2020-11-30 19.35.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/22f64b07-ee54-3a9f-5997-0e3c3323180c.png)

一般的な監視の表示期間として「5分」間隔の平均値となる。
ただし、間隔が長ければ長くなる程、纏められてしまうため、より細かな数値を知りたい場合は、期間を「1分」にする。
![スクリーンショット 2020-11-30 19.40.49.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/cd5c22ef-0453-d08e-98c4-7e49d637481a.png)

#3.アラーム#

システムやシステムのコンポーネントの振る舞いに変化が起きた際に、ビジネスへの影響をなくすために必要です。

今回は「静的」で設定したとします。
（「異常検出」は、過去の値を元に異常があったか学び、値が外れた場合はアラーム通知をするらしいです。）
今回は、ディスク使用率（disk_used_percent）が90%を越えた場合に、メール通知するように設定してみてください。
![スクリーンショット 2020-12-01 19.04.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/784c736e-fbb1-cb58-d4d6-9a6534ed998f.png)
![スクリーンショット 2020-12-01 19.05.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/c699cd93-d500-9331-6b95-dd2e208bbfd8.png)

メール通知のみではなく他に、
　Auto Scalingアクション、
　EC2アクション、
　Systems Manager OpsCenterアクション
をとることもできる。
（Systems Manager OpsCenterアクションは、初めて聞いたような気がする。。。）
![スクリーンショット 2020-12-01 19.06.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/4a347851-8db7-192f-4964-eaa985cefb70.png)

#4.ログ#

サーバーが増加した際に、各サーバーにログインしてログを確認する必要があり、それぞれ確認するのが辛い。
そのため、ログを集約することで、運用が簡単になります。

エージェント経由でログメッセージを Cloudwatchエンドポイントに転送します。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html

ログデータの保存期間を1日から永久保存可能です。これは↓の「失効しない」から設定可能です。
（転送されたログの容量に応じて課金されるため、何でもかんでもアップすべきではない。）
![スクリーンショット 2020-12-01 19.16.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/afdf9c76-3c5a-7676-4dee-7ae647164314.png)

#5.分析#

集約したデータの中から、必要な情報を抜き出し、ビジネス、アプリケーションの改善に繋げるためには、ログの分析が必要です。

クエリの書き方などは↓を参考に。
[サポートされるログと検出されるタイプ](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData-discoverable-fields.html)
[クエリ構文](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)

#6.ダッシュボード#

1つのサービス、1つのプロダクトのステータスを効率的に確認できるようにするために必要です。
異なるリージョンでも1つのダッシュボードで利用することが可能です。

手動で作成することもできるし、
![スクリーンショット 2020-12-23 20.44.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/88481aae-031e-f877-164e-c60fa2255fbf.png)

＊＊Automatic Dashboard＊＊ で予めAWSのベストプラティクスにそったものを利用することも可能。
![スクリーンショット 2020-12-23 20.46.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/97c90035-49f9-0d5a-9ee6-ec60d69ad391.png)
![スクリーンショット 2020-12-23 20.47.01.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/1beb2640-5c7f-5807-ea2d-3b2dd6f909cf.png)

#7.イベント#

リソース変更のイベントに基づいて、アクションを実行する。

EC2インスタンスが停止になった場合に、メールを通帳するなど。。。
![スクリーンショット 2020-12-23 20.59.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/280929/369bd92f-4ed6-6cd1-ca36-0ffec8ac9fee.png)