OTel Collector (多段構成)で TailsamplingとSpanMetricsを両立させる
Otel Collector
- Otel Collector
- ベンダーに依存しないデータ収集
- プラガブルな構造
- レシーバー/プロセッサー/エクスポーター
- Traceをデータソースに可観測性向上
- 全部とるとtraceの量が膨大
- 問題のあるtraceだけほしい
- 全てのtraceを元にした統計情報が見たい
- エラー率とか応答速度とか
- 全部とるとtraceの量が膨大
- Tail Sampling Processor
- ポリシーに沿ってサンプリング
- statusが何とかlatencyが何秒以上とか
- traceに紐づくspanが全部ないとダメ
- 保存先をスケールさせると欠損してしまう
- ポリシーに沿ってサンプリング
- Span Metrics Connector
- spanからメトリクスを収集
- traceからコネクターを通じてメトリクスに流す
- traceはサンプリングしてるから全部のデータはとれない
- 1つの流れだけだと実現できない?
- OtelCollectorを2つ用意
- 1つ目からSpanMetricsに
- 2つ目のTraceでサンプリング
- LoadbalancingExporter
- TraceIDをハッシュ化して一貫した送信先に送れる
- これでスケールさせたことによる欠損を防げる
OpenTelemetryとSaaSの“良いとこ取り”で構築する柔軟なオブザーバビリティ基盤
- ymtdzzzさん
柔軟かつお手軽にOpenTelemetryを使う
- OtelとDatadogの事例
- サービスをまたいだ調査に時間がかかっていた
- ログが紐づけられない
- ボトルネックの特定に時間がかかる
- トレース周りを整えた
- goだとベンダー依存度高くのsdkを入れてとかやらないといけない - 利用サービス変えたらコスト高い - 計装の中で実装に係るところをOtelにした - zero-code計装可能ならそれで - プロトコルの差異 - Datadogは独自プロトコル
- サービスをまたいだ調査に時間がかかっていた
- ベンダーの壁の事例
- NewRelicの独自フォーマットで計装
- DBのコネクションプールを導入した
- pgcatのメトリクス収集が課題
- OtelCollectorを使って対応した
デンソー工場IoTにおける世界中からのテレメトリー収集の取り組み
- 澤田さん / 吉井さん / 中尾さん
デンソーのIoTプラットフォーム
- 工場のデータを吸い上げて可視化分析し改善サイクルを回してる
- 全世界に拠点があってそれぞれ共通化できるように
- 世界中の工場データを集約して解析する
- データロストは起きてはいけない
- データを処理できてるか受信できてるかを監視
- OTelCollectorの導入