以下の内容はhttps://ozaki25.hatenadiary.jp/entry/2024/11/20/210558より取得しました。


「OpenTelemetry Meetup 2024-11」に参加してきました

OTel Collector (多段構成)で TailsamplingとSpanMetricsを両立させる

Otel Collector

  • Otel Collector
    • ベンダーに依存しないデータ収集
    • プラガブルな構造
    • レシーバー/プロセッサー/エクスポーター
  • 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の導入
    • 元々は各工場からクラウドにfluentdであげてためる
      • ある程度中央管理
      • 全部送るとトラフィック厳しいからフィルタリングして送信
      • 受け取るpushgatewayの運用が大変
      • スケールアウトができなくてメモリ肥大化
      • 工場のNW瞬断などでfluentdのメモリ増大
    • OTelCollectorを中心にした構成に変更
      • やりとりがgRPCに統一された
      • メトリクスとログの収集が一本化できた
      • 標準仕様なのが拡張性もあったいい



以上の内容はhttps://ozaki25.hatenadiary.jp/entry/2024/11/20/210558より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14