OpenTelemetryの中核的な強みの 1 つは、テレメトリーデータ パイプラインに対する比類のない制御を提供する豊富なツール セットです。 このコントロールはNew Relicの使用量ベースの価格設定モデルを補完します。
このページでは、 OpenTelemetry New Relicと併用する場合にデータ量に影響するさまざまな概念と、テレメトリデータ パイプラインを管理するために使用できるツールやパターンについて説明します。 リソース、トレース、メトリクス、ログのデータ量に寄与する主要な概念について説明するセクションに分かれており、その後に量の管理に役立つツールのカタログが続きます。
重要な概念: リソース
OTLP は、すべての信号にわたって同様の階層型メッセージ構造を定義し、レコード間で情報を共有することでプロトコル レベルでの繰り返しを回避します。
- 各エクスポート要求には多数の
Resource{SignalRecord}が含まれています - 各
Resource{SignalRecord}には多数のScope{SignalRecord}が含まれています - 各
Scope{SignalRecord}には多数の{SignalRecord}が含まれています {SignalRecord}はSpan、Metric、そしてLogRecord
この階層構造は、New Relic エンドポイントに送信されるときに平坦化され、各リソース属性は個別のSpan 、 Metric 、およびLogレコードに非正規化されます。 New Relic で OpenTelemetry データがどのように処理されるかの詳細については、次のページを参照してください。
ほとんどの OpenTelemetry 言語実装では、環境で検出された情報に基づいてリソース属性を提供するリソース検出器を備えたパッケージが提供されます。 これらの属性は非常に便利ですが、必要以上の情報が含まれる可能性があります。
詳細については、以下を参照してください。
重要な概念: トレース
サンプリング
サンプリングは、どのスパンをオブザーバビリティ バックエンドにエクスポートするかを制御するプロセスです。 トレース データは非常に価値のあるインサイトを提供しますが、チェックを怠るとハード ドライブ (そして請求書も!) がすぐにいっぱいになってしまいます。
デフォルトでは、OpenTelemetry SDK はParentBased(root=AlwaysOn)サンプラーを使用します。 ParentBasedサンプラーは、親スパンが存在するかどうか、その親が現在のプロセスに対してローカルかリモートか、およびその親がサンプリングされているかどうかに基づいて、さまざまな構成可能なサンプラーに委任します。 デフォルトのParentBased(root=AlwaysOn)サンプラーは、次のいずれかが当てはまる場合にスパンをサンプリングします。
- 親スパンはありません（つまり、このスパンはルートです）
- 親がローカルかリモートかに関係なく、親がサンプリングされます。
つまり、親がサンプリングされていない限り、スパンをサンプリングします。
これは、ユーザーが最初にサンプリングの概念を意識する必要なく、インストゥルメンテーションをインストールしてトレース データを確認できるため、 OpenTelemetryコミュニティにとって適切なデフォルトです。 ただし、 OpenTelemetryの実稼働デプロイメントには注意が必要です。 このポリシーでは、下流システムが準拠すべきインテリジェントなサンプリング決定を行う上流コンポーネントまたはゲートウェイがない限り、すべてのスパンがサンプリングされます。
代替案については、以下を参照してください。
スパンデータ
OpenTelemetry スパンは、さまざまなトップレベル フィールド (名前、種類など)、属性、スパン イベント、およびスパン リンクで構成されます。 スパンの添付データの量は、New Relic のデータ量に直接対応します。
インストゥルメンテーション ライブラリは、多くの場合、セマンティック規約に従って、どの情報をスパンに添付するかを決定します。 例外が発生すると、その情報は例外スパン イベントの形式でスパンに添付されることがよくあります。 このイベントには、例外メッセージ、タイプ、およびスタックトレースを表すプロパティが含まれており、言語やアプリケーションによっては、数千バイトで構成される場合があります。 例外が頻繁に発生する場合、スタックトレースによりNew Relicで大量のデータが生成される可能性があります。
スパン データの管理戦略については、以下を参照してください。
トレーサー
計測スコープは、テレメトリーが関連付けられたアプリケーション コードの論理単位です。 各インストゥルメンテーション ライブラリには 1 つ (または複数) の固有のスコープと、対応するトレーサーがあります。
高い値のトレース データを生成しないトレーサーは、トレースを中断することなく選択的に無効にすることができます。
詳細については、 「SDK のトレーサー、メーター、ロガーの無効化」を参照してください。
重要な概念: メトリクス
収集間隔
メトリクスは個々の測定値を集計し、集計された状態をプロセス外にエクスポートします。 OTLP などのプッシュベースのプロトコルの場合、エクスポートは構成可能な間隔で行われ、デフォルトでは60sになります。 この間隔は New Relic のデータ量に直接対応します。 間隔を30sに短縮すると、データ量は約 2 倍になります。 間隔を120sに増やすと、データ量は約半分に削減されます。
60sのデフォルト間隔は、データ量とオブザーバビリティのラグの間のトレードオフのバランスをとるため、適切なデフォルトです。 間隔を長くしすぎると、重要な信号が New Relic ダッシュボードやアラートに到達するまでに遅延が発生し、問題が悪化する可能性があります。
詳細については、 「SDK の定期エクスポート Metriks Reader exportIntervalMillisを参照してください。
基数
メトリクスが集約する測定値は、一連のプロパティに関連付けられます。 異なる属性セットの数をカーディナリティと呼びます。 カーディナリティは、測定値の集計状態を維持するために必要なアプリケーション メモリの量、各収集間隔でエクスポートされるデータの量、および New Relic のデータ量を決定するため重要です。
カーディナリティが高すぎる場合は、カーディナリティに寄与する属性を省略することを検討してください。 検査を制御すると、各測定で記録する特性が少なくなる可能性があります。 ただし、多くの場合、インストゥルメンテーションは直接構成できません。
メトリクスからプロパティを削除する方法の詳細については、以下を参照してください。
集約の時間性
OpenTelemetryでは、集約時間の概念によって、集約された測定値の状態が各収集後にリセットされるかどうかが定義されます。 集約の一時性が累積的である場合、集約状態はリセットされず、メトリクスはアプリケーションの開始以来の累積値を表します。 集計のテンポラリティーがデルタの場合、集計状態は各コレクションの後にリセットされ、メトリックは前回のコレクションからの差異を表します。
New RelicのOTLP エンドポイントは累積集約時間性をサポートしていますが、 New Relicメトリクス アーキテクチャーはデルタ メトリクス システムです。 デフォルトの累積設定を使用すると、通常、SDK からのメモリ使用量が増加し、データの取り込み量が多くなります。 累積集計からデルタ集計への変換は、差異を計算するために各時系列の前のポイントを保持する必要があるため、ステートフル アクティビティです。 このため、SDK で集約の一時性を構成することが最善です。これにより、アプリケーションのメモリが節約され、下流の余分な複雑さが回避されます。
詳細については、以下を参照してください。
メーターとインストゥルメントが施された
インストゥルメンテーション スコープは、テレメトリーが関連付けられたアプリケーション コードの論理単位です。 各インストゥルメンテーション ライブラリには 1 つ (または複数) の固有のスコープと対応するメーターがあり、各メーターには 1 つまたは複数のインストゥルメントが作成されます。
貴重なメトリクス データを提供しないメーターまたはインストゥルメントは、選択的に無効にすることができます。
詳細については、以下を参照してください。
重要な概念: ログ
ログレコードデータ
OpenTelemetry ログ レコードは、さまざまなトップレベル フィールド (タイムスタンプ、重大度、本文など) と属性で構成されます。 ログ レコードに添付されるデータの量は、New Relic のデータ量に直接対応します。
インストゥルメンテーション ライブラリ ( ブリッジログ OpenTelemetryOpenTelemetryAPIはログ から にログをブリッジすることを目的としているため、 ログ空間では ログ アペンダーAPI OpenTelemetryと呼ばれます) は、多くの場合、 セマンティック規則 に従って、ログ レコードにどの情報を添付するかを決定します。
ログ データの管理に関する戦略については、以下を参照してください。
ロガー
計測スコープは、テレメトリーが関連付けられたアプリケーション コードの論理単位です。 OpenTelemetryログの場合、各個別のロガー ( OpenTelemetryブリッジログAPIを使用してログ アペンダーによってブリッジされる) には、固有の監視スコープがあります。
高価値のログ データを生成しないロガーは、選択的に無効にすることができます。
詳細については、以下を参照してください。
パイプライン管理ツールカタログ
次の表には、OpenTelemetry データ パイプラインを管理するためのさまざまな便利なツールがリストされています。 OpenTelemetry は高度に拡張可能なエコシステムであることに注意してください。 これらのツールが十分でない場合は、他のツールを利用できるか、言語 SDK またはコレクター用のカスタム拡張ロジックを記述して目標を達成できる可能性があります。
名前 | コレクターか SDK か? | 説明 |
|---|---|---|
開発キット | OpenTelemetry 言語 SDK は、環境に基づいてリソース属性を提供する検出器をパッケージ化します。 これらの一部のセットは、OpenTelemetry Javaagent などの ゼロコード計測 オプションによってデフォルトで有効になっていることがよくあります。リソース検出器を有効/無効にする方法の詳細については、 を参照してください。 | |
開発キット | ルートが bash
| |
開発キット | OpenTelemetry トレース SDK を使用すると、スパン制限を構成して、属性の最大長と数量、スパン イベントの最大数、およびスパン リンクの最大数を指定できます。 スパン制限は SDK bash New Relic OTLP エンドポイントの属性制限に合わせてスパン制限を設定します。 | |
開発キット | OpenTelemetry ログ SDK を使用すると、スパン制限を構成して、属性の最大長と数を指定できます。 LogRecord の制限は SDK bash ログ レコードの制限を、New Relic OTLP エンドポイントの属性制限に合わせて設定します。 | |
SDK は 、 、 無効にします | 開発キット | OpenTelemetry SDK は、トレーサー、メーター、ロガーをそれぞれ構成および無効化するために
、
、
を定義します。 このコンセプトは現在開発中であり、すべての言語実装で利用できるわけではありません。 個々の を参照し、言語のメンテナーに連絡してステータスを確認してください。 |
開発キット | OpenTelemetryメトリクス SDK を使用すると、定期的にエクスポートするメトリクス リーダーの収集間隔を設定できます。 間隔はプログラムで設定できますが、環境変数を使用するのが一般的です。 bash 収集間隔を 60 秒 (60k ミリ秒) に設定します。 これはデフォルトですが、必要に応じて調整できます。 | |
開発キット | OpenTelemetryメトリクス SDK を使用すると、保持するプロパティ キーのセット、集計タイプ、メトリクスの削除などのさまざまなオプションを指定するビューを使用して
を構成できます。 通常、ビューはプログラムによって構成されます。 ご使用の言語での代替手段を確認するには、個々の を参照してください。 たとえば、OpenTelemetry Java では、 でビューを構成するための実験的なサポートがあります。 | |
開発キット | OpenTelemetryメトリクス SDK を使用すると、OTLP エクスポーターに対して集約の一時性を構成できます。 この時間性はプログラムで設定できますが、環境変数を使用するのが一般的です。 bash New Relic OTLP エンドポイントの設定に合わせて、OTLP メトリクス エクスポーターの集約時間性をデルタに設定します。 | |
開発キット | OpenTelemetryログ ブリッジAPI 、ログAPIからOpenTelemetryにログをブリッジするログ アペンダーで使用するように設計されています。 これらのログ OpenTelemetryアペンダは、 Java エージェントなどの ゼロコード計測 オプションを使用して自動的にインストールされる場合もあれば、手動のインストール手順が必要な場合もあります。多くの場合、どのログとどのデータをOpenTelemetryにブリッジするかを指定する設定オプションがあります。 さらに、多くの場合、ブリッジされるログAPIを構成して、どのログ (重大度またはロガー名に基づいて) をログ アペンダーに渡すかを指定することができます。 詳細については、個々の を参照してください。 | |
コレクター | コレクター フィルター プロセッサを使用すると、オブザーバビリティ パイプラインからスパン、メトリクス、ログ レコードをフィルターで除外できます。 スパンの場合には、単純なテール サンプラーとして機能し、完了したスパンに対して動作しますが、完全なトレースにはアクセスできません (注: これにより、トレースが壊れる可能性があります)。 メトリクスの場合、価値の高くないメトリクスやシリーズをドロップするために使用できます。 ログの場合、価値の高くないログ レコードを削除するために使用できます (例: 細粒度の重大度を持つログやノイズの多いロガーからのログなど)。 | |
コレクター | コレクターのテールサンプリングを使用すると、完了したトレースに基づいてサンプリングするかどうかを決定できます。 たとえば、エラーがあるトレースや、システムの重要な領域に関係するトレースの保持を強調できます。 欠点は、テールサンプリング プロセッサでは、トレースのすべてのスパンを同じコレクター インスタンスにルーティングする必要があり、トレースが完了するまでコレクターがスパンをメモリに保持する必要があるため、オブザーバビリティ パイプラインが複雑になることです。 オブザーバビリティ パイプラインが単一のコレクター インスタンスでは処理できない規模に達した場合は、慎重な計画が必要になります。 | |
コレクター | コレクター リソース プロセッサを使用すると、スパン、メトリクス、ログのリソース プロパティを操作する簡単なルールを作成できます。 たとえば、価値が高くない属性を削除できます。 | |
コレクター | コレクター メトリクス変換プロセッサを使用すると、メトリクス データを操作できます。 たとえば、価値が高くないシリーズを削除したり、時系列を結合してカーディナリティを減らしたりすることができます (空間再集約と呼ばれることもあります)。 | |
コレクター | コレクター変換プロセッサーを使用すると、データを選択する条件とそれを変更するステートメントを使用して、観察データを変換できます。 たとえば、リソースのプロパティの削除、プロパティの切り捨て、スパン、メトリクス、ログ レコードのトップレベル フィールドの変更などを行うことができます。 | |
コレクター | コレクターcumulativetodeltaプロセッサを使用すると、メトリクス集計の時間性を累積からデルタに変換できます。 これは 、New Relic の OTLP エンドポイントの優先集計時間 に合わせてメトリクスを調整するのに役立ちます。 累積集計から差分集計への変換はステートフルなプロセスであり、コレクターは差分を計算して出力するために各時系列の最後のポイントをメモリに保存する必要があることに注意してください。 これには、コレクター メモリ リソースを慎重に計画し、同じシリーズのすべてのポイントが同じコレクター インスタンスに確実に到着するようにオブザーバビリティ パイプラインを構築する必要があります。 |