2023年のOpenTelemetry

 (bit.kevinslin.com)
2 ポイント 投稿者 GN⁺ 2023-08-29 | 1件のコメント | WhatsAppで共有
  • 2019年に OpenTracing と OpenCensus の統合から始まった OpenTelemetry は、4年でトレース・メトリクス・ログを網羅するオブザーバビリティ標準として定着した
  • 中核構造は 仕様 と 実装 に分かれており、ベンダー互換性を合わせる基準と実際の計測・収集ツールを併せて提供する
  • OTEL 仕様は 2020年にトレーシング、2021年にメトリクス、2023年にログが安定化し、すべてのシグナルが stable 状態に到達したが、ログ対応は SDK ごとにまだ差がある
  • OTLP と Collector は、オブザーバビリティデータを共通形式で送信・処理する基盤であり、Grafana や Datadog のようなベンダーエージェントもこれを実装している
  • OTEL は Collector、Semantic Conventions、OpAMP、OTTL、Demo まで範囲を広げ、ベンダー中立なオブザーバビリティの共通基盤へと拡張されている

OpenTelemetryの現在地

  • OpenTelemetry、略して OTEL は、2019年に OpenTracing と OpenCensus が統合されて始まった
  • 当初はトレーシング中心のプロジェクトだったが、統合後に対象範囲がオブザーバビリティ全体へ広がった
  • 目標は、組織が 高品質・汎用的・ポータブルなテレメトリ を提供できるよう支援することにある
  • 4年を経て、OTEL は次の基盤を備えるに至った
    • メトリクス、ログ、トレースに対する安定した標準
    • どのような環境でもテレメトリを受信・処理・エクスポートできる Collector
    • 主要言語でコード計測を支援する SDK
    • Semantic Conventions とエージェント管理に関する追加標準
  • 現在の OTEL は CNCF において Kubernetes に次いで活発なプロジェクトであり、主要なオブザーバビリティベンダー全体にコントリビューターが分布し、プロトコルもオブザーバビリティ提供者の間でほぼ普遍的に採用されている

仕様と実装に分かれるOTELの構成

  • OTEL は大きく 仕様 (specification) と 実装 (implementation) で構成される
  • 仕様は、テレメトリをキャプチャし、収集し、処理し、エクスポートする方法を定義する
    • ベンダーが OTEL と互換性を持つために従うべき共通標準に近い
  • 実装は、テレメトリデータを扱うクライアントライブラリとツールである
    • エンドユーザーがコードを計測する際に直接触れる部分である
  • プロジェクトの安定性は通常 シグナルごと に示される
    • OTEL におけるシグナルとは、メトリクス、ログ、トレースのようなテレメトリデータ型を指す
  • 主なサブプロジェクトは次のとおり
    • OpenTelemetry Specification
    • OpenTelemetry SDKs
    • OpenTelemetry Protocol
    • OpenTelemetry Collector
    • Open Agent Management Protocol
    • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

  • OpenTelemetry Specification は OTEL の基盤であり、他の OTEL 標準の土台となる API、SDK、データモデルを提供する
  • 安定化はシグナルごとに進められてきた
    • 2020年9月: トレーシング stable
    • 2021年11月: メトリクス stable
    • 2023年4月: ログ stable
  • 現在の OTEL 仕様は すべてのシグナルで stable 状態にある
  • ログシグナルは 2023年になってようやく安定化したため、まだ多くの OTEL SDK がログをサポートしていない

OpenTelemetry SDKと自動計測

  • OTEL SDK は、OTEL 仕様に基づくクライアント側の計測機能を提供する
  • 言語ごとの SDK には、メトリクス、ログ、トレースという各シグナルごとに成熟度の違いがある
  • 一部の SDK は、プログラミング言語に応じて 自動計測 (auto instrumentation) をサポートする
    • 自動計測とは、SDK がアプリケーションコードにシグナル、主としてトレースを自動注入し、手動計測の負担を減らす方式である
  • go や rust のようなコンパイル言語では自動計測は動作しない
  • ただし SDK の外側で eBPF や service mesh ベースのツールを使えば、自動トレース注入を得ることができる

