ゲートウェイ プロセッサは、テレメトリー データがNew Relicに到達する前にそれを処理します。これは、NRDB で利用可能な一部のプロパティがゲートウェイではまだ利用できないことを意味します。 フィルター、変換、およびサンプリング プロセッサの OTTL 式を記述するときには、これらの違いを理解することが重要です。
スキーマが異なる理由
データフローとエンリッチメント
テレメトリーデータがNew Relicのプラットフォームを通過する場合:
- ゲートウェイ処理- ゲートウェイはエージェントやその他のソースから生のテレメトリーを受信します
- エンリッチメント- New Relic は属性（
entity.guid、appNameなど）を追加し、既存の属性の名前を変更します - クラウドルール処理- NRQLベースのcloudルールは強化されたデータに対して動作します
- ストレージ- データはすべてのエンリッチメントが適用された状態でNRDBに保存されます
ゲートウェイプロセッサへの影響
ゲートウェイ プロセッサは、事前エンリッチメント データを参照します。これは次のことを意味します。
- 一部の属性はまだ存在しません (
entity.guid、appName、entityGuidなど) - 属性名はNRDBに表示されるものと異なる場合があります
- フィルタと変換ロジックは、この縮小された属性セットを考慮する必要があります。
クラウド ルールはエンリッチメント後のデータを参照します。これは次のことを意味します。
- すべての強化された属性が利用可能
- NRQLゲートウェイに存在しないプロパティを参照できる
データソース
ゲートウェイは以下からテレメトリーを受信します。
- New Relic APM エージェント(複数の言語をサポート)
- New Relic Infrastructure
- OpenTelemetry
- New Relic API (イベントAPI 、ログAPI 、トレースAPI 、メトリクスAPI)
- その他のOTLP互換ソース
重要
エージェント設定ドキュメントを参照して、ゲートウェイ デプロイメントでサポートされているエージェントとバージョンを確認してください。
すべてのデータは、多数の属性を持つ複雑で多重ネストされた JSON として届きます。
ゲートウェイプロセッサのOTTL式の記述
属性の可用性
OTTL フィルタ条件または変換ステートメントを記述する場合:
利用可能な属性:
- エージェント/コレクターによって送信されたコア テレメトリー プロパティ
- 計装が直接追加するプロパティ
- 標準 OTLP 属性 (
span_id、trace_id、severity.numberなど)
利用できない属性（エンリッチメント中に追加されたもの）:
entity.guid,entityGuidappId,appNamehost（ほとんどの場合）realAgentId- NR固有のさまざまなメタデータ属性
詳細については、以下の属性参照表を参照してください。
ベストプラクティス
実際のデータでテストする:複雑なフィルターを作成する前に、ゲートウェイの監視データを使用して、テレメトリーにどのプロパティが存在するかを確認します。
利用可能な属性を使用します:
# ✓ Works - span_id exists in raw telemetryfilter/Spans: config: spans: - 'span_id.string == "abc123"'
# ✗ May not work - entity.guid added during enrichmentfilter/Spans: config: spans: - 'attributes["entity.guid"] == "xyz789"'強化された属性のcloudルールを検討してください。フィルタリング ロジックで強化された属性 (appNameやentity.guidなど) が必要な場合は、ゲートウェイ プロセッサの代わりにcloudルールを使用します。
参照テーブルを確認します。フィルターまたは変換で属性を使用する前に、以下の表でその属性が「ゲートウェイでは使用不可」としてリストされていないことを確認します。
データ型による属性参照
次の表は、各テレメトリーデータ タイプのゲートウェイ レベルで利用できないプロパティを示しています。 これらの属性に基づいてフィルタリングまたは変換する必要がある場合は、代わりにcloudルールの使用を検討してください。
データ型 | ゲートウェイで利用できない属性 | フィルター式の例（OTTL） |
|---|---|---|
トランザクション（APM） |
、
、
、
、
、
、
、
、
|
|
カスタムイベント |
、
、
、
、
、
|
|
エラートレース |
、
、
、
、
、
、
、
、
、
、
、
、
、
、
、
、
、
、
|
|
TransactionError |
、
、
、
、
、
、
、
、
|
|
ログ |
、
、
、
、
|
|
メトリックタイムスライス) |
、
、
、
、
、
、
、
、
、
| 次元メトリクスまたはcloudルールを使用する |
スパン (ディストリビューティッド（分散）トレーシング) |
、
、
、
、
、
、
、
、
、
、
、
|
|
SQLトレース |
、
、
、
、
、
、
、
、
、
、
、
、
、
、
|
|
トランザクショントレース |
、
、
、
、
、
、
、
、
、
、
、
| 生のトレースデータで利用可能な属性を使用する |
メトリクス（ゲージ） |
(値:
)、
:
|
|
メトリクス（概要） |
(値:
)、
:
|
|
メトリクス（カウント） |
(値:
)、
:
|
|
SystemSample（インフラストラクチャ） | なし |
|
ストレージサンプル（インフラストラクチャ） |
|
|
NetworkSample (インフラストラクチャ) |
|
|
ProcessSample (インフラストラクチャ) |
|
|
ContainerSample (インフラストラクチャ) |
、
、
|
|
一般的なシナリオ
エンティティによるフィルタリング
問題:エンティティごとにスパンをフィルター処理したいのですが、ゲートウェイにentity.guidが存在しません。
解決策:未加工のテレメトリーに存在するサービス名またはその他の識別プロパティを使用します。
filter/Spans: config: spans: - 'attributes["service.name"] == "my-service"'アプリケーション名によるフィルタリング
問題: APM トランザクションのゲートウェイにappNameがありません。
解決策:エージェントが設定したプロパティを直接使用するか、 cloudルールで強化した後にフィルタリングを適用します。
エンティティ情報の追加
問題:ゲートウェイでテレメトリーにエンティティ コンテキストを追加したいと考えています。
解決策:ゲートウェイでentity.guidにアクセスすることはできませんが、独自の識別メタデータを追加できます。
transform/Logs: config: log_statements: - set(attributes["deployment"], "production-us-east") - set(attributes["cluster"], "k8s-prod-01")トラブルシューティング
フィルターが期待されるデータと一致しない
フィルター プロセッサが期待どおりのデータと一致しない場合は、次の操作を実行します。
- 属性の可用性を確認する- ゲートウェイに属性が存在することを確認する（NRDB だけでなく）
- 実際のテレメトリーを検査する- ゲートウェイ監視を使用して、実際にどのようなプロパティが存在するかを確認します。
- 属性アクセスのテスト- 属性に簡単なフィルターを適用して、属性が存在するかどうかを確認します。filter/Test:config:logs:- 'attributes["entity.guid"] != ""' # Will match nothing if attribute doesn't exist
変換で期待される値が設定されない
属性が追加または変更されていない場合:
- 属性名を確認する- エンリッチメント前の属性名はNRDBと異なる場合があります
- データ型を確認してください- 属性に正しくアクセスしていることを確認してください（例:
attributes["key"]と直接フィールド アクセス） - プロセッサの順序を確認する- 変換が、それに依存するフィルタよりも先に実行されることを確認する
次のステップ
- フィルタープロセッサリファレンス- OTTLフィルター構文を学ぶ
- 変換プロセッサリファレンス- OTTL変換ステートメントを学ぶ
- クラウドルールドキュメント- エンリッチドデータでNRQLを使用する