はじめに
CloudWatch Logs Insightsを使用するときに意識しておかないと、思ったよりコスト高くなるので、クエリの書き方と実行時に注意することをまとめる。
クエリ実行時に注意すること
公式にも掲載されているが、クエリ実行時はロググループを選択すること、時間指定は必ず行うこと。
個人的にはFiledsも指定した方がパフォーマンス上がるので、Mustレベルで指定した方がいいと思う。
ウィジェットは慣れるまで使用しない方が安心。更新のたびにクエリ実行されるので、頻繁に更新されるとコスト嵩む。
生成されるフィールド
| filed | 内容 |
|---|---|
| @message | ログイベント |
| @timestamp | ログイベントに含まれる時刻 |
| @ingestionTime | CloudWatchがイベントを受信した時刻 |
| @logStream | イベントを追加したログストリーム名 |
| @log | ロググループの識別子(account_id:log-group-name) |
クエリ構文
バグ調査などでよく使う構文のみピックアップします。
| コマンド | 内容 | SQLなら |
|---|---|---|
| display | 表示するフィールドを選択 fieldsとごっちゃになりやすいので注意 |
select(イメージ的には表示する内容の順序などレイアウト調整) |
| fields | 表示するフィールドを絞る | select(カラム選択のイメージ) |
| filter | ログイベントのフィルタリング | where |
| sort | ログイベントを昇順または、降順で表示 | order by |
| stats | ログの集計 | group by |
| limit | 検索結果の上位x件を表示 | limit, top |
| dedup | 指定したフィールドの特定の値の重複を除く | distinct |
バグ調査でも汎用クエリ
バグ調査時にログ検索をなるべく効率化しつつ、様々な場面で活躍するクエリを紹介。
ロググループは指定されていること
fields @timestamp, @message, @logStream
| filter @message like {検索したい文字列}
| filter @timestamp >= 1672567200000 and @timestamp <= 1672574400000
| sort @timestamp desc
| limit 10
timestampで絞るときはミリ秒で指定する必要がある。
Fargate使用しているとログストリームよく分かれるので、上記のようなクエリでログストリームを探して、その後、ログストリームで前後のログまで確認すると、調査しやすくなると思います。
クエリだけだと、いつそのログが出力されたかは分かりますが、メッセージでFilterかけている分断片的な部分しか表示されなかったりします。
参考文献