Slide 1

Slide 1 text

OTel Collector 〜TailSamplingとSpanMetricsを両立させる〜 OpenTelemetry Meetup 2024-11 @gumamon33 1

Slide 2

Slide 2 text

アジェンダ ● 自己紹介 ● OTel Collectorの概要 ● 課題(Traceの一部収集 and Metricsの全収集) ● 課題解消の難しさ ● 課題解消の一例(多段構成アプローチ) ● まとめ 2

Slide 3

Slide 3 text

アジェンダ ● 自己紹介 ● OTel Collectorの概要 ● 課題(Traceの一部収集 and Metricsの全収集) ● 課題解消の難しさ ● 課題解消の一例(多段構成アプローチ) ● まとめ 3

Slide 4

Slide 4 text

自己紹介 ● 稲熊修宏 (いなぐまのぶひろ) ● 株式会社ラクス / SRE課 ● 社内プラットフォームの守り人 ● おチビ達のしもべ ● X (@gumamon33) 4

Slide 5

Slide 5 text

5

Slide 6

Slide 6 text

6

Slide 7

Slide 7 text

7

Slide 8

Slide 8 text

https://career-recruit.rakus.co.jp/career_engineer/ 積極採用中! ・ ・ ・ 8

Slide 9

Slide 9 text

https://career-recruit.rakus.co.jp/engineer_jobs/sreengineer 9

Slide 10

Slide 10 text

アジェンダ ● 自己紹介 ● OTel Collectorの概要 ● 課題(Traceの一部収集 and Metricsの全収集) ● 課題解消の難しさ ● 課題解消の一例(多段構成アプローチ) ● まとめ 10

Slide 11

Slide 11 text

OTel Collectorの概要 OpenTelemetry Collector ベンダーに依存しない方法でテレメトリ データを受信、処理、エクスポート https://opentelemetry.io/docs/collector/ より引用 11

Slide 12

Slide 12 text

OTel Collectorの概要 OpenTelemetry Collector ベンダーに依存しない方法でテレメトリ データを受信、処理、エクスポート プラガブルな構造 ● Receivers ● Processors ● Exporters + ● ( Connector ) Stream 12

Slide 13

Slide 13 text

OTel Collectorの概要 OpenTelemetry Collector 今日の発表では以下の図を多用します https://opentelemetry.io/docs/collector/building/connector/ より引用 = 13

Slide 14

Slide 14 text

OTel Collectorの概要 OpenTelemetry Collector 今日の発表では以下の図を多用します https://opentelemetry.io/docs/collector/building/connector/ より引用 スペースの関係上小さめに・・・覚えておいて下さい! = 14

Slide 15

Slide 15 text

OTel Collectorの概要 OpenTelemetry Collector ディストリビューションについて 本日紹介するコンポーネントの多くは Contribution Distro です。 Collectorの公式ディストリビューションですが、 3rdパーティ製のコンポーネントを多く含む為、セキュリ ティの観点から必要なコンポーネントのみでビルドすることが推奨されています。 また、安定性レベルが α以下のコンポーネントも多くありますので、 利用される際には各々自己責任でお願い致します。 15

Slide 16

Slide 16 text

アジェンダ ● 自己紹介 ● OTel Collectorの概要 ● 課題(Traceの一部収集 and Metricsの全収集) ● 課題解消の難しさ ● 課題解消の一例(多段構成アプローチ) ● まとめ 16

Slide 17

Slide 17 text

課題 Traceをデータソースとした可観測性の向上 ● Trace ○ 全て収集しようとすると膨大な量 ○ 実際に見たいのは エラー または 応答遅延のみ → 問題のある Traceのみが欲しい (一部収集) ● Metrics (from Trace) ○ 各APIへのリクエストのエラー率、応答速度の95%ile などが見たい →全てのTraceを元に計算した Metricsが欲しい(全部収集) 17

Slide 18

Slide 18 text

課題 Traceをデータソースとした可観測性の向上 いけるいける! Otel Collectorのパイプラインはすばらしい OTel CollectorのPoCを終えたころの私 18

Slide 19

Slide 19 text