OTLP 1.0とデータ転送標準

  • OTLP は、オブザーバビリティデータを転送するための 共通ワイヤープロトコル である
  • 公式の転送方式は2つある
  • この仕様は stable と見なされ、OTEL データを受信・処理・エクスポートするすべてのサービスで実装できる
  • OTLP は OpenTelemetry Collector が実装しており、Grafana や Datadog などのオブザーバビリティベンダーのエージェントも実装している

OpenTelemetry Collector 0.83.0

  • OTEL Collector は、オブザーバビリティデータを収集・変換・転送する ベンダー中立のエージェント である
  • Collector は次の構成要素から成る
    • receivers: 複数のソースから push/pull 方式でデータを受け取る
    • processors: 流通中のデータを変換、フィルタ、補強、派生する
    • exporters: データを downstream の宛先へ送る
    • connectors: receiver かつ exporter として動作し、複数のパイプラインをつなぐ
    • pipelines: receiver、0個以上の processor、exporter で構成されるチェーン
    • extensions: basic auth、health check のように、テレメトリ処理以外の機能を提供する
  • これらの構成要素は一体となって オブザーバビリティパイプライン として動作し、あらゆるソースからテレメトリを収集し、途中で処理したうえで、望む宛先へ送ることができる
  • Collector は2つのプロジェクトに分かれる
    • otel-collector: Collector の中核構成要素のみを含み、主として OTLP データ処理に直接関係するロジックを扱う
    • otel-collector-contrib: 大半のオブザーバビリティプロバイダー向けの exporter と receiver を含む統合コレクション
  • 執筆時点で otel-collector-contrib には 91個の receiver、48個の exporter、24個の processor が含まれている
  • エンドユーザーには、OpenTelemetry Collector Builder を使って、必要な構成要素だけを含む otel-collector-contrib のカスタムビルドを作成することが推奨される
  • AWS や Splunk のようなベンダーも独自の OTEL ディストリビューション を提供している

OpAMPとエージェントのリモート管理

  • OpAMP は、エージェントをリモート管理するためのネットワークプロトコルである
  • 2022年に OTEL に追加された比較的新しい標準で、エージェント群を制御する ベンダー中立の方式 を提供する
  • 管理対象は otel-collector インスタンスである場合もあれば、OpAMP を実装したベンダー専用エージェントである場合もある
  • OpAMP を使うと次の機能を有効化できる
    • 動的設定の配布
    • エージェントの更新
    • 資格情報の管理
  • 現在、OpAMP 仕様の Go 実装 は作業中の状態にある

Semantic Conventionsと追加プロジェクト

  • OTEL Semantic Conventions は、オブザーバビリティデータで使われる 共通属性セット を定義する
  • 適用範囲にはクラウドリソース、データベース、例外、システムなどが含まれる
  • Semantic Conventions は OTEL SDK で利用され、自動計測をサポートする SDK では自動的に適用される
  • 共通の意味体系により、異なるシグナル間の相関付けが可能になる
  • OTEL のその他の主要構成要素も個別に存在する
    • OpenTelemetry Transformation Language (OTTL): テレメトリのための共通変換言語であり、高い性能と柔軟性を備え、otel-collector-contrib で設計・実装されている
    • OTEL Demo: OTEL の機能と大半の言語 SDK を示すマイクロサービスベースのショッピングサイト

4年間の変化

  • OTEL は、競合していたトレーシング仕様の統合から出発し、オブザーバビリティの 業界標準 へと発展した
  • この4年間は、ベンダーやツール全体に共通基盤を築く期間だった

関連記事

