OpenTelemetry: 観測可能なオプションの海をナビゲートするヒント

OpenTelemetryは、柔軟でベンダーニュートラルな観測可能性パイプラインを作るが、話にはまだ続きがある。

オブザーバビリティは奥が深く、ウサギの穴になりやすいテーマです。Momentoでは、顧客のトラフィックをモニターできる効率的で耐久性のあるオブザーバビリティ・システムを構築し、軽快な動きを維持したいと考えています。このブログでは、OpenTelemetry (OTel)-(トレース、メトリクス、ロギングのためのベンダーニュートラルなオブザーバビリティ標準を定義しています)-を使ったMomento自身の旅と、なぜそれがあなたに合うか合わないかを説明します。‍

私のOpenTelemetryの経験は、LightstepでCEOのBen Sigelmanと一緒に働いていた2017年のOpenTracingから始まりました。彼は、オープンソースで統一されたトレーシング標準を提供する目的でOpenTracingを共同作成しました。その後、OpenTracingはOpenCensus(Google)と統合され、OpenTelemetryとなりました。この5年間でコミュニティがどれだけ成長し、多くの企業や個人がこのプロジェクトに積極的に貢献しているのを見ると、本当にやりがいを感じます。

初心者の方にとって、OpenTelemetryのエコシステムは圧倒されるかもしれません-ドキュメントはたくさんありますが、開発者はただコーディングを始めたいだけなのです!ここでは、OpenTelemetry の様々なコンポーネントの概要を簡単に説明します。全部使うことも、一部だけ使うこともできます。非常にフレキシブルに作られており、ミックス&マッチやプラグ&プレイをサポートしています:

OpenTelemetry SDKs

OpenTelemetry SDK は、開発者がアプリケーションをメトリクス、トレース、ログで計測するために使用するライブラリです。OpenTelemetry 仕様は、この計測を行うための標準化された API インターフェイスを定義しています。そして、実際の実装は、仕様(Java、Python、GoLangなど)に従って、サポートされているSDKの各言語で実行されます。これはオープンソースでコミュニティ主導のプロジェクトなので、SDKの安定性は異なる言語フレームワークによって異なることを忘れないでください。良いニュースは、特に必要なものがあれば、いつでも自分でコードベースに貢献できることです。興味のあるSDKの現在の安定性は、公式のOpenTelemetryステータスページでチェックすることもできます。

OpenTelemetry Protocol (OTLP)

一旦アプリケーションがOTel SDKを使用してインスツルメンテーションされると、OpenTelemetry Protocol(OTLP)と呼ばれる標準的なワイヤーフォーマットを使用して、これらのアプリケーションによって観測可能性データが発行されます。これは、エンコーディング、トランスポート、配信メカニズムなどの詳細を定義します。現在、OTLPはプロトコル・バッファ・スキーマ(protobuf)を使用し、gRPCとHTTP1.1(JSON over HTTP)の両方のトランスポートをサポートしています。

OpenTelemetry Collector

OpenTelemetry Collector は、テレメトリ・データを受信、処理、エクスポートするために実行できるオプションの中間エージェントです。添付の図では、サンプル・アプリケーションは OTLP 経由でテレメトリ・データを OTel Collector に送信します。OTel Collector は、様々な観測ベンダにエクスポートする前に、バッチ処理やレート制限などの中間処理を実行します。この中間エージェントを持つことは有用ですが、スタックに追加のインフラと複雑なレイヤーを追加することになります。

それで…OpenTelemetryは私のためにあるのだろうか?

OpenTelemetry の最大の利点は、その柔軟性とベンダー中立性です。ここ数年の OpenTelemetry コミュニティの急速な拡大により、Splunk、Datadog、Dynatrace、Lightstep など、多くの観測可能性ベンダーが OTel のネイティブサポートを発表しています。OpenTelemetryを採用することで、”ベンダーのロックインがない “ことが望まれます。世界は超ダイナミックで、より多くの機能と低価格で新しいプレーヤーが現れ続けています。より機敏になり、選択肢を広げておくことは有効でしょう。しかしながら、もしあなたが、既存の観測可能性ベンダーにコミットしているのであれば、OpenTelemetryを採用する付加価値はほとんどありません。ベンダー固有のライブラリーに集中し、そのベンダーが提供する公式の観測可能性パイプラインを使うべきです。

Momento では、選択肢を広げておくために OpenTelemetry を採用しました。私たちは、特定のベンダーに縛られることなく、迅速に行動し、観測可能性を実現したかったのです。私たちは、選択肢を評価する時間が欲しかったのですが、OpenTelemetryは、私たちの選択肢を双方向のドアにしてくれました。OpenTelemetry SDK と OpenTelemetry Collector をセットアップした後は、OTel データを全てのベンダーにブロードキャストすることで、複数のベンダーを同時に評価することが簡単になりました。我々の開発者は、複数の観測システムを同時に使用し、ユーザー・エクスペリエンスを並べて比較することができます。これにより、現在の予算とニーズに最も適したベンダーを選ぶことができました。

とはいえ、OpenTelemetry のエコシステムはまだ若く、常に進化しています。あなたのスタックにOpenTelemetryを採用するかどうかを決定する際には、エコシステムのダイナミックな性質を考慮に入れるべきです。コミュニティはとても親切で活発なので、OTel のコントリビューターの今後の計画を必ずチェックしてください!

Momentoにとって、可用性とパフォーマンスの高い水準を維持するための観測可能性は第一級市民です。OTelが提供する柔軟性を基盤に、私たちはお客様に広範な可視性を提供し、お客様が独自の観測可能性目標を達成できるよう支援します。運用のオーバーヘッドがなく、強力でパフォーマンスの高いキャッシュが必要な場合は、今すぐMomentoを無料でお試しください。