課題 Traceをデータソースとした可観測性の向上 そんな簡単な話ではなかった 19

Slide 20

Slide 20 text

課題 Traceをデータソースとした可観測性の向上 そんな簡単な話ではなかった 本日は課題解消で苦労した部分と 解決の一例をお話します! 20

Slide 21

Slide 21 text

アジェンダ ● 自己紹介 ● OTel Collectorの概要 ● 課題(Traceの一部収集 and Metricsの全収集) ● 課題解消の難しさ ● 課題解消の一例(多段構成アプローチ) ● まとめ 21

Slide 22

Slide 22 text

課題解消の難しさ Traceをデータソースとした可観測性の向上 課題 (再掲) ● Trace ○ 全て収集しようとすると膨大な量 ○ 実際に見たいのは エラー または 応答遅延のみ → 問題のある Traceのみが欲しい (一部収集) ● Metrics (from Trace) ○ 各APIへのリクエストのエラー率、応答速度の95%ile などが見たい →全てのTraceを元に計算した Metricsが欲しい(全収集) 22

Slide 23

Slide 23 text

課題解消の難しさ > Trace Traceをデータソースとした可観測性の向上 課題 > Trace ● Trace ○ 全て収集しようとすると膨大な量 ○ 実際に見たいのは エラー または 応答遅延のみ → 問題のある Traceのみが欲しい (一部収集) Tail Sampling Processor 23

Slide 24

Slide 24 text

課題解消の難しさ > Trace Tail Sampling Processor ● Contribution Distro ● 一連のポリシーに基づいてサンプリング ● ポリシーの一例 ○ status_code != OK (異常なWeb応答) ○ latency > 1s (遅延したWeb応答) TailSampling 24

Slide 25

Slide 25 text

課題解消の難しさ > Trace Tail Sampling Processor ● Contribution Distro ● 一連のポリシーに基づいてサンプリング ● ポリシーの一例 ○ status_code != OK (異常なWeb応答) ○ latency > 1s (遅延したWeb応答) 各Traceと、それに紐づくスパンが全て揃わなければ知り得ない情報 各Traceは、同じTailSamplingProcessorに集約しなければならない TailSampling 25

Slide 26

Slide 26 text

課題解消の難しさ > Trace Tail Sampling Processor ● Contribution Distro ● 一連のポリシーに基づいてサンプリング ● ポリシーの一例 ○ status_code != OK (異常なWeb応答) ○ latency > 1s (遅延したWeb応答) ⇐こういうトレースを考える 26

Slide 27

Slide 27 text

課題解消の難しさ > Trace Tail Sampling Processor ● Contribution Distro ● 一連のポリシーに基づいてサンプリング ● ポリシーの一例 ○ status_code != OK (異常なWeb応答) ○ latency > 1s (遅延したWeb応答) ⇐こういう構成も考える 27

Slide 28

Slide 28 text

課題解消の難しさ > Trace Tail Sampling Processor ● Contribution Distro ● 一連のポリシーに基づいてサンプリング ● ポリシーの一例 ○ status_code != OK (異常なWeb応答) ○ latency > 1s (遅延したWeb応答) OTelCollectorで分散して受けようとすると、送信先の OTelCollectorに よってはOK/ERRORを誤認してしまう。 スケーラビリティ ←→ サンプリングのトレードオフ 28

Slide 29

Slide 29 text

課題解消の難しさ Traceをデータソースとした可観測性の向上 課題 (再掲) ● Trace ○ 全て収集しようとすると膨大な量 ○ 実際に見たいのは エラー または 応答遅延のみ → 問題のある Traceのみが欲しい (一部収集) ● Metrics (from Trace) ○ 各APIへのリクエストのエラー率、応答速度の95%ile などが見たい →全てのTraceを元に計算した Metricsが欲しい(全収集) 29

Slide 30

Slide 30 text

課題解消の難しさ > Metrics Traceをデータソースとした可観測性の向上 課題 > Trace ● Metrics (from Trace) ○ 各APIへのリクエストのエラー率、応答速度の95%ile などが見たい →全てのTraceを元に計算した Metricsが欲しい(全収集) Span Metrics Connector 30

Slide 31

