AWS環境で監視構成

CloudWatch

今日の内容

CloudWatch 概要
実際にCloudWatch を使ってみる（基本メトリクスの取得）
CloudWatch Logの設定
CloudWatch Alarm/Event の設定

CloudWatchの概要

AWSサービス（ex. EC2 , RDS , S3 , EBS , ELB , etc…）の監視サービス
メトリクス：CloudWatchで取得するインスタンスの各種パラメータのこと
- 基本メトリクス
  何も設定しなくても、インスタンスを立てるだけ で勝手に取得しているメトリクス
- 拡張メトリクス
  ユーザ側で設定したり、CloudWatch Agent(後述) を入れることにより取得可能な詳細なメトリクス

最大の特徴として、 EC2インスタンスだけではなく、マネージドなAWSサービス（RDS , Redshiftなど）のメトリクスも取得可能
各種メトリクスは時系列グラフで表示できる。
料金：基本的に無料で利用可能。
無料枠を超える使い方をすると有料になるが、テスト環境の構築くらいでは気にするレベルの課金にはならない。

*AWS 無料利用枠には、Amazon CloudWatchでのメトリックス10個、アラーム 10個、APIリクエスト1,000,000件が含まれています。*

ロギング / ログ監視
CloudWatch Logs で各種AWSサービスのロギングを行ったり、ログ監視を行ったり
イベント発火 / アラート発報
CloudWatch Event で AutoScalingイベントの発火やSQS連動
CloudWatch Alart でアラートのメール通知、SNS通知など

実際にCloudWatch を使ってみる（基本メトリクスの取得）

前述の通り、CloudWatchの基本メトリクスはインスタンスを立てただけで取得を開始している。
先週作った　EC2 (+ EBS) + RDS の環境を見てみる
左上のサービス選択画面から　管理とガバナンス > CloudWatch > メトリクス > EC2 / EBS / RDS etc…
実際に稼働している様子をみてみる
「すべてのメトリクス」タブで閲覧対象メトリクスを選択
「グラフ化したメトリクス」で監視対象のチェック間隔など

EC2のメトリクス

StatusCheckFailedだけ解説
StatusCheckFailed：要するにヘルスチェック、1と0のみ。1が出るとサーバが死んでる状態
1. StatusCheckFailed_Instance > OS(仮想サーバ)側でヘルスチェックに失敗
2. StatusCheckFailed_System > HW(仮想サーバホスト)側でヘルスチェックに失敗
  この場合に、AWSに問い合わせを投げると「AWS側の障害でしたテヘペロ」って、ほぼ100%帰ってきます。対処方法はStop/Startしかないので、この障害に当たったらインスタンスを一回止めましょう。
EC2のインスタンスを検索する場合は、インスタンス名ではなくインスタンスIDで検索

RDSのメトリクス

1. WriteLatency / ReadLatency：ディスク書き込み/読み込み時間、ここが急上昇している場合はAWSのHW起因なことがある
2. ReplicaLag：リードレプリカ側がソース（マスタ）からどんだけ遅延しているか。ここをトリガーに設定するとDB詰まってたりする場合に気付ける。
3. SwapUsage：OS側でスワップしている量。ここをトリガーにしておいて、あんまりにもスワップするようならスペックが足りてない可能性大。スペックアップを検討しよう。

その他：ざっくりとしたTips

CloudFrontのステータスをCloudWatchで確認するときはリージョンを「米国東部（バージニア北部）」に設定しよう。CloudFront自体はグローバルサービスなので、リージョンは関係ないが、何故かCloudWatchでCloudFrontのステータスをみる場合は米国東部を選択しないと表示されない。
インスタンスの詳細画面からみれるステータスも実はCloudWatch
AWSを利用する以上、なんかあったらCloudWatchに出てくるので、不審な点があったらCloudWatchを確認しましょう。
逆に言うと、マネージドサービスはCloudWatchに出てる情報しか取ることができない。
※EC2インスタンスには各種監視ソフトウェアのエージェントなどがインストールできるが、マネージドサービスはできないため。EC2のメモリなど、拡張メトリクスをCloudWatchで取りたい場合はCloudwatch AgentをEC2にインストールすると取ることができます。
https://dev.classmethod.jp/cloud/aws/new-cloudwatch-agent-collect-metrics-and-logs/

CloudWatch Logの設定

実際に運用する上で、重要なスローログを設定してみよう
defaultでは、RDSはスローログを出力しない設定になっている。
まずはRDS側のスローログ設定
defaultのパラメータグループ(my.cnfの設定と思ってもらって大丈夫です)に関しては変更できないので、まずは変更用のパラメータグループを作成
- RDS > パラメータグループ > パラメータグループの作成 > 適当な名前で作成
  作成したパラメータグループを編集 > slow_query_logの設定を1に変更
- RDS > 一覧画面から対象のデータベースを選択 > 変更 > DB パラメータグループでパラメータグループを選択 > 次へ > すぐに適用 (DB再起動)
ログタイプ選択 > スローログにチェック
これで、DB側の設定変更完了。CloudWatch側でみてみる
Cloudwatch > ログ > /aws/rds/instance/<db-instance-id>/<log-type>
https://qiita.com/kooohei/items/729b7ae1c4f167bcbf21

CloudWatch Alarm/Event の設定

CloudWatchでメトリクスを指定してアラームを鳴らす設定を入れる
https://dev.classmethod.jp/cloud/aws/cm-advent-calendar-2015-aws-re-entering-cloudwatch/
CloudWatch > メトリクス > 対象のサーバの監視したいメトリクスを選択 > アラームボタンを選択(🔔) > %を指定 > アラームの種類指定 >SNSトピック（アラーム送信先）の指定 > アラーム時の文言の指定
実際に鳴らしてみる ( yes > /dev/null &)
※yesをdev/nullにバックグラウンドで垂れ流しする。t2インスタンスは一つ程度流してやれば十分かと。基本的にAWS環境で負荷試験を行う際は申請が必要らしく、長時間は厳禁です。
https://techblog.ap-com.co.jp/entry/linux-cpu
EC2/ELBからAutoScalingグループを設定して、アラームをトリガーにオートスケールさせてたり、EC2のイベント（インスタンス停止/再起動/削除）なども実行可能
設定したSQS/Lamda等との連動も可能（らしいので誰かやってください）
https://dev.classmethod.jp/cloud/aws/cloudwatch-events-support-sqs/

そのほか(今後試してみたいことなど)

まとめ

AWSサービスの監視は基本的にCloudWatchから取得する
CloudWatchの基本メトリクスはインスタンスを立てただけで利用可能
CloudWatch にはLogとAlarm、Eventの機能がある
RDSのスロークエリログの出力は設定が必要
Alarmは閾値を設定してアラームをSNSに設定する機能
Eventは様々なAWSサービスと連動可能