1件のコメント

 
GN⁺ 2023-08-29
Hacker News のコメント

  • OpenTelemetry には 2 つの問題がある

    1. 正体がはっきりしない。セマンティクス標準なのか、プロトコルなのか、ファサードなのか、ライブラリなのか、どの抽象化レイヤーを提供するのか曖昧で、答えは「全部」に近い
    2. OpenTelemetry 側で実際にライブラリを計装したことがある人がいないように見える。計装する側がメトリクス、トレース、ログをどう使うべきか、3 つ全部を使うべきなのか 1 つだけでよいのかについての提案もない。2 年前に質問したが回答は得られなかった: https://github.com/open-telemetry/opentelemetry-specificatio...
    • 同意。流し台と、それに付いてくる家をまとめて渡されるようなもので、ドキュメントも薄く混乱しやすくなる
      同じように、デスクトップアプリで利用状況を把握するために簡単な ハートビート を実装したかったが、プロジェクト名を考えると驚くほどほぼ不可能だった。質問への反応も少なく、OpenTelemetry の計画は完全に取りやめた: https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
    • 同意。OpenTelemetry が推奨しているものの一部は、実際の SDK では不可能
      例えば、ヒストグラムを定義する場所の近くでバケットを定義できない。グローバルなエクスポーターのような場所に、ヒストグラム名からバケットへのマッピングになる「オーバーライド」一覧を渡す必要がある。メトリクスを出力するライブラリがあると非常に汚くなる: https://github.com/open-telemetry/opentelemetry-go/issues/38...
    • 良い質問だが、あまり重要だとは思わない。こうした質問は OpenTelemetry であれ他の独自システムであれ、オブザーバビリティ の領域では明確に答えるのが難しい
      先進的なオブザーバビリティ企業のウェブサイトを見ても、カスタム計装に関する記事は 4 ページ程度で、ごく基礎的な内容しか扱っていない。OTel が特別に遅れているわけではなく、答えはだいたい「場合による」に近い。経験が積み上がれば、初心者には混乱しやすいこうした部分も解きほぐせる
    • 必要だったのは JSON スキーマファイル 3 つ を保守する程度だった
    • 3 つ目の質問は 拡張性 があるかどうか

  • OpenTelemetry がとても好きで、ほぼすべてのスパンを追跡したい。どこかのベンダーを使っていたら、費用で破産していたと思う
    Java の自動計装でほとんど手間なく OpenTelemetry を導入し、セルフホストの ClickHouse に送り、1 日 7 億件以上のスパンを 100 ドルの EC2 に保存している: https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

    • 小さな個人プロジェクトで SigNoz を通じてトレース/ログ/メトリクスを ClickHouse に送っている。1 日 40 万〜80 万スパン程度で（https://i.imgur.com/s0J6Mzo.png）、単一の t4g.small で CPU は通常 11%、IOPS は 4% 程度
      トレースを 1 か月保持する前提で、signoz_index_v2 は 2,690 万行で 17.06GiB、trace_log は 1.23 億行で 2.64GiB、samples_v2 は 9.49 億行で 345MiB 程度と圧縮率が良い。推奨スペックの ClickHouse マシンを使っていればチューニング時間は減らせただろうが、今でもよく動いている
      欠点は、小さい sc1 ディスクの IOPS が 4 程度なので ClickHouse の起動に 5 分ほどかかることと、SigNoz UI は機能としては十分だが Datadog 並みの polish は期待しにくいこと
    • サンプリング率 は設定しつつ、エラーはすべて送っていることを確認すべき
      以前の職場では、エラーでないトレースの 5% だけを収集していた
    • 現実的には、多くの人は自前の ClickHouse ストレージ を運用したがらないし、すべてのエンジニアがコードのように SQL を効率よく扱えるわけでもない。それでもかなり格好いい構成だ
    • 設定に必要な手間が少なかった点も良い。Java 自動計装 + ClickHouse エクスポーター + Grafana ClickHouse プラグイン の組み合わせ

  • OpenTelemetry には大きく失望した。経験上、過剰に設計された混乱の塊であり、デフォルトの利用体験は非常にユーザー敵対的だ。
    自らは汎用のトレーシング／メトリクス／ログ形式であり、必要なあらゆるものにアダプターがあるプラグアンドプレイのライブラリ群のように宣伝しているが、実際には内部実装がかなり漏れ出していて、アダプターの品質も悪く、機能も多くない、中途半端なライブラリ群に近い。

    • 同意する。SDK を使うたびに、常識と直交するやり方で考えなければならない感じがする。期待どおりに動くものがなく、あらゆるものに不要な抽象化が 3 層ずつあり、裏口からアクセスしなければならない。
      多くの機能には、いつ、どこで、どれだけ、月の満ち欠けがどういう時に、木星が空に見える時に、文字列長がどの程度なら動くのか、といった条件が付いている。
      それでも、漏れ出す SDK API と半分だけ実装された機能群を無視すれば、置き換え可能性という約束はある程度守っている。OTel 以前はすべてが専用スタックだったが、今では標準 SDK 1 つに別のロギングバックエンドを差し込めば、おおむね動くことを期待できる。垂直統合スタックよりは劣るが、オブザーバビリティスタック全体を入れ替えなくても部分ごとの競争と進化を可能にするので、アーキテクチャの観点では部分的な勝利だ。
    • 同じ苦しみを経験したが、OpenAPI 仕様があるからより良いと主張する代替案も、使ってみると大差ない: https://github.com/openzipkin/zipkin-api-example
      例では swagger ツールで OpenAPI 仕様（https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...）をパースし、Go のグルーコードを自動生成したうえで、自動生成された関数を 1 つ呼んでトレースを記録する方法だけを示している。
      ドキュメントも他の例もまったくなく、このアプローチを実際に使っている人がいるのか疑問に思い、結局 REST 呼び出しでサービス API（https://zipkin.io/zipkin-api/#/）を直接使うことになった。OTel はつらいが、代替案も良いわけではない。SLO と SLI の測定がますます重要になっているだけに、この領域にもっと関心が集まってほしい。
    • だとすると、代替案を勧められるのか、それとも単に OTel を受け入れているのか気になる。
    • 具体的な経験と改善提案を挙げてもらえるとよい。

  • OTel 公式ライブラリは、まだ Web フロントエンドではうまく動作しない。たとえばデフォルト状態では、エラーをソースマップと関連付ける方法がない。
    OTel プロジェクトが配布している Web ブラウザコレクターは Zone.js を使い、ブラウザ内のほぼすべてをコンテキストとして横取りする。最近の Angular を使ったことがあれば、Zone.js が時にかなり苦痛で、グローバルをいじって予測しづらい動作を生み出し得ることがわかるはずだ。
    セッションリプレイのようなものに対する OTel 標準も知らない。Sentry、Rollbar、DataDog など多くのテレメトリプラットフォームはこれをサポートしている。バックエンドチームはかなり気に入っているようだし、一意のタグでシステム全体を追える span の境界横断的な性質は気に入っている。ただし生成されるペイロードは時に非常に冗長で、一部のロギングプラットフォームのほうがよりコンパクトだ。実務では大きな問題には感じていない。

    • ネイティブの Promise と async/await 環境では、Zone.js のようなものを正しく実装する方法は現状なさそうだ。
      自分で計測もしてみたが、エラーが起きやすく冗長だった。ブラウザにも https://nodejs.org/api/async_context.html#class-asynclocalst... のようなものが本当に必要だ。
    • ほとんどのプラットフォームで、Otel は良い計測ライブラリを作るための出発点に近かった。
      私たちのパッケージでは、Otel/Splunk ブラウザ SDK 実装の上に、セッションリプレイや改善された例外追跡などを載せている。残念ながら、こうしたものは標準提供にはほど遠い。それでも、フロントエンドセッションをバックエンドのトレース／ログと結び付けられるようになったことは、開発者体験を大きく変えたと思う: https://www.hyperdx.io/blog/browser-based-distributed-tracin...
    • Otel のこのドキュメントも見る価値がある: https://opentelemetry.io/docs/instrumentation/js/getting-sta...
      問題を完全に解決するわけではないが、出発点にはなる。
    • DataDog のフロントエンド計測である Real User Monitoring も、目に見えて洗練されているわけではない。Duplo ブロックを扱う程度の繊細さだ。
      フロントエンドトレーシングに少しでも着手した人がいるのか気になる。
    • Grafana Faro を見たことがあるか気になる。Grafana Agent に送るようにでき、Grafana Agent はオープンソースで、トレースを別の場所に保存できる。

  • 同僚数人と、もはやログは不要なのではないかという、やや突飛な考えを持った。ログメッセージの代わりにスパンイベントを付ければよい、というもの: https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
    そのうえで、スパンのタイトルと Jaeger の該当スパンへのリンクだけをログに残す形にする。個人プロジェクトでしか試していないが、かなり良い感触だった。ただ、Jaeger UI がこうした使い方をもっとよくサポートしてくれるとよいと思う。
    実際、その同僚たちはこのテーマで発表もしている。ドイツのハノーファー近辺にいるなら、https://javaforumnord.de/2023/programm/で “Nie wieder Log-Files!” を探すとよい。

    • プロジェクトがどれだけグリーンフィールドかにもよるが、特定の処理のタイムスタンプだけが必要で、継続時間が不要な場合でなければ、スパンイベントすら必要ないかもしれない。
      意味のあるすべての処理にスパンを使うのは、より強力な構造化ログを使うのに似ている。既存のログも併用しなければならない多くのシステムでは難しいが、十分にグリーンフィールドならおすすめできる。
    • 私もこのやり方を考えたことがあるが、シンプルなツールで何が起きているのかを大まかに把握できる点が良い。
      トレースを使うには、正しく動作しなければならないものがたくさんある。あるいは、単にまだ経験が足りず、ツールを怖く感じているだけかもしれない。
    • これは Stripe の Veneur プロジェクトのアイデアだった。スパン、ログ、メトリクスを同じ形式で扱い、必要に応じてカーディナリティを「自動的に」ロールアップする方式だ。
      数年前に発表を見たときはすごいと思ったが、SRE ではない開発者たちを説得するのは非常に難しそうだとも思った: https://github.com/stripe/veneur
    • トレースをどこかに送る必要すらない。プロセス内に保持し、そのインメモリのトレースデータの上に API を作ることもできる。
    • 同じ話を会社でもしている。かなり筋が通っていて、ログをほぼ完全になくすこともできると思う。

  • OpenTelemetry はマーケティング主導のプロジェクトであり、委員会方式で設計され、素朴で非効率に実装されていて、Fortune X00 の CTO たちに戦略ロードマップ文書のチェックボックスを埋めさせることを主目的にしているように見える。
    選択肢のある人が使うべきものではない。

    • このスレッドの他のコメントはおおむね好意的か非常に肯定的なので、具体的に何が良くないのか、もう少し詳しく聞きたい。
    • highlight.io の創業者として、利用者の立場では OTEL に多くの価値を見いだした。複数の顧客のために言語サポートを拡張するのに使ったし、コミュニティも非常に受け入れに前向きだった。
      私たちが出した変更の例はここにある: https://github.com/open-telemetry/opentelemetry-js/pull/4049
      なぜ誰も使うべきではないと考えるのか、その理由を共有してもらえるとうれしい。
    • その評価は当たっていないと思う。むしろ「オープンソースソフトウェアが Prometheus メトリクスや Jaeger トレースを出力しているが、我々はその代替となるプロプライエタリ製品を売りたいし、すべてのプロジェクトにパッチを送るのは避けたい」という話に近く見える。
      Datadog は実際、OSS プロジェクトに Datadog サポートを追加する人員を大規模に投入していた。馴染みのないコードベースに飛び込むのは強力な能力なので、キャリア初期としてはかなり良かったのかもしれない。
      OTel はオープンソースプロジェクトに抽象化レイヤーを使わせることで、ユーザーがセルフホストの代わりに購入できるようにする。心から気に入っているわけではないが、社外の人が運用するサービスなら、今では OTel を検討すると思う。あるユーザーが Datadog を使いたい場合に、私たちがそれを妨げずに済むからだ。
      ごく初期の OTel を使ったときは、Go API が非常に非効率でがっかりした。カウンターを増やすのに context.Context が必要だったり、Prometheus にエクスポートするときにヒストグラムのバケットを設定する方法がなかったりと、抽象化も漏れていた。今はおそらく修正されていると思う。
    • 厳しすぎる。データモデルは正しい方向への前進だと思う。
      プロセッサもかなり有能で、レシーバーとエクスポーターの contrib 集合も全体として悪くない。最良の解決策だと言うつもりはなく、ユースケース次第ではあるが、ここまで強い批判は妥当には見えない。ちなみに私は fluent-bit のメンテナンスチームに属している。
    • サービスに OTLP で話させ、アプリケーション設定を OTEL コレクターへデータを送るだけに単純化できる点は素晴らしい。
      運用の観点では、開発者がコードにどんなオブザーバビリティを追加しても中央でフィルタリングを強制でき、アプリケーションが通信する中央の入口も1つだけで済む。
      すべてが OTLP を出力するので、新しいバックエンドに移りたいときは YAML ファイルを変えるだけでよく、新しいロギングバックエンドをサポートするためにアプリケーションを書き直す必要がない。ベンダー別のロギングライブラリを使っていた昔のやり方に戻るくらいなら、欠点があっても10回中10回 OTEL を使い続ける。

  • このブログの購読ポップアップが本当に嫌いだ。x ボタンがないので、メールアドレスを渡さずに閉じられることがまったく明確ではない。
    購読ボタンの下に、非常に直感的でない “continue reading” があるのだが、それが機能するとは思わなかったし、外側をクリックしても閉じなかった。こういうものは改善されるべきだ。
    OpenTelemetry については、データを Datadog に送るときに必要な機能をすべて提供しているのか、以前から試してみたいと思っていた。ただ、基本機能以外に依然として Datadog エージェントが必要なら、管理し教育しなければならないものがさらに1つ増えることになるので、ためらいがある。
    実際に Datadog につないでみた人がいるのか気になる。目標は必ずしも Datadog に縛られ続けることではないが、今のアラートやログのかなりの部分がそこにあるので、まず OpenTelemetry に切り替えれば、理論上は後で別のものに移れるのではないかと思う。

    • そのポップアップは medium.com 側の機能だ。非常にうっとうしいという点には同意する。
    • 個人的にはアンケートのほうがもっとひどかった。意見を聞かれたので選択肢を1つ押したら、全画面のアカウント作成画面でお返しされた。
      戻るを押したら HN に戻ってしまった。

  • 収益の流れを人件費、インフラ、ライセンス費用の面で大きく削らないフロントエンドがまだあるのか気になる
    秒間2,000件以上のリクエストを受けていると、ログを保持するだけでも高い

    • まだやっていないなら、トレースサンプリングを勧める。Datadog APMには安価な構成がなく、あまり良い印象ではなかった
      私たちは自前のJaegerスタックを0.1%サンプリングで運用しており、Datadog APMと比べるとコストは無視できるレベル
      メトリクスとログにはサンプリングがあまり有用ではなく、良い答えはない。Datadogの粗利率が80%なら、支払額のうちインフラ費用は多くても20%で、人件費がその80%より少ないなら、オープンソーススタックを自分たちで運用すれば大幅にコストを削減できる。Datadogを使っていても、3か月ごとに利用量を減らすプロジェクトをやっているので、結局ずっと面倒を見る必要があるのは同じ
    • 答えはサンプリング。成功リクエストは1%だけサンプリングし、エラーはすべて収集すればよい
      コストも問題だが、オブザーバビリティがサービスに思った以上に重くのしかかることに驚くかもしれない。CPUをかなり使う
    • 「大きく」の基準を決める必要がある。以前の会社ではトレースをCassandraにルーティングし、AWS Elasticsearchドメインに保存して、Jaegerで可視化していた
      遅いクエリを見つける基本的なレポートを作るために、Elasticsearchクエリもいくつか書いた。OTEL/Jaegerのチュートリアルに従えば、かなり標準的な構成
      トレースは秒間数百件程度で、ダウンサンプリングせずにすべて収集していた。保持期間は7日に設定でき、私が去る時点では実際の最適化はほとんどなかった。月額コストは数十〜数百ドルくらいだったと思う
      コンテナに設定できる環境変数で、トレーシングサンプラーの動作を定義できる。ドキュメントのOTEL_TRACES_SAMPLERを見ればよい: https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
    • ほとんどのオブザーバビリティベンダーは、今ではOTELをサポートしている。私が参加しているOSSプロジェクトもOTELの収集をサポートしている: https://github.com/grafana/tempo/
    • なぜダウンボートされているのか分からない。私たちにも同じ痛みがあり、ただし規模は秒間50万リクエスト
      現在Datadogを使っているが、誰もが高すぎることは分かっている

  • このスレッドの大半は、OpenTelemetryでメトリクス/ログをセルフホストのコレクター作業に送る話をしている
    ClickHouseのような複数のコレクターツールがサポートする標準ライブラリを使うこと自体も有用だが、もう一つの利点は、仕様によってシステム境界を越えてトレースIDを渡せること
    自分たちと依存先の双方がOpenTelemetry仕様を実装していれば、処理の流れの中で何が起きたのかを細かく示すスパンを得られる。たとえば、ページ読み込みが長い原因がデータベースのディスクページ読み込みだったのか、クラウドサービスのメタデータプレーンのスパンが高レイテンシの原因だったのかが分かる

  • OpenTelemetryの進展にはとても満足している。数年前に導入を推し進めたとき、開発者たちは新しくて聞いたことがないと言ってためらっていたが、1年前に改めて見たときにはOpenTelemetryが私たちのシステムのあちこちにあり、私たちが使っているログ/トレーシングベンダーもそちらへ移行中だった