Slide 31 text

課題解消の難しさ > Metrics Span Metrics Connector ● Contribution Distro ● スパンからメトリクスを集計する ● メトリクスの活用例 ○ 各WEB APIの応答時間の分布を可視化する ○ 各WEB APIのエラー率を算出する SpanMetrics 31

Slide 32

Slide 32 text

課題解消の難しさ > Metrics Span Metrics Connector ● Contribution Distro ● スパンからメトリクスを集計する ● メトリクスの活用例 ○ 各WEB APIの応答時間の分布を可視化する ○ 各WEB APIのエラー率を算出する だが、Traceのパイプラインには ProcesserにTailsamplingがいたはずだ・・・ TailSampling SpanMetrics 32

Slide 33

Slide 33 text

課題解消の難しさ > Metrics Span Metrics Connector ● Contribution Distro ● スパンからメトリクスを集計する ● メトリクスの活用例 ○ 各WEB APIの応答時間の分布を可視化する ○ 各WEB APIのエラー率を算出する TailSampling SpanMetrics ConnectorはProcessorよりも後段にある → Tailsamplingに正常なTraceを捨てられてしまう 33

Slide 34

Slide 34 text

課題解消の難しさ > 総括 OTelCollectorで全部実現は難しい? 34

Slide 35

Slide 35 text

アジェンダ ● 自己紹介 ● OTel Collectorの概要 ● 課題(Traceの一部収集 and Metricsの全収集) ● 課題解消の難しさ ● 課題解消の一例(多段構成アプローチ) ● まとめ 35

Slide 36

Slide 36 text

多段構成アプローチ 問題を整理してみる 36

Slide 37

Slide 37 text

多段構成アプローチ OTelCollector ①TailSampling TailSampling→SpanMetrics の順序が問題 ②SpanMetrics 37

Slide 38

Slide 38 text

多段構成アプローチ OTelCollector SpanMetrics→TailSampling の順序にしたい ①SpanMetrics ②TailSampling 38

Slide 39

Slide 39 text

多段構成アプローチ OTelCollector-a OTelCollector-b SpanMetrics→TailSampling の順序にしたい > 別々のOTelCollectorに処理をさせる・・? ①SpanMetrics ②TailSampling 39

Slide 40

Slide 40 text

多段構成アプローチ SpanMetrics TailSampling OTelCollector-a OTelCollector-b よさそう! 40 (remote write)

Slide 41

Slide 41 text

多段構成アプローチ いや、スケーラビリティはどうする? 41

Slide 42

Slide 42 text

多段構成アプローチ Tail Sampling Processor (再掲) ● Contribution Distro ● 一連のポリシーに基づいてサンプリング ● ポリシーの一例 ○ status_code != OK (異常なWeb応答) ○ latency > 1s (遅延したWeb応答) OTelCollectorで分散して受けようとすると、送信先の OTelCollectorに よってはOK/ERRORを誤認してしまう。 スケーラビリティ ←→ サンプリングのトレードオフ 42

Slide 43

Slide 43 text

多段構成アプローチ 救世主 Loadbalancing Exporter 43

Slide 44

Slide 44 text

多段構成アプローチ Loadbalancing Exporter ● Contribution Distro ● exporters.loadbalancing に送信先(複数)を設定 ● TraceID(等)をハッシュ化し、 一貫したバックエンドに送信する ○ Trace1のSpan(a,b,c)→ hosts.host-aへ ○ Trace2のSpan(x,y,z)→ hosts.host-bへ 44

Slide 45

Slide 45 text

多段構成アプローチ Loadbalancing Exporter ● Contribution Distro ● exporters.loadbalancing に送信先(複数)を設定 ● TraceID(等)をハッシュ化し、 一貫したバックエンドに送信する ○ Trace1のSpan(a,b,c)→ hosts.host-aへ ○ Trace2のSpan(x,y,z)→ hosts.host-bへ 条件(TraceID , hosts.*)が同じであれば、 どのOTelCollectorも同じバックエンドに Traceを送信してくれる! 45

Slide 46

Slide 46 text

