セルフホスト型ソフトウェアやSaaSプロダクトのユーザーは、コンプライアンス遵守、コスト削減、データの一元化などのために、ログ、トレース、メトリクスを自分で選んだオブザーバビリティスタックに送信したいというニーズが高まっています。プロダクトが組み込みダッシュボードにロックインしたり、特定ベンダーへのエクスポートに制限をかけたりすると、不要な摩擦が生じます。OTelネイティブアプローチでは、標準のOpenTelemetry Protocol（OTLP）を介して任意のOpenTelemetry互換エンドポイントにテレメトリーをプッシュするようにプロダクトを設計することで、カスタムアダプターを各システムごとに用意することなく、ユーザーが好みのバックエンドを自由に選べるようになります。
この画像はOTelネイティブアプローチの導入をサポートし、OTLPがカスタムアダプターを必要とせずにユーザーが任意のオブザーバビリティバックエンドを選べることを示しています。
堅実なOTelネイティブのエクスポートストーリーは、次の4つの重要な特性に依存します：ベンダーニュートラル（ユーザーは任意のOTel互換コレクターまたはバックエンドを指すことができる）、深いカスタム開発不要（標準のOTel SDKとOTLPを介して統合できる）、豊富なコンテキストの保持（メタデータ、タイムスタンプ、トレース／スパンの相関関係が保持される）、セマンティックコンベンションへの準拠によりデータが標準化され、バックエンド間で解釈可能であること。OpenTelemetryは4種類のシグナルタイプを定義しています：ログ（イベントログとアプリケーションログ）、トレース（分散トレースとスパン）、メトリクス（カウンター、ゲージ、ヒストグラム）、プロファイル（リソース使用サンプル、現在パブリックアルファ）。テレメトリーを生成するシステムを誰が実行するかによって実装方法が異なります：セルフホストソフトウェアの場合、プロダクトはOpenTelemetryでインストルメントされ、環境変数や設定ファイルを通じてOTLPエンドポイントの構成フラグを公開します（KumaやKeycloakが例）。クラウドプラットフォームの場合、プロバイダーは「テレメトリードレイン」や「オブザーバビリティデスティネーション」などの機能を提供し、ユーザーのワークロードやファーストパーティサービスからテレメトリーを収集して、顧客が定義したOTLPエンドポイントに転送します（Cloudflare WorkersやHerokuが例）。
OTLPを使用したプッシュベースのエクスポートは、ニアリアルタイムのデータ配信、ユーザーにポーリングパイプラインの構築とメンテナンスの運用負荷をかけないこと、ログ記録を親トレースIDにリンクするようなコンテキスト関係を自動的に保持できる点で、従来のポーリングAPIよりも好まれます。このモデルはログ、トレース、メトリクスに対してうまく機能しますが、一部の実装にはまだギャップがあります：Cloudflare Workersはまだメトリクスのエクスポートをサポートしておらず、Keycloakのログエクスポートはプレビュー段階でデフォルトでは無効になっています。これらの制約は、すべてのシグナルにわたって完全なOTelネイティブサポートを達成するには継続的な作業が必要であることを示していますが、コアパターンは将来にわたってベンダーニュートラルな基盤を提供し、ユーザーが選ぶ任意のオブザーバビリティスタックで機能します。