New Relic OTLP プロパティ処理の更新

より緩やかな属性処理を実現するために、OTLP 取り込み検証ロジックを調整しています。

New Relic OTLP エンドポイントは、属性に対してさまざまな検証を実行します。キーと値の長さなどを制約する属性制限や、異種配列 (つまり、文字列と整数などの値の型が混在する配列)、ネストされた配列 (つまり、配列の配列) など、protobuf メッセージ定義を介して表現できるが、実際には通常は遭遇しないエッジケースの値型に対する追加の制約があります。

現在、New Relic OTLP エンドポイントは検証が厳格です。場合によっては、問題のある属性を黙って削除しますが、ほとんどの検証の問題では、単一の属性が無効な場合はレコード全体を削除します。

この厳格な検証は、OTLP データを New Relic に送信する際に顧客が遭遇する最も一般的な問題点の 1 つです。幸いなことに、簡単な解決策があります。

我々は寛容な属性処理姿勢を採用しています。属性が無効な場合は、その属性を削除または変更し、レコードを保持します。深刻なケースでは、レコードを保持する直感的な方法がない場合、レコードを削除することがあります。属性を削除または変更したり、レコードを削除したりするたびに、 NrIntegrationErrorを作成して、ソースの問題を追跡して修正できるようにします。

この変更は2025 年 6 月 2 日に展開される予定です。

これは私にどのような影響を与えるでしょうか

これは、ほとんどすべてのケースにおいて歓迎すべき救済策となるだろうと私たちは考えています。現在の厳格な検証では、データが欠落することが多く、特に多数の個別のチームによって管理される多数のデプロイメントがある環境では、追跡と診断が困難になる可能性があります。この変更により、New Relic OTLP エンドポイントは「送信したものを保存する」という当社の理念をよりよく体現するようになります。

ただし、New Relic の使用量ベースの価格設定モデルを考慮すると、この変更により、以前は削除されていたレコードが保存され、アカウントのデータ使用量に加算されることになります。

プロパティの制限に関する OTLP エンドポイントのドキュメントに従っており、データのプロパティがOpenTelemetry標準プロパティ定義に準拠している場合は、何もする必要はありません。これらの制約に準拠するということは、現在データが削除されていないことを意味し、したがって追加のデータは保存されません。

属性検証によりアカウント内のデータが現在削除されているかどうかを確認するには、次の NRQL クエリを実行します。

FROM NrIntegrationError SELECT * WHERE message like 'One or more OTLP data point(s) was dropped%'

このクエリが結果を返す場合、使用量が変更され、それに応じて課金も変更される可能性があります。正確な金額は、レコードが制限に違反する頻度によって異なります。具体的には、現在、以下のケースではレコードが削除されており、以下のように調整されます。

属性名が 255 文字の長さ制限を超えています。属性名は切り捨てられ、保持されます。
属性文字列値が 4095 文字の長さ制限を超えています。属性値は切り捨てられ、保持されます。
属性バイト配列がバイト配列の 128k 制限を超えています。属性は削除され、レコードは保持されます。
配列の長さが 64 エントリの制限を超えています。属性は削除され、レコードは保持されます。

注:最もよく見られる検証の問題は、属性文字列値が 4095 文字の制限を超えていることです。長い属性値を持つレコードを削除する検証から、長い属性を切り捨ててレコードを保持する検証に変更すると、データ使用量が著しく増加する可能性があります。

発生する可能性のある追加のデータ使用量を相殺する方法については、「軽減策」を参照してください。

緩和

OpenTelemetryの中核となる価値提案の一部は、テレメトリーデータパイプラインを制御するツールを提供することにあります。そのため、データ使用量の変化を緩和するのに役立つさまざまなツールが利用可能です。詳細については、「OpenTelemetry データ取り込みボリュームの管理」を参照してください。ここでは、特にいくつかの戦略が関連しています。

長い属性を切り捨てる
問題のある属性を削除する
サンプリングでレコード数を減らす

長い属性を切り捨てる

コレクター変換プロセッサとtruncate_allエディターを活用して、ここで示されているように、すべての属性を既知の制限まで切り捨てます。これは、この変更後に New Relic OTLP エンドポイントが実行する動作です。ただし、この手法を利用して、New Relic プラットフォームの制限よりも低い制限を設定することで、使用量の変化を相殺することができます。たとえば、オブザーバビリティのユースケースで最初の 1,000 文字だけが必要だと思われる場合は、制限を 1,000 に設定できます。

transform:
  trace_statements:
    - truncate_all(span.attributes, 4095)
    - truncate_all(resource.attributes, 4095)
  log_statements:
    - truncate_all(log.attributes, 4095)
    - truncate_all(resource.attributes, 4095)
  metric_statements:
    - truncate_all(datapoint.attributes, 4095)
    - truncate_all(resource.attributes, 4095)

問題のある属性を削除する

コレクター変換プロセッサとdelete_keyエディターを活用して、価値のない属性を削除します。

transform:
  trace_statements:
    - delete_key(span.attributes, "attribute.key.to.drop")
  log_statements:
    - delete_key(log.attributes, "attribute.key.to.drop")
  metric_statements:
    - delete_key(datapoint.attributes, "attribute.key.to.drop")

特に長く、そのため使用量に大きく貢献している属性キーや、短いが通常は役に立たない属性キーを削除することを選択できます。参考までに、次のリストは、属性値の長さ制限に違反する最も一般的な 10 個の属性をまとめたものです。

exception.stactrace
other - OpenTelemetryセマンティック規約で定義されていないカスタムアトリビュートの包括的なもの
db.statement
process.command_line
graphql.document
db.operation
db.query.text
http.url
exception.message
http.target

サンプリングでレコード数を減らす

ここで説明したいずれかの戦略を使用してサンプリングレートを調整し、追加データをオフセットします。