ここではAWSのAmazon CloudWatch初手ベースでの流れを元に話をしているものの、どこでも同じような流れになると思われる。
※Metric／Metrics／メトリック／メトリクス…英語と日本語で表記が揺れるけど細かいこと気にしない。
全体図
部分ごとの説明
保存する
- メトリクスをCloudWatch Metricsに送信する
- メトリクス＝システムのとある日時におけるとある状態を表したデータの集まり
- 概ねAWS側が自動的に各種メトリクスを送信してくれている
- ログをS3やCloudWatch Logsに保存する
- S3保存はAthena利用を見越した形式で行うと吉
- CloudWatch Logs保存はCloudWatch Logs Insights利用を見越した形式で行うと吉
- 必要であれば（※後述）、メトリックフィルターでログから自前メトリクスを生成しておく
監視する
- 「監視」＝「メトリクスを元に予め決めておいた条件で合否判定すること」と言える
- 例：1分毎のエラー発生率が5％を超えるという状態が直近10分間で2回以上発生しているかどうか
- 逆に「合否判定したいのであれば対象となるメトリクスが存在しているべき」と考えると分かり易い
- 例：処理エラー発生回数、処理呼び出し回数
- 例：「◯◯」というエラーメッセージが出たらアウトとしたい＝「『◯◯』というエラーメッセージが出た回数がカウントされているメトリクス」をメトリックフィルターで生成し、そのメトリクスを監視
- 条件次第なので、「大元のサービスで何らかのエラーメトリクスが発生すること」と「監視で否という判定結果になること」は別問題である（勿論、たまたまイコールになるような判定をしている場合もある）
監視対象の状況変化を開発者に通知する
内容の重要度に応じて、通知の有無や方法を考える（例：休日深夜でも通知するのかどうか）。
以下ではSlackを経由した通知を例にしている。
監視対象状況の変化をSlackに投稿する
- 合否状況がこれまでと変化した場合になんらかのアクションを実施する
- アクション＝重要情報向けSlackチャンネルへの投稿
- アクション＝小ネタ向けSlackチャンネルへの投稿
- ※ここではSlack投稿を例にしているが、アクション＝「メール送信」とか「何もしない」でも良いということ
Slack投稿をユーザー通知する
- Slackチャンネルの重要度に応じて、必要があれば新規投稿が発生したことをユーザーに通知する
余談
メトリクスを閲覧する
- 「閲覧」と「監視」は別である
- 「監視」は前述の通り、合否判定をしている
- 「閲覧」＝「任意期間のメトリクスを眺めながらの感想戦につい耽ってしまう」様ってことで…
- 例：昨日の夜間は一昨日の夜間よりアクセス数が多かったんだな〜
- 例：昨日のエラーと同タイミングでCPU利用率も高かったんだな〜
- メトリクスがグラフ化されていると見易い
- 特に気になるメトリクスだけを選抜して一覧化していると、さらに見易い
- 監視（CloudWatch Alarms）状況の変遷をメトリクスだと捉え、これを含めてもよい
ログを閲覧する
- 生データを直接読み込む
- サービスを使って適宜検索する