CloudWatch Logs Insightsをめぐるあれこれ

CloudWatch Logs Insightsをめぐるあれこれ
2024/08/23 kyotoLT発表資料

Transcript

1. Road to CloudWatch Logs Insights # CloudWatchLogs Insightsをめぐるあれこれ Junki Ishigaki August 23, 2024
2. 自己紹介 石垣潤樹 / Junki Ishigaki - 所属 → 株式会社シーズ - やっていること → インフラエンジニア - やっていること → AWSとかさわってます - 好きなAWSサービス → Athena - 最近 → Amplify Gen 2楽しい - 好き → ラーメン, 担々麺 2
3. 目次 - CloudWatch Logs Insight について - 自然言語によるクエリ生成さわってみる - 自然言語によるクエリ生成の勘所 - 感想など 3
4. CloudWatch Logs Insights について 4
5. なぜ、注目したいか 5 ついついやってしまうけど、これ苦しい (検索は検索でフィルターパターンはあるけれど…) これもこれでツライ
6. CloudWatch Logs Insightsについて 6 これ
7. CloudWatch Logs Insightsについて 7 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/AnalyzingLogData.html ざっくりいうと、CloudWatch Logsにクエリ投げれます
8. 今日の裏テーマ 8 汎用的な知識 ・いろんなところで使える ・覚えるモチベーション↑↑↑ 局所的な知識 ・特定のところでしか使えない ・覚えるモチベーション↓↓↓ できるだけこっちを覚えたい
9. 自然言語によるクエリ生成 さわってみる 9
10. CloudWatch Logs Insightsさわってみる 10 fields @timestamp, @message, @logStream, @log | sort @timestamp desc | limit 10000 「なんとなくはわかる」 「なんとなくしかわかんない」 「これ覚えるの？？」 「ツライ」 最初のサンプルクエリ これ覚えるでもいいけども…
11. 自然言語によるクエリ生成 11 latest 3 record fields @timestamp, @message | sort @timestamp desc | limit 3 - re:Invent 2023で発表 - 2024年1月GA(2024/8現在バージニア北部, オレゴン, 東京リージョンで利用可) 生成プロンプト 生成されるクエリ
12. 画面的には以下みたいな感じ 12
13. ちなみに 13 - プレビュー期間に 日本語使えていた 期間もありました。 (今はEnglish Only)
14. 自然言語によるクエリ生成の勘所 14
15. 注意 - このあと出てくる例で生成されるクエリは性質上必ずしも一意なものではないです。 (場合によってはうまく生成されないこともあるかと思います) - 雰囲気を感じ取ってもらえればと思います。 15
16. より汎用性を求めて 16 - 英語から生成されるとはいうものの… - 分析用のクエリ言語としてもっと汎用的なものを人類は知っている。 S tructured Q uery L anguage
17. SQL使いたい 17 - とりあえずparseしたい。 172.147.146.148 - - [21/Aug/2024:15:55:45 +0000] "GET /item/electronics/1964 HTTP/1.1" 200 40 "http://www.google.com/search?ie=UTF-8&q=google&sclient=psy- ab&q=Electronics+Games&oq=Electronics+Games&aq=f&aqi=g- vL1&aql=&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&biw=1847&bih=442" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11" 164.63.158.69 - - [21/Aug/2024:15:55:46 +0000] "GET /category/jewelry?from=10 HTTP/1.1" 200 78 "/category/electronics" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)" 32.207.135.191 - - [21/Aug/2024:15:55:47 +0000] "GET /item/games/1443 HTTP/1.1" 200 59 "/category/software" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0.1) Gecko/20100101 Firefox/9.0.1" こうしたい
18. parse - ここだけは腕力 18 parse '* - * [*] "* * *" * * * *' as host, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes,Referer,UserAgent CloudWatch Logs Insightsのほうで上記のよ うな感じで (ログを横目で見ながら腕力でparse)
19. 腕力のいらない方法 19 { "host": "172.183.203.219", "user": "-", "method": "GET", "path": "/category/office", "code": 200, "referer": "/item/electronics/1390", "size": 74, "agent": "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" } fields host, user, method, path, code, referrer, size, agent | limit 5 こういうログならそのままいける
20. やっていきます 20 select count(*) where code != "200" fields @timestamp, @message | parse @message "Status Code: *" as statusCode | filter statusCode != "200" | stats count(*) as count それっぽいのが出る fields @timestamp, @message | filter code != "200" | stats count(*) as count ゴニョる
21. うまくいく parse '* - * [*] "* * *" * * * *' as host, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes,Referer,UserAgent | filter statusCode != "200" | stats count(*) as count 21 処理内でparseする場合は以下のようなゴニョり
22. やっていきます2 22 SELECT host, COUNT(*) as count GROUP BY host ORDER BY host DESC limit 10; fields @logStream as host | stats count(*) as count by @logStream | sort count desc | limit 10 それっぽいのが出る fields host | stats count(*) as count by host | sort count desc | limit 10 ゴニョる
23. うまくいく2 23
24. やっていきます3 24 SELECT HOUR(@timestamp) AS hour, COUNT(*) AS count_per_hour GROUP BY hour ORDER BY count_per_hour DESC; fields @timestamp | stats count(*) as count_per_hour by bin(1hr) | sort count_per_hour desc それっぽいのが出る そのままいけそう
25. うまくいく3 25
26. 応用できそう3 26 fields @timestamp | stats count(*) as count_per_hour by bin(5min) | sort count_per_hour desc
27. 感想など 27
28. 感想など - SQLからLogs Insightsのクエリに変換する作戦はけっこう有効。 - ただし、多少のゴニョり力は必要(読めるけどパッと書けないくらいのレベル感)。 - 何回かゴニョっていると、Logs Insightsのクエリにも結局慣れる。 - parseされていると便利。 - AWSサービスのログとかはjsonだったりするのでそれらには使いやすそう。 - Athenaは偉大。 - データカタログにスキーマ情報入っているのはやはり便利。 - クエリは保存できるので結局よく使うクエリは保存しておく等の対応が吉。 - 普段の運用で使えるかどうかはここがキモ。 28
29. 裏話 - 今回の検証で使用したサンプルログはEC2でapache-loggen(rubyのgem)にて作成して CloudWatchAgentからCloudWatch Logsに転送しました。(これが一番大変だった) - apache-loggen → https://github.com/tamtam180/apache_log_gen [ぼやき] - S3からCloudWatch Logsにインポートできたりすると検証楽になるのに。 - aws-cliで入れる手(put-log-events)もあったけどそれも手間そうだった。 - Athenaはそのあたりの検証も楽でやはり偉大。 - 普段使いの検索 → Cloudwatch Logs Insights - オブザーバビリティ寄りの分析 → Cloudwatch Logs Insights or Athena - BI寄りの分析 → Athena 29
30. ありがとうございました