多段構成アプローチ SpanMetrics TailSampling OTelCollector-a(1...n) OTelCollector-b(1...m) LoadBalancing 46 (remote write)

Slide 47

Slide 47 text

多段構成アプローチ 通信経路の補足 (kubernetes) 2段目のOTelCollectorは1つのpodごとに1つのserviceが必要です。 私は OTelCol-a,-bを一つの HelmChartで管理しています。 valuesにOTelCollector-bのホスト一覧を登録すると、 service , exportersが同時に更新されるように構成しています。 47

Slide 48

Slide 48 text

多段構成アプローチ 完成!! 48

Slide 49

Slide 49 text

多段構成アプローチ と思いきや、まだ発生する問題 (Metrics) 49

Slide 50

Slide 50 text

多段構成アプローチ SpanMetrics OTelCollector-a(1...n) (remote write) x10 x5 不一致 事象 ● 発生させたTraceの数と 検出されたTraceの数が 一致しない ( 基本減っている) 50

Slide 51

Slide 51 text

多段構成アプローチ SpanMetrics OTelCollector-a(1...n) (remote write) x10 x5 不一致 事象 ● 発生させたTraceの数と 検出されたTraceの数が 一致しない ( 基本減っている) 原因 ● Metricsのラベル被り OTelcol-a(1..n) が 同じラベルを使っていた ↓ Prometheusに同じもの としてカウントされ、 一部が無視されてしまった 51

Slide 52

Slide 52 text

多段構成アプローチ SpanMetrics OTelCollector-a(1...n) (remote write) x10 x10 一致! 事象 ● 発生させたTraceの数と 検出されたTraceの数が 一致しない ( 基本減っている) 原因 ● Metricsのラベル被り OTelcol-a(1..n) が 同じラベルを使っていた 解決 ● Processorでラベルを追加 ( OTelCollectorのPod名) Attributes 52

Slide 53

Slide 53 text

多段構成アプローチ SpanMetrics TailSampling OTelCollector-a(1...n) OTelCollector-b(1...m) LoadBalancing Attributes 53 (remote write)

Slide 54

Slide 54 text

多段構成アプローチ 今度こそ完成!! 54

Slide 55

Slide 55 text

アジェンダ ● 自己紹介 ● OTel Collectorの概要 ● 課題(Traceの一部収集 and Metricsの全収集) ● 課題解消の難しさ ● 課題解消の一例(多段構成アプローチ) ● まとめ 55

Slide 56

Slide 56 text

まとめ Traceをデータソースとした可観測性の向上 ● TailSamplingとSpanMetricsの両立 (スケーラビリティも担保) ○ OTelCollectorの2段構成で実現可 ○ 1段目では主にSpanMetricsを処理する ○ 2段目では主にTailSamplingを処理する I did it! 56

Slide 57

Slide 57 text

まとめ Traceをデータソースとした可観測性の向上 ● APPからTraceを受け、Trace , Metricsを出力 ● pipelines.traces ○ receivers {otlp} ○ processors {attributes/metrics , batch , …etc} ○ exporters {loadbalancing, spanmetrics} ● pipelines.metrics ○ receivers {spanmetrics} ○ processors {batch, …etc} ○ exporters {prometheusremotewrite} OTelCollector-a(1...n) ※1段目 57

Slide 58

Slide 58 text

まとめ Traceをデータソースとした可観測性の向上 ● OTelCollector-aからTraceを受け、TailSamplingしたTraceを出力 ● pipelines.traces ○ receivers {otlp} ○ processors {tail_sampling , batch , …etc} ○ exporters {otlphttp} OTelCollector-b(1...m) ※2段目 58

Slide 59

Slide 59 text

まとめ SpanMetrics TailSampling OTelCollector-a(1...n) OTelCollector-b(1...m) LoadBalancing Attributes 全体像(再掲) 59 (remote write)

Slide 60

Slide 60 text

まとめ 60 結論

Slide 61

Slide 61 text

まとめ OpenTelemetryは最高だぜ! 61

Slide 62

Slide 62 text

ご清聴ありがとうございました! 〜TailSamplingとSpanMetricsを両立させる〜 OpenTelemetry Meetup 2024-11 @gumamon33 62