▫️ はじめに
先日、担当していた案件の中で、ユーザーに対してメッセージを送信するバッチ処理があり、その処理が「きちんと送信できているか」をログベースで把握できる状態にしておきたいと考えました。
最初、CloudWatch Logs Insightsでログを検索していましたが、以下の問題がありました。
- 毎回クエリを書く必要がある
-
successという文字列を含む 余計なログまで拾ってしまう - 定常的な監視やアラートには少し使いづらい
そんな時に、上長に
「メトリクスストリームやMetric Filterを使えば、もう少し簡単にログの数が取得できるのでは？」
という話を伺いました。
調べていく中で、今回の用途では Metric Filter を使うのが一番ちょうどよい、という結論に至りました。
この記事では、なぜMetric Filterが最適だったのか、そして実際の設定方法までまとめます。
▫️ メトリクスストリームとは？
CloudWatchのMetric Streamsは、
CloudWatch Metricsを、ほぼリアルタイムに外部へ配信する仕組み
です。
重要なポイントは次の通りです。
- ログを流す機能ではない
- CloudWatchに存在するメトリクスのみをストリーミングする
- 低遅延で外部の監視基盤へ送れる
主な用途
- Datadog / New Relic / Dynatrace などの監視基盤に低遅延でメトリクスを送信（API ポーリングより高速）
- 複数アカウント・複数リージョンのメトリクスを集約
- S3などに保存して後から分析
重大な制約
- Metric Streamsを有効にしていなかった時間帯のメトリクスは後から埋め戻しできない
- 過去に遡って流す（backfill）は不可
▫️ Logs InsightsとMetric Streamsは別物
調べて分かったのは、
Logs InsightsとMetric Streamsは、そもそも対象が違うということでした。
- Logs Insights
→ ログを検索・分析する仕組み - Metric Streams
→ メトリクスを配信する仕組み
つまり、
Logs Insights のクエリを、そのままMetric Streamsで便利にする
ということはできない
ということです。
▫️ ただし「メトリクス化」できれば話は別
今回見たかったのは、
メッセージが何件送信されたか
つまり、
- 特定の処理
- 特定のログ
- その発生回数
です。
このログを メトリクス化できれば、
- CloudWatchダッシュボードで即確認できる
- success / failure を分けて監視できる
- アラームを設定できる
- 将来、必要になればMetric Streamsで外部監視基盤に流せる
という構成が取れます。
▫️ 過去分をメトリクスとして追えるかどうか
ここも重要なポイントです！
- Metric Filter / EMF
→ 作成後のログのみが対象 - Metric Streams
→ 有効化後のメトリクスのみが対象
どちらも
過去に遡ってメトリクスを生やすことはできません。
過去分を見たい場合は、
- Logs Insights
- S3 + Athena
など、別の手段が必要になります。
▫️ 今回やりたかったこと
やりたかったことを整理すると、以下です。
- アプリケーションに仕込んだメッセージを送信する処理
- 成功時に出るログを拾いたい
- 送信件数を継続的に把握したい
- Logs Insights のように余計なログを拾いたくない
この要件に対して、
- Logs Insights
→ 調査向け、定常監視には向かない - Metric Streams
→ メトリクスが前提、ログは対象外
ということで、
👉 Metric Filter を使うのが最適という結論になりました。
▫️ Metric Filterとは？
Metric Filter は、
特定のログパターンが出現した回数を
自動的にCloudWatchメトリクスとして記録する仕組み
です。
ログ 1 行 = 1 カウント
という使い方ができるため、 今回の用途にぴったりでした。
▫️ 実際のログ例
今回対象にしたログは、例えば次のようなものです。
INFO Response: { success: true } for user U××××××××××××××××××××××××××××××××
- JSONではなくプレーンテキスト
-
success: trueが含まれている - userIdは毎回変わる
▫️ Metric Filter の設定方法（AWSコンソール）
1. ロググループを開く
CloudWatch
→ Logs
→ Log groups
→ 対象の Lambda / バッチのロググループ
2. Metric Filter を作成
- 「Metric filters」タブ
- 「Create metric filter」
3. フィルターパターン
今回のログに対しては、以下のように設定しました。
“Response:” “success: true”
- スペース区切りはAND 条件
- 正規表現は使えない点に注意
※ Logs Insightsのクエリ構文とは異なるため、そのまま流用できない点に注意が必要です。
これで、
- メッセージ送信成功ログのみ
- 他の
successログは除外
できます。
▫️ 4. メトリクス定義
- メトリクス名前空間
Custom/Response
- メトリクス名
RemindSuccessCount
- メトリクス値
1
ログ 1 行 = 1 件としてカウントされます。
▫️ 5. 作成後の注意点
- フィルター作成後のログのみが対象
- 最初の1件が来るまでMetrics画面には表示されない
- 一度でもマッチすると、
Custom/Response/RemindSuccessCountが出現する
▫️ この構成にしてよかったこと
- Logs Insights のように毎回クエリを書く必要がない
- ノイズログを拾わない
- success / failure を分けて可視化できる
- アラーム設定が簡単
- 将来Metric Streamsにも流せる
▫️ まとめ
- Metric Streams は「メトリクス配信」
- Logs Insights は「ログ調査」
-
ログの発生回数を継続監視したい場合は
👉 Metric Filter がちょうどいい
今回の「メッセージが何件送信されたか」を知りたい、という要件は、
- Logs Insights ではやや重く
- Metric Streams では対象外
そのため、
Metric Filter を使うのが最適解だった、という話でした！