Dan Gomez Blanco(New Relic)の寄稿による記事です。セルフホスト型ソフトウェアや SaaS 製品を開発している場合、ユーザーはいずれ自分たちのオブザーバビリティ基盤へログ、トレース、メトリクスを送信したいと求めるようになります。組み込みのダッシュボードに閉じ込めたり、エクスポート先を特定のベンダーに限定したりすると、不必要な摩擦が生まれます。代わりに、Open Telemetry(OTel)互換の任意のバックエンドへのエクスポートをサポートすることは、ベンダー中立で将来性のあるアプローチであり、ユーザーが自分のオブザーバビリティ基盤を自由に選べるようにします。
この記事では、ユーザーが必要なときにログ、トレース、メトリクスを OTel バックエンドへエクスポートできるように製品を設計する方法を説明します。Open Telemetry は、標準の Open Telemetry Protocol(OTLP)で送信される 4 種類のシグナルを定義しています。ログ(タイムスタンプとメタデータを持つイベント記録、リクエスト/アクセスログ、アプリケーションログ)、トレース(サービス間のリクエストの流れを確認し、ログと関連付けられる分散トレースとスパン)、メトリクス(リクエスト率、レイテンシ、エラー率などのカウンター、ゲージ、ヒストグラム)、プロファイル(実行中にアプリケーションがどこでリソースを消費しているかを示すサンプル)です。3 つのシグナルすべてに共通するエクスポートの流れは、ユーザーが OTLP エンドポイントを設定し、そこへテレメトリを送信できるようにすることです。製品が生成するデータに応じて、1 つ、2 つ、あるいは 3 つすべてのシグナルをサポートできます。OTel エクスポートに対応する多くのプラットフォームは少なくともトレースとログをサポートしており、メトリクスをサポートする製品も増えています。最初から 3 つすべてを想定して設計しておけば、後から改修する手間を避けられます。
優れたエクスポート戦略には、サポートする各シグナルについて明確な特性があります。ベンダー中立であること、大がかりなカスタム開発を必要としないこと、豊富なコンテキストを保持すること、セマンティック規約をサポートすることです。考慮すべき文脈は 2 つあります。製品はどこで動作するのか、という点です。セルフホスト型ソフトウェアの場合は、Open Telemetry で製品を計装し、顧客が環境変数や設定ファイルでエンドポイントを設定できるようにします。クラウドプラットフォームの場合は、エクスポートを管理するためのプラットフォーム機能を追加します。Keycloak や Kuma がその例です。
出典: Hacker News · 要約：HeadlinesBriefing