Datadog Logs を活用して SLO 監視基盤を構築する

「Japan Datadog User Group Meetup#4」の登壇資料です。
https://datadog-jp.connpass.com/event/317091/

Transcript

1. © 2024 Wantedly, Inc. Datadog Logs を活用して SLO 監視基盤を構築する Japan Datadog User Group Meetup#4 2024-05-29 Hayato Kawai (@fohte)
2. © 2024 Wantedly, Inc. あなた誰 名前 Fohte (ふぉーて) 川井 颯人 (Hayato Kawai) 所属 ウォンテッドリー株式会社 趣味 🎮 🎹
3. © 2024 Wantedly, Inc. 今日話すこと • SLO 監視基盤を Datadog Logs + Datadog SLO で 構築しました ◦ Datadog Logs の活用事例や Datadog SLO を使う上での注意点について 知見共有します ▪ (他の人の意見やアイデアも聞きたい )
4. © 2024 Wantedly, Inc. ウォンテッドリーにおける SLO/SLI 定義 • サービスを運営する上で重要な endpoint において 成功したリクエストの比率を SLI として定義 ◦ レイテンシーも計測したいがまだできていない • SLO はそれぞれの endpoint において過去 90 日間で リクエストの 99.9 % が成功することを目標と定義
5. © 2024 Wantedly, Inc. いままでの SLO 監視基盤 • BigQuery で アクセスログを クエリ • Looker で ダッシュボードを 作り可視化
6. © 2024 Wantedly, Inc. ウォンテッドリーにおける SLO/SLI 運用 (現在) • 週に一度 SLO に違反したエンドポイントがないか SLO ダッシュボードを見て人力チェック • 違反していれば解決に向けて Infra Squad 主導で対応
7. © 2024 Wantedly, Inc. ウォンテッドリーにおける SLO/SLI 運用の課題 • SLO 違反に迅速に気付けない ◦ 人が能動的に Looker のダッシュボードを確認する必要がある ▪ 基本的に週に一度しか確認できていない ▪ 違反時に通知するような仕組みもない ◦ => エラーレートが上がったら可能な限り早く知りたい • SLO 違反と判断する基準が人によって違う (属人化) ◦ アラートがないので、ダッシュボード見て「大丈夫そう」「だめそう」を 人が判断している ◦ => 判断基準は人に依存しないようにしたい
8. © 2024 Wantedly, Inc. そして新しい SLO/SLI 監視基盤へ • ウォンテッドリーでは Datadog をよく使っている ◦ よく使う機能は APM, Infrastructure Monitoring, Logs • Datadog SLO を使えば Datadog で一連の情報が見れて オブザーバビリティを強化できそう ◦ => 試してみて概ね期待通りだったので本格的に導入へ
9. © 2024 Wantedly, Inc. Datadog SLO の完成品
10. © 2024 Wantedly, Inc. どう作るか? • Datadog SLO は 3 つ設定方法がある ◦ Metric-based SLO ▪ カスタムメトリクスの特定の値や閾値に基づいて評価する ▪ Monitor でクエリ書くのと同じ ◦ Monitor-based SLO ▪ Monitor を指定し、その Monitor が OK になっている期間の割合を評価する ◦ Time Slice SLO ▪ 定義された時間枠内で正常に動作している時間の割合に基づいて評価する ▪ 例: p95 レイテンシーが 1 秒未満を正常とする
11. © 2024 Wantedly, Inc. どう作るか? • Datadog SLO は 3 つ設定方法がある ◦ Metric-based SLO ← 今回適していたのはこれ ▪ カスタムメトリクスの特定の値や閾値に基づいて評価する ▪ Monitor でクエリ書くのと同じ ◦ Monitor-based SLO ▪ Monitor を指定し、その Monitor が OK になっている期間の割合を評価する ◦ Time Slice SLO ▪ 定義された時間枠内で正常に動作している時間の割合に基づいて評価する ▪ 例: p95 レイテンシーが 1 秒未満を正常とする
12. © 2024 Wantedly, Inc. どう作るか? • Metric-based なので、クエリするための metric が 必要 ◦ 「この metric をどうやって作るか」が肝 いい感じの metric いい感じに クエリ
13. © 2024 Wantedly, Inc. metric をどう作るか • Custom Metrics を作る手段は いろいろある • 今回は Datadog Logs から metrics を生成した ◦ アクセスログを元に計測したいため ◦ すでにアクセスログは Datadog Logs にあり 実装コストが少ないと判断 https://docs.datadoghq.com/metrics/custom_metrics/
14. © 2024 Wantedly, Inc. Custom Metric の注意点 • タグの key/value ごとに 別の custom metrics としてカウントされる ◦ つまり path: "/:id" みたいな タグを設定すると無尽蔵に カウントされて課金される ◦ タグは適当な粒度で集約しておく必 要がある https://docs.datadoghq.com/account_management/billing/custo m_metrics/
15. © 2024 Wantedly, Inc. 実装の要件 • 「Custom Metrics から、どの SLI か・またそれが SLI として 正常かどうか判定できる」を実現したい ◦ かつタグが無尽蔵に増えないようにしたい • 今回はこれを Logs の Pipeline で頑張ることにした ◦ ここが最も大変だった
16. © 2024 Wantedly, Inc. 全体構成 (1/3): AWS の ALB アクセスログ 〜 Datadog Logs ALB Lambda function (Datadog Forwarder) S3 Datadog Logs
17. © 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"}
18. © 2024 Wantedly, Inc. 全体構成 (3/3): Custom Metrics 〜 SLO、通知 Custom Metrics Datadog SLO Datadog Monitor Slack クエリ アラート時に 通知 SLO 違反 監視
19. © 2024 Wantedly, Inc. Pipeline は表現力に制限がある • Logs に入ったログを metric で扱いやすいようにしたい ◦ ログを構造化できる Pipeline の出番 ▪ Grok Parser や Remapper などを活用してログデータをひたすら加工する ◦ ALB のアクセスログは Datadog で用意された Pipeline がある ▪ アクセスログの生の文字列からの構造化はこれでできる ◦ 「metric で扱いやすいように、パスの集約などをしたい」となると 自分で Pipeline の処理を実装する必要がある
20. © 2024 Wantedly, Inc. Pipeline は表現力に制限がある • 例: GET /users/123 というリクエストを考える ◦ path:"/users/:id" という tag をつけたい ◦ /users/\d+ という正規表現にマッチしたら /users/:id にすれば良い • 簡単そう! → そんなことはなかった
21. © 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) を 属性に追加する」なのでちょっと違う
22. © 2024 Wantedly, Inc. Pipeline は表現力に制限がある • 苦肉の策: / でパスを分割してそれぞれ属性を割り当てる ◦ /users/123 だったら path_0: users, path_1: 123 にする (補足) anypath は %{regex("[^/]*")} という helper を定義している
23. © 2024 Wantedly, Inc. Pipeline は表現力に制限がある • この分割された属性から Category Processor で path をグルーピングする ◦ Category Processor はパターンマッチング的なことができる ◦ @slo.path_0:users @slo.path_1:>=0 にマッチしたら path に /users/:id を設定する
24. © 2024 Wantedly, Inc. Pipeline は表現力に制限がある • なんとか実現できたけどつらい! • Pipeline に正規表現で置換できる Processor がほしい! ◦ Datadog さんお願いします 🙏
25. © 2024 Wantedly, Inc. (再掲) Datadog SLO の完成品
26. © 2024 Wantedly, Inc. 使い勝手は 👍 • Datadog SLO はとても 見やすいし使いやすい ◦ ログの処理は大変だが、一度 実装できてしまえば便利 • 「SLO 違反に迅速に 気付きたい」という元の 目的も達成できた 実際のアラート
27. © 2024 Wantedly, Inc. まだ課題はある • SLI の計測対象の変更にすぐに追従できない ◦ 既存の Logs のログデータが変更できない ▪ 既存のログに対して Pipeline を再度通せない ◦ 例: 特定の User-Agent からのリクエストは計測対象から除外したいケース ▪ Logs Pipeline で計測対象から除外するしかない (skip: true 的な属性をつける等 ) ▪ 新しいログにしか適用されないので、既存のリクエストが除外できない ◦ いい方法・案があれば知りたい (切実)
28. © 2024 Wantedly, Inc. まとめ • Datadog Logs (主に Pipeline) を駆使して Datadog SLO で SLO の監視基盤を作りました ◦ Pipeline は表現力に制約があるので、使う前に本当に実現できるか検証しよう ◦ まだ最善ではない。引き続き良い設計の模索は必要そう