はじめに
実案件でもCloudWatch Logs Insightsを利用する事が増えてきた事を実感しているこの頃です。
API経由での利用・テストにあたり、1例となりますが注意点を挙げてみました。
結論としては下記3点となります。
- タイムゾーンを考慮する（リクエスト・レスポンス）
- 日・月・年 等跨ぎのテストを行う
- 取得可能最大行数等サービスのクォータに気をつける
目次
事象/原因
バッチ実行結果にずれが生じている？（生じる事がある）
LogsInsightsコンソールとAPI結果に差分があるのではないか！？
→ そんな事はありませんので、Debugログ/すぐに調査可能なものとしてCloudTrailログを見る事をおすすめします。
CloudTrailのイベント履歴を選択、イベントソースを「logs.amazonaws.com」で検索するとクエリ条件を確認する事が出来ます。
原因
原因としては、下記のようなものが想定されます。
日・月・年跨ぎの実行結果が正しいかどうかテストをしっかり行う事も重要と考えております。
- 時刻パラメータ不備 (引き渡しUNIXTIMESTAMP)
- Lambda、EC2、コンテナ内部のタイムゾーン設定
- UNIXTIMESTAMP変換時のタイムゾーン想定不備
- プログラム内部のキャストにより時間ずれが発生してしまっている
- クエリ
- クエリ返却値のタイムゾーンは考慮されているか
@timestampはUTCで返ってくるため、datefloor(@timestamp + 9 * 60 * 60 * 1000, 1d) 等で日本時間に変換しているか
- クエリ返却値のタイムゾーンは考慮されているか
- ロググループ
- ロググループは正しいものが設定されているか
- 番外編（エラー返却される）
- クエリロググループ数、クエリの同時実行数等制限があります、上限緩和可能・不可能な物がありますのでクォータ確認をしましょう
- 高頻度でクエリ実行結果の取得リクエストをするとエラーとなるケースもありますので、適度に待ちましょう
取得/処理データ件数が不足している？
基本的には集約・集計した後のデータ取得のためこちらの例は稀かもしれませんが、集約した結果の行数が多い場合サービス制限に引っかかっている可能性を考慮する必要があります。
原因
取得対象のログ件数が多く、全てのデータ取得に失敗していた。
現状はDefaultで、最大 1,000行、Limit句で大きな値を設定しても最大 10,000行の結果取得となっているため、場合によってはクエリの見直し、ロジックで分割して取得等が必要になります。
まとめ
大変便利なCloudWatch Logs Insightsですが、活用するためには気をつけるべき点もあります。
クラウドサービス全般に言えますが、利用方法を読み試した後は制限事項（クォータ）も熟読し、サービスを活用しましょう！
投稿者プロフィール
