Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
CloudWatch Logs Insightsをめぐるあれこれ
Search
Junki Ishigaki
August 23, 2024
Technology
0
130
CloudWatch Logs Insightsをめぐるあれこれ
CloudWatch Logs Insightsをめぐるあれこれ
2024/08/23 kyotoLT発表資料
Junki Ishigaki
August 23, 2024
Tweet
Share
More Decks by Junki Ishigaki
See All by Junki Ishigaki
impressions-trying-lambda-web-adapter
junkishigaki
2
220
talk_about_wasmwasi
junkishigaki
0
210
Athenaのコスト節約を考える
junkishigaki
0
21
Other Decks in Technology
See All in Technology
人と組織に偏重したEMへのアンチテーゼ──なぜ、EMに設計力が必要なのか/An antithesis to the overemphasis of people and organizations in EM
dskst
6
630
VPC Latticeのサービスエンドポイント機能を使用した複数VPCアクセス
duelist2020jp
0
260
Understanding Go GC #coefl_go_jp
bengo4com
0
1.1k
Goss: Faiss向けの新しい本番環境対応 Goバインディング #coefl_go_jp
bengo4com
0
1.4k
Claude Code x Androidアプリ 開発
kgmyshin
1
600
攻撃と防御で実践するプロダクトセキュリティ演習~導入パート~
recruitengineers
PRO
3
330
開発と脆弱性と脆弱性診断についての話
su3158
1
1.1k
JavaScript 研修
recruitengineers
PRO
4
330
EKS Pod Identity における推移的な session tags
z63d
1
210
AIエージェント就活入門 - MCPが履歴書になる未来
eltociear
0
550
つくって納得、つかって実感! 大規模言語モデルことはじめ
recruitengineers
PRO
25
6.6k
Evolution on AI Agent and Beyond - AGI への道のりと、シンギュラリティの3つのシナリオ
masayamoriofficial
0
190
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Scaling GitHub
holman
462
140k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
How STYLIGHT went responsive
nonsquared
100
5.7k
Producing Creativity
orderedlist
PRO
347
40k
Become a Pro
speakerdeck
PRO
29
5.5k
Mobile First: as difficult as doing things right
swwweet
223
9.9k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Transcript
Road to CloudWatch Logs Insights # CloudWatchLogs Insightsをめぐるあれこれ Junki Ishigaki
August 23, 2024
自己紹介 石垣潤樹 / Junki Ishigaki - 所属 → 株式会社シーズ -
やっていること → インフラエンジニア - やっていること → AWSとかさわってます - 好きなAWSサービス → Athena - 最近 → Amplify Gen 2楽しい - 好き → ラーメン, 担々麺 2
目次 - CloudWatch Logs Insight について - 自然言語によるクエリ生成さわってみる - 自然言語によるクエリ生成の勘所
- 感想など 3
CloudWatch Logs Insights について 4
なぜ、注目したいか 5 ついついやってしまうけど、これ苦しい (検索は検索でフィルターパターンはあるけれど…) これもこれでツライ
CloudWatch Logs Insightsについて 6 これ
CloudWatch Logs Insightsについて 7 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/AnalyzingLogData.html ざっくりいうと、CloudWatch Logsにクエリ投げれます
今日の裏テーマ 8 汎用的な知識 ・いろんなところで使える ・覚えるモチベーション↑↑↑ 局所的な知識 ・特定のところでしか使えない ・覚えるモチベーション↓↓↓ できるだけこっちを覚えたい
自然言語によるクエリ生成 さわってみる 9
CloudWatch Logs Insightsさわってみる 10 fields @timestamp, @message, @logStream, @log |
sort @timestamp desc | limit 10000 「なんとなくはわかる」 「なんとなくしかわかんない」 「これ覚えるの??」 「ツライ」 最初のサンプルクエリ これ覚えるでもいいけども…
自然言語によるクエリ生成 11 latest 3 record fields @timestamp, @message | sort
@timestamp desc | limit 3 - re:Invent 2023で発表 - 2024年1月GA(2024/8現在バージニア北部, オレゴン, 東京リージョンで利用可) 生成プロンプト 生成されるクエリ
画面的には以下みたいな感じ 12
ちなみに 13 - プレビュー期間に 日本語使えていた 期間もありました。 (今はEnglish Only)
自然言語によるクエリ生成の勘所 14
注意 - このあと出てくる例で生成されるクエリは性質上必ずしも一意なものではないです。 (場合によってはうまく生成されないこともあるかと思います) - 雰囲気を感じ取ってもらえればと思います。 15
より汎用性を求めて 16 - 英語から生成されるとはいうものの… - 分析用のクエリ言語としてもっと汎用的なものを人類は知っている。 S tructured Q uery
L anguage
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" こうしたい
parse - ここだけは腕力 18 parse '* - * [*] "*
* *" * * * *' as host, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes,Referer,UserAgent CloudWatch Logs Insightsのほうで上記のよ うな感じで (ログを横目で見ながら腕力でparse)
腕力のいらない方法 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 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 ゴニョる
うまくいく parse '* - * [*] "* * *" *
* * *' as host, identity, dateTimeString, httpVerb, url, protocol, statusCode, bytes,Referer,UserAgent | filter statusCode != "200" | stats count(*) as count 21 処理内でparseする場合は以下のようなゴニョり
やっていきます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 ゴニョる
うまくいく2 23
やっていきます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 それっぽいのが出る そのままいけそう
うまくいく3 25
応用できそう3 26 fields @timestamp | stats count(*) as count_per_hour by
bin(5min) | sort count_per_hour desc
感想など 27
感想など - SQLからLogs Insightsのクエリに変換する作戦はけっこう有効。 - ただし、多少のゴニョり力は必要(読めるけどパッと書けないくらいのレベル感)。 - 何回かゴニョっていると、Logs Insightsのクエリにも結局慣れる。 -
parseされていると便利。 - AWSサービスのログとかはjsonだったりするのでそれらには使いやすそう。 - Athenaは偉大。 - データカタログにスキーマ情報入っているのはやはり便利。 - クエリは保存できるので結局よく使うクエリは保存しておく等の対応が吉。 - 普段の運用で使えるかどうかはここがキモ。 28
裏話 - 今回の検証で使用したサンプルログは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
ありがとうございました