Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Datadog Logs を活用して SLO 監視基盤を構築する
Search
Hayato Kawai
May 29, 2024
2
860
Datadog Logs を活用して SLO 監視基盤を構築する
「Japan Datadog User Group Meetup#4」の登壇資料です。
https://datadog-jp.connpass.com/event/317091/
Hayato Kawai
May 29, 2024
Tweet
Share
More Decks by Hayato Kawai
See All by Hayato Kawai
巨大 tfstate に立ち向かう技術
fohte
1
300
RubyKaigi で LT 初登壇したきっかけと感想
fohte
1
890
The Journey of rubocop-daemon into RuboCop
fohte
1
1.1k
Ruby as Shell script
fohte
1
490
rubocop-daemon 裏話: OSS の苦悩
fohte
2
570
RuboCop Server Mode の仕組み
fohte
1
280
Ruby を使ったプロダクト開発を支えるオブザーバビリティ基盤
fohte
2
140
インシデントコマンダーやってみた
fohte
5
1k
Ruby でもなんとかなる - ISUCON13 公式反省会
fohte
0
140
Featured
See All Featured
Done Done
chrislema
181
16k
A Tale of Four Properties
chriscoyier
156
23k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Raft: Consensus for Rubyists
vanstee
136
6.7k
Thoughts on Productivity
jonyablonski
67
4.3k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
Automating Front-end Workflow
addyosmani
1366
200k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
17k
We Have a Design System, Now What?
morganepeng
50
7.2k
How to Think Like a Performance Engineer
csswizardry
21
1.2k
Transcript
© 2024 Wantedly, Inc. Datadog Logs を活用して SLO 監視基盤を構築する Japan
Datadog User Group Meetup#4 2024-05-29 Hayato Kawai (@fohte)
© 2024 Wantedly, Inc. あなた誰 名前 Fohte (ふぉーて) 川井 颯人
(Hayato Kawai) 所属 ウォンテッドリー株式会社 趣味 🎮 🎹
© 2024 Wantedly, Inc. 今日話すこと • SLO 監視基盤を Datadog Logs
+ Datadog SLO で 構築しました ◦ Datadog Logs の活用事例や Datadog SLO を使う上での注意点について 知見共有します ▪ (他の人の意見やアイデアも聞きたい )
© 2024 Wantedly, Inc. ウォンテッドリーにおける SLO/SLI 定義 • サービスを運営する上で重要な endpoint
において 成功したリクエストの比率を SLI として定義 ◦ レイテンシーも計測したいがまだできていない • SLO はそれぞれの endpoint において過去 90 日間で リクエストの 99.9 % が成功することを目標と定義
© 2024 Wantedly, Inc. いままでの SLO 監視基盤 • BigQuery で
アクセスログを クエリ • Looker で ダッシュボードを 作り可視化
© 2024 Wantedly, Inc. ウォンテッドリーにおける SLO/SLI 運用 (現在) • 週に一度
SLO に違反したエンドポイントがないか SLO ダッシュボードを見て人力チェック • 違反していれば解決に向けて Infra Squad 主導で対応
© 2024 Wantedly, Inc. ウォンテッドリーにおける SLO/SLI 運用の課題 • SLO 違反に迅速に気付けない
◦ 人が能動的に Looker のダッシュボードを確認する必要がある ▪ 基本的に週に一度しか確認できていない ▪ 違反時に通知するような仕組みもない ◦ => エラーレートが上がったら可能な限り早く知りたい • SLO 違反と判断する基準が人によって違う (属人化) ◦ アラートがないので、ダッシュボード見て「大丈夫そう」「だめそう」を 人が判断している ◦ => 判断基準は人に依存しないようにしたい
© 2024 Wantedly, Inc. そして新しい SLO/SLI 監視基盤へ • ウォンテッドリーでは Datadog
をよく使っている ◦ よく使う機能は APM, Infrastructure Monitoring, Logs • Datadog SLO を使えば Datadog で一連の情報が見れて オブザーバビリティを強化できそう ◦ => 試してみて概ね期待通りだったので本格的に導入へ
© 2024 Wantedly, Inc. Datadog SLO の完成品
© 2024 Wantedly, Inc. どう作るか? • Datadog SLO は 3
つ設定方法がある ◦ Metric-based SLO ▪ カスタムメトリクスの特定の値や閾値に基づいて評価する ▪ Monitor でクエリ書くのと同じ ◦ Monitor-based SLO ▪ Monitor を指定し、その Monitor が OK になっている期間の割合を評価する ◦ Time Slice SLO ▪ 定義された時間枠内で正常に動作している時間の割合に基づいて評価する ▪ 例: p95 レイテンシーが 1 秒未満を正常とする
© 2024 Wantedly, Inc. どう作るか? • Datadog SLO は 3
つ設定方法がある ◦ Metric-based SLO ← 今回適していたのはこれ ▪ カスタムメトリクスの特定の値や閾値に基づいて評価する ▪ Monitor でクエリ書くのと同じ ◦ Monitor-based SLO ▪ Monitor を指定し、その Monitor が OK になっている期間の割合を評価する ◦ Time Slice SLO ▪ 定義された時間枠内で正常に動作している時間の割合に基づいて評価する ▪ 例: p95 レイテンシーが 1 秒未満を正常とする
© 2024 Wantedly, Inc. どう作るか? • Metric-based なので、クエリするための metric が
必要 ◦ 「この metric をどうやって作るか」が肝 いい感じの metric いい感じに クエリ
© 2024 Wantedly, Inc. metric をどう作るか • Custom Metrics を作る手段は
いろいろある • 今回は Datadog Logs から metrics を生成した ◦ アクセスログを元に計測したいため ◦ すでにアクセスログは Datadog Logs にあり 実装コストが少ないと判断 https://docs.datadoghq.com/metrics/custom_metrics/
© 2024 Wantedly, Inc. Custom Metric の注意点 • タグの key/value
ごとに 別の custom metrics としてカウントされる ◦ つまり path: "/:id" みたいな タグを設定すると無尽蔵に カウントされて課金される ◦ タグは適当な粒度で集約しておく必 要がある https://docs.datadoghq.com/account_management/billing/custo m_metrics/
© 2024 Wantedly, Inc. 実装の要件 • 「Custom Metrics から、どの SLI
か・またそれが SLI として 正常かどうか判定できる」を実現したい ◦ かつタグが無尽蔵に増えないようにしたい • 今回はこれを Logs の Pipeline で頑張ることにした ◦ ここが最も大変だった
© 2024 Wantedly, Inc. 全体構成 (1/3): AWS の ALB アクセスログ
〜 Datadog Logs ALB Lambda function (Datadog Forwarder) S3 Datadog Logs
© 2024 Wantedly, Inc. 全体構成 (2/3): Datadog Logs 〜 Custom
Metrics Datadog Logs (Logs) Pipeline (Logs) Generate Metrics Custom Metrics ログを parse & 属性追加 処理したログを metric に変換 2024-05-29T14:30:00.123456Z app/my-load-balancer/1234abcd ... { "datetime": "2024-05-29T14:30:00.123456Z", "alb_arn": "app/my-load-balancer/1234abcd", ... } slo_requests{path:"/users/:id"}
© 2024 Wantedly, Inc. 全体構成 (3/3): Custom Metrics 〜 SLO、通知
Custom Metrics Datadog SLO Datadog Monitor Slack クエリ アラート時に 通知 SLO 違反 監視
© 2024 Wantedly, Inc. Pipeline は表現力に制限がある • Logs に入ったログを metric
で扱いやすいようにしたい ◦ ログを構造化できる Pipeline の出番 ▪ Grok Parser や Remapper などを活用してログデータをひたすら加工する ◦ ALB のアクセスログは Datadog で用意された Pipeline がある ▪ アクセスログの生の文字列からの構造化はこれでできる ◦ 「metric で扱いやすいように、パスの集約などをしたい」となると 自分で Pipeline の処理を実装する必要がある
© 2024 Wantedly, Inc. Pipeline は表現力に制限がある • 例: GET /users/123
というリクエストを考える ◦ path:"/users/:id" という tag をつけたい ◦ /users/\d+ という正規表現にマッチしたら /users/:id にすれば良い • 簡単そう! → そんなことはなかった
© 2024 Wantedly, Inc. Pipeline は表現力に制限がある • 正規表現マッチは Grok Parser
でできる ◦ が置換したり別の属性を追加することはできない 😭 ▪ つまり sed -e 's|/users/\d+|/users/:id|' 的なことができない ◦ Grok Parser でできるのは「マッチした文字列に属性を割り当てる」ことだけ ▪ 例えば /users/123 であれば「/users/\d+ にマッチ => path: "/users/123" という属性を追加」はできる ▪ やりたいことは「/users/\d+ にマッチしたら固定の文字列 (/users/:id) を 属性に追加する」なのでちょっと違う
© 2024 Wantedly, Inc. Pipeline は表現力に制限がある • 苦肉の策: / でパスを分割してそれぞれ属性を割り当てる
◦ /users/123 だったら path_0: users, path_1: 123 にする (補足) anypath は %{regex("[^/]*")} という helper を定義している
© 2024 Wantedly, Inc. Pipeline は表現力に制限がある • この分割された属性から Category Processor
で path をグルーピングする ◦ Category Processor はパターンマッチング的なことができる ◦ @slo.path_0:users @slo.path_1:>=0 にマッチしたら path に /users/:id を設定する
© 2024 Wantedly, Inc. Pipeline は表現力に制限がある • なんとか実現できたけどつらい! • Pipeline
に正規表現で置換できる Processor がほしい! ◦ Datadog さんお願いします 🙏
© 2024 Wantedly, Inc. (再掲) Datadog SLO の完成品
© 2024 Wantedly, Inc. 使い勝手は 👍 • Datadog SLO はとても
見やすいし使いやすい ◦ ログの処理は大変だが、一度 実装できてしまえば便利 • 「SLO 違反に迅速に 気付きたい」という元の 目的も達成できた 実際のアラート
© 2024 Wantedly, Inc. まだ課題はある • SLI の計測対象の変更にすぐに追従できない ◦ 既存の
Logs のログデータが変更できない ▪ 既存のログに対して Pipeline を再度通せない ◦ 例: 特定の User-Agent からのリクエストは計測対象から除外したいケース ▪ Logs Pipeline で計測対象から除外するしかない (skip: true 的な属性をつける等 ) ▪ 新しいログにしか適用されないので、既存のリクエストが除外できない ◦ いい方法・案があれば知りたい (切実)
© 2024 Wantedly, Inc. まとめ • Datadog Logs (主に Pipeline)
を駆使して Datadog SLO で SLO の監視基盤を作りました ◦ Pipeline は表現力に制約があるので、使う前に本当に実現できるか検証しよう ◦ まだ最善ではない。引き続き良い設計の模索は必要そう