【AWS】cloudwatchの仕組み、監視設計など

CloudWatchとは？

AWSサービスの監視やモニタリングができるサービスです。閾値を設定しておいてそれをそれを超えたらAmazon SNSを使って通知をさせることができます。

Amazon SNSとは？

AWSの通知サービスです。Topicを作成することでPublisherがメッセージを送信してSubscriberが通知を受信するための通信チャンネルとして機能します。

サブスクリプション

Topicを作成するときにできて通知先のemailアドレスを保持しています。

Cloud Watchの設定

アラームを作成する。

保持期間

永久保管は可能です。

注意点

メモリの監視はデフォルトでは対応していないです。メモリを監視したい場合はカスタマイズして使う必要があるので注意です。

構造

ロググループ

• 複数のログストリームで構成されています。
• 保持、監視、アクセス制御について同じ設定を共有するグループになります。
• 具体的には、EC2やFargateのホスト名などがここに該当します。

ログストリーム

• 複数のログイベントで構成されます。
• モニタリングしているリソースのタイムスタンプ順でイベントを表します。
• 具体的には、監視したいログファイル名（var/log/messagesなど）がここに入ります。

メトリクスフィルター

ログを特定の文字列からフィルタリングできます。なお、正規表現の利用はできません。アラームやSNS連携なども可能です。

サブスクリプションフィルター

ログのフィルタパターンに応じてリアルタイムにKinesis Data Streamsや、Kinesis Data Firefoseに連携が可能です。

CloudWatch Logs Insights

ログデータをインタラクティブに検索して分析します。

ログイベント

• 1つのログエントリです。
• モニタリングしているリソースによって記録されたアクティビティのレコードです。
• イベント発生時のタイムスタンプ及び、ログメッセージ(UTF-8)で構成されます。

そもそも監視とは？

監視のメリット

障害発生をすぐに検知して復旧作業に取り掛かれるようになる。

監視設定

• 「正常な状態」を定義する。（CPU使用率80%以上等）
• 正常じゃなくなった場合にすぐに通知が来るようにします。

監視設定のポイント

監視項目が多すぎると把握するのが大変ですし監視疲れをします。都度状況に応じて監視項目を増減して最適な監視設定ができるようにしておくのが良いでしょう。最初はCPU、メモリ、ディスク使用率、ネットワーク使用率とうの基本的なリソースのみを監視対象とだけしておけば良いでしょう。

監視設計の注意点

モニタリングの設計を始めるととりあえず「システムに関する情報をできるだけ集める」という方向で考えてしまいがちになりますが、一番大事なのは「利用者のためにモニタリングを行うこと」です。ログであれメトリクスであれ利用者の体験が損なわれないようなイベントを念頭に行うべきです。

例：HTTPレスポンスコードについて監視するなど。

監視の種類

監視には「死活監視」と「メトリクス監視」の2種類があります。

死活監視

• 正常にシステムが動作しているか確認する。

メトリクス監視

• パフォーマンスを定量的に確認
• 指標を決めて、指標が閾値以上、以下となっているか把握

昨今の監視

昨今のアプリケーション開発では、AWSによって用意された各種サービスや比較的小さい粒度のアプリが相互に連携し合う分散システムとすることが一般的。コンポーネント連携が多くなると、構造が複雑になって障害発生時における影響範囲調査の把握や原因の特定が難しくなる。

そこで重要になるのが「トレース」です。システム全体を俯瞰しつつ、内部状態まで深堀りできるような状態を「オブザーバビリティ(可観測性）」という。

検知（メトリクス）

何が起きているのかを定量的に把握する。CloudWatchを利用することで容易に取得できる。

「利用者観点で何が必要か？」ということを一番念頭に考えるべき。

把握(トレース)

どこで起きているのかを知る。X-Rayと組み合わせることでリクエストの流れを追うことができます。

特定(ログ)

なぜ発生したのかを突き止める。CloudWatch Logsを利用することで容易に蓄積できる。また、FireLens(CloudWatch Logsよりは後発サービスになります。)でもいけます。

FireLensであればAWS以外のSaasに対してログ転送などがしやすいなどのメリットがあります。