▫️ はじめに

先日、担当していた案件の中で、ユーザーに対してメッセージを送信するバッチ処理があり、その処理が「きちんと送信できているか」をログベースで把握できる状態にしておきたいと考えました。

最初、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 件としてカウントされます。

▫️ 5. 作成後の注意点

フィルター作成後のログのみが対象
最初の1件が来るまでMetrics画面には表示されない
一度でもマッチすると、Custom/Response/RemindSuccessCountが出現する

▫️ この構成にしてよかったこと

Logs Insights のように毎回クエリを書く必要がない
ノイズログを拾わない
success / failure を分けて可視化できる
アラーム設定が簡単
将来Metric Streamsにも流せる

▫️ まとめ

Metric Streams は「メトリクス配信」
Logs Insights は「ログ調査」
ログの発生回数を継続監視したい場合は
👉 Metric Filter がちょうどいい

今回の「メッセージが何件送信されたか」を知りたい、という要件は、

Logs Insights ではやや重く
Metric Streams では対象外

そのため、
Metric Filter を使うのが最適解だった、という話でした！