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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 2024 Wantedly, Inc. ウォンテッドリーにおける SLO/SLI 運用の課題 ● SLO 違反に迅速に気付けない ○ 人が能動的に Looker のダッシュボードを確認する必要がある ■ 基本的に週に一度しか確認できていない ■ 違反時に通知するような仕組みもない ○ => エラーレートが上がったら可能な限り早く知りたい ● SLO 違反と判断する基準が人によって違う (属人化) ○ アラートがないので、ダッシュボード見て「大丈夫そう」「だめそう」を人が判断している ○ => 判断基準は人に依存しないようにしたい

Slide 8

Slide 8 text

© 2024 Wantedly, Inc. そして新しい SLO/SLI 監視基盤へ ● ウォンテッドリーでは Datadog をよく使っている ○ よく使う機能は APM, Infrastructure Monitoring, Logs ● Datadog SLO を使えば Datadog で一連の情報が見れてオブザーバビリティを強化できそう ○ => 試してみて概ね期待通りだったので本格的に導入へ

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 2024 Wantedly, Inc. どう作るか? ● Datadog SLO は 3 つ設定方法がある ○ Metric-based SLO ■ カスタムメトリクスの特定の値や閾値に基づいて評価する ■ Monitor でクエリ書くのと同じ ○ Monitor-based SLO ■ Monitor を指定し、その Monitor が OK になっている期間の割合を評価する ○ Time Slice SLO ■ 定義された時間枠内で正常に動作している時間の割合に基づいて評価する ■ 例: p95 レイテンシーが 1 秒未満を正常とする

Slide 11

Slide 11 text

© 2024 Wantedly, Inc. どう作るか? ● Datadog SLO は 3 つ設定方法がある ○ Metric-based SLO ← 今回適していたのはこれ ■ カスタムメトリクスの特定の値や閾値に基づいて評価する ■ Monitor でクエリ書くのと同じ ○ Monitor-based SLO ■ Monitor を指定し、その Monitor が OK になっている期間の割合を評価する ○ Time Slice SLO ■ 定義された時間枠内で正常に動作している時間の割合に基づいて評価する ■ 例: p95 レイテンシーが 1 秒未満を正常とする

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2024 Wantedly, Inc. metric をどう作るか ● Custom Metrics を作る手段はいろいろある ● 今回は Datadog Logs から metrics を生成した ○ アクセスログを元に計測したいため ○ すでにアクセスログは Datadog Logs にあり実装コストが少ないと判断 https://docs.datadoghq.com/metrics/custom_metrics/

Slide 14

Slide 14 text

© 2024 Wantedly, Inc. Custom Metric の注意点 ● タグの key/value ごとに別の custom metrics としてカウントされる ○ つまり path: "/:id" みたいなタグを設定すると無尽蔵にカウントされて課金される ○ タグは適当な粒度で集約しておく必要がある https://docs.datadoghq.com/account_management/billing/custo m_metrics/

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 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"}

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2024 Wantedly, Inc. Pipeline は表現力に制限がある ● Logs に入ったログを metric で扱いやすいようにしたい ○ ログを構造化できる Pipeline の出番 ■ Grok Parser や Remapper などを活用してログデータをひたすら加工する ○ ALB のアクセスログは Datadog で用意された Pipeline がある ■ アクセスログの生の文字列からの構造化はこれでできる ○ 「metric で扱いやすいように、パスの集約などをしたい」となると自分で Pipeline の処理を実装する必要がある

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© 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) を属性に追加する」なのでちょっと違う

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© 2024 Wantedly, Inc. まだ課題はある ● SLI の計測対象の変更にすぐに追従できない ○ 既存の Logs のログデータが変更できない ■ 既存のログに対して Pipeline を再度通せない ○ 例: 特定の User-Agent からのリクエストは計測対象から除外したいケース ■ Logs Pipeline で計測対象から除外するしかない (skip: true 的な属性をつける等 ) ■ 新しいログにしか適用されないので、既存のリクエストが除外できない ○ いい方法・案があれば知りたい (切実)

Slide 28

Slide 28 text