Telemetry を OpenTelemetry と一緒に使用する

Telemetry と OpenTelemetry は、可観測性システムの関連するが異なる部分を解決します。 OpenTelemetry は、ベンダー中立の API、SDK、セマンティック規約、およびトレース、メトリック、ログ用のコレクターを提供します。 Telemetry は、専用の JSON アプリケーション結果、型付きテーブル、DataFusion SQL、ダッシュボード、およびアラートのための管理パスを提供します。

Telemetry は現在、OTLP インジェスト エンドポイントを提供していないため、OpenTelemetry コレクター バックエンドとして記述するべきではありません。を使用します。 OpenTelemetry コレクター トレース、メトリクス、ログにはOTLP互換の可観測性バックエンドを使用します. アプリケーションがSQL分析に適したビジネス上または運用上の成果に達したときは、別のTelemetryイベントを送信します.

各信号に 1 つのジョブを与える

チェックアウト トレースでは、データベースとプロバイダーのスパンを表示できます。あ checkout_completed イベントは、収益影響 SQL に必要な端末ステータス、安全なアカウント ID、プラン、金額カテゴリ、再試行回数、リリース、レイテンシーを保持できます。どちらも他方を複製する必要はありません。

承認された識別子と関連付けます

アプリケーション結果境界でアクティブな OpenTelemetry スパン コンテキストを読み取ります。

import { trace } from "@opentelemetry/api";

const spanContext = trace.getActiveSpan()?.spanContext();

await telemetry.log("checkout_completed", {
  checkout_id: checkoutId,
  status: "success",
  latency_ms: 684,
  trace_id: spanContext?.traceId,
  span_id: spanContext?.spanId,
  checkout_version: "v2",
  release: process.env.APP_RELEASE,
});

トレース ID とスパン ID を、チャートのディメンションではなくルックアップ フィールドとして扱います。システム間の相関関係をインシデント ワークフローの一部にする前に、トレース システムと Telemetry に互換性のあるアクセス境界と保持境界があることを確認してください。

スパン イベント、リソース属性、バゲッジ、プロンプト、リクエスト本文、またはスタック トレースを全体的にコピーしないでください。ホワイトリストを使用します。特に OpenTelemetry バゲージはサービス境界を越えて伝播する可能性があるため、分析にとって安全であると想定すべきではありません。

パイプラインを独立して操作する

OpenTelemetry コレクターは、サポートされている信号をバッチ処理、再試行、フィルター処理、およびエクスポートできます。 Telemetry SDK またはログ API には、独自の配信動作があります。両方のパイプラインを監視し、それらの障害モードの結合を回避します。

• 失敗した結果イベントの配信によって、それ以外の場合は成功したリクエストが終了してはなりません
• トレースのエクスポートが失敗しても、再帰的なイベント ログがトリガーされるべきではありません。
• 重要な監査または請求の結果には、明示的に耐久性のあるアプリケーション パスを使用する必要があります
• サンプリングの決定は信号固有である必要があります
• 導入検証では、相関性と独立した可用性の両方を確認する必要があります

の OpenTelemetry ロギング仕様 トレースとログのコンテキスト間の相関関係について説明します。を使用します。 OpenTelemetry 統合ガイド, ログ、メトリクス、トレース、イベント、そして 正規のワイドイベント 信頼できる最小の信号セットを選択します。