• /
  • EnglishEspañolFrançais日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

Pipeline Controlゲートウェイ

Pipeline Controlゲートウェイは、インフラストラクチャ内で実行されるOpenTelemetryベースのデータ処理パイプラインです。 テレメトリーデータをNew Relicに送信する前に処理し、データコスト、信号品質、データ管理を制御できるようにします。

Pipeline Control ゲートウェイはどのような問題を解決しますか?

データの処理方法に対する可視性と詳細な制御が欠如しているため、組織はノイズが多く無関係なテレメトリー データに圧倒されています。 これにより、意味のあるインサイトを見つけたり、データを効果的に管理したりすることが困難になり、コストが高くなり、観察の効率が低下します。

ノイズの多いデータを除外する

問題:デバッグ ログ、テスト環境データ、ヘルス チェックによってシステムに無関係な情報が大量に送信され、重大な問題を見つけるのが困難になります。

ゲートウェイを使用したソリューション:

  • 本番環境からすべての DEBUG ログを除外します
  • すべてのテレメトリをネットワークから出る前にテスト環境から削除します
  • 毎日数百万のエントリを生成するヘルスチェックログを削除します
  • ログレベル、環境、サービス名、または任意の属性でフィルタリングします

結果:信号対雑音比の向上により、重大な異常や傾向の特定が容易になります。

データ取り込みコストを削減

問題:オブザーバビリティの請求額は月額 80,000 ドルで、その 70% は定期的なログの取り込みによるものです。 インサイトを提供しないと、大量の低価値データによりコストが増加します。

ゲートウェイを使用したソリューション:

  • ERROR および WARN ログを 100% 保持しながら、INFO ログの 95% をサンプリングします。
  • 無課金ユーザー (ユーザーベースの 80%) に対してユーザー固有のメトリクスを削除する
  • ソースで冗長または不要なテレメトリーをフィルタリングして除去する
  • ビジネス価値に基づいてきめ細かなレベルでデータを管理

結果:データ量が 85% 削減され、すべての重要なデータを保持しながら、毎月の請求額が 80,000 ドルから 12,000 ドルに削減されます。

コンテキストを追加してデータを充実させる

問題:マイクロサービスが異なるログ フレームワークを使用しています。サービス A はlevel=ERRORログに記録し、サービス B はseverity=errorログに記録し、サービス C はlog_level=3をログに記録します。統合されたダッシュボードやアラートを作成することはできません。

ゲートウェイを使用したソリューション:

  • 属性名を正規化する: すべてのバリアントを severity.text=ERROR
  • 組織メタデータ: teamcost_centerregionをすべてのテレメトリーに追加します
  • ビジネスコンテキストを充実させる: チェックアウトエンドポイントにbusiness_criticality=HIGHを追加します
  • 環境名を標準化: envenvironmentdeploy_envdeployment.environment

結果: 1 つのクエリがすべてのサービスにわたって機能します。統合ダッシュボードは、アプリケーション コードを変更することなく、正確なクロスサービス メトリクスを表示します。

誰がこれを使用すべきでしょうか?

Pipeline Control ゲートウェイは次のような場合に役立ちます。

  • うるさくて関係のないテレメトリーデータに圧倒される
  • データ取り込みコストを削減する必要がある
  • 信号対雑音比を改善して、重要な問題をより早く発見したい
  • テレメトリーデータに組織コンテキストを追加する必要がある
  • より優れたクエリのために非構造化ログデータを構造化したい
  • データプライバシー規制を遵守する必要がある
  • ネットワークから送信されるデータを制御したい

コアコンセプト

テレメトリーの種類

ゲートウェイは 4 つのテレメトリー タイプを個別に処理します。

  • メトリクス: 数値測定 (CPU 使用率、リクエスト レート、メモリ消費量)
  • イベント: 個別の発生 (デプロイメント、ユーザーサインアップ、エラー)
  • ログ: アプリケーションアクティビティのテキストベースの記録
  • トレース: マイクロサービス全体にわたる分散リクエストフロー(個々のスパン)

各タイプは、独自のプロセッサを備えた独自のパイプラインを通過します。

プロセッサ

プロセッサはパイプラインの構成要素です。各プロセッサ タイプには特定の目的があります。

ヒント

ゲートウェイ プロセッサは、変換ステートメントとブール条件の記述にOTTL (OpenTelemetry Transformation Language)を使用します。OTTL は、豊富な機能セットを備えた強力なベンダーニュートラル言語です。 詳細については、OpenTelemetry OTTL ドキュメントをご覧ください。

変換プロセッサはOTTL を使用してデータを変更します。

  • 属性を追加、更新、または削除する
  • 正規表現パターンで文字列を解析する
  • 既存のデータから新しいフィールドを派生する
  • ハッシュ高いカーディナリティ属性
  • 関数の例: set()replace_pattern()delete_key()Hash()

フィルター プロセッサは、 OTTL ブール式を使用してデータをドロップします。

  • 条件に一致するレコード全体を削除する
  • 複数の条件を組み合わせてフィルタリングする
  • 例の式: attributes["http.url"] matches ".*health.*"duration < 100000000

サンプリング プロセッサはデータ量をインテリジェントに削減します。

  • デフォルトのサンプリング率を設定する(例:全データの10%をサンプリングする)
  • 条件付きルールを定義する(例:エラーの 100% を保持し、成功の 5% をサンプリングする)
  • 属性値またはパターンによるサンプリングの制御

重要

レート サンプリングはログイベントとトレースでサポートされていますが、条件付きサンプリングはログイベントでのみサポートされています。

YAMLベースの設定

ゲートウェイ設定では、宣言型構造の YAML ファイルを使用します。

version: 2.0.0
autoscaling:
minReplicas: 6
maxReplicas: 10
targetCPUUtilizationPercentage: 60
configuration:
simplified/v1:
troubleshooting:
proxy: false
requestTraceLogs: false
steps:
receivelogs:
description: Receive logs from OTLP and New Relic proprietary sources
output:
- probabilistic_sampler/Logs
receivemetrics:
description: Receive metrics from OTLP and New Relic proprietary sources
output:
- filter/Metrics
receivetraces:
description: Receive traces from OTLP and New Relic proprietary sources
output:
- probabilistic_sampler/Traces
probabilistic_sampler/Logs:
description: Probabilistic sampling for all logs
output:
- filter/Logs
config:
global_sampling_percentage: 100
conditionalSamplingRules:
- name: sample the log records for ruby test service
description: sample the log records for ruby test service with 70%
sampling_percentage: 70
source_of_randomness: trace.id
condition: resource.attributes["service.name"] == "ruby-test-service"
probabilistic_sampler/Traces:
description: Probabilistic sampling for traces
output:
- filter/Traces
config:
global_sampling_percentage: 80
filter/Logs:
description: Apply drop rules and data processing for logs
output:
- transform/Logs
config:
error_mode: ignore
logs:
rules:
- name: drop the log records
description: drop all records which has severity text INFO
value: log.severity_text == "INFO"
filter/Metrics:
description: Apply drop rules and data processing for metrics
output:
- transform/Metrics
config:
error_mode: ignore
metric:
rules:
- name: drop entire metrics
description: delete the metric on basis of humidity_level_metric
value: (name == "humidity_level_metric" and IsMatch(resource.attributes["process_group_id"], "pcg_.*"))
datapoint:
rules:
- name: drop datapoint
description: drop datapoint on the basis of unit
value: (attributes["unit"] == "Fahrenheit" and (IsMatch(attributes["process_group_id"], "pcg_.*") or IsMatch(resource.attributes["process_group_id"], "pcg_.*")))
filter/Traces:
description: Apply drop rules and data processing for traces
output:
- transform/Traces
config:
error_mode: ignore
span:
rules:
- name: delete spans
description: deleting the span for a specified host
value: (attributes["host"] == "host123.example.com" and (IsMatch(attributes["control_group_id"], "pcg_.*") or IsMatch(resource.attributes["control_group_id"], "pcg_.*")))
span_event:
rules:
- name: Drop all the traces span event
description: Drop all the traces span event with name debug event
value: name == "debug_event"
transform/Logs:
description: Transform and process logs
output:
- nrexporter/newrelic
config:
log_statements:
- context: log
name: add new field to attribute
description: for otlp-test-service application add newrelic source type field
conditions:
- resource.attributes["service.name"] == "otlp-java-test-service"
statements:
- set(resource.attributes["source.type"],"otlp")
transform/Metrics:
description: Transform and process metrics
output:
- nrexporter/newrelic
config:
metric_statements:
- context: metric
name: adding a new attributes
description: 'adding a new field into a attributes '
conditions:
- resource.attributes["service.name"] == "payments-api"
statements:
- set(resource.attributes["application.name"], "compute-application")
transform/Traces:
description: Transform and process traces
output:
- nrexporter/newrelic
config:
trace_statements:
- context: span
name: remove the attribute
description: remove the attribute when service name is payment-service
conditions:
- resource.attributes["service.name"] == "payment-service"
statements:
- delete_key(resource.attributes, "service.version")
nrexporter/newrelic:
description: Export to New Relic

主な特徴:

  • バージョン宣言: version: 2.0.0は設定スキーマを指定します
  • ステップの命名: 形式は processortype/TelemetryType です (例: transform/Logsfilter/Metrics)
  • 出力チェーン: 各ステップは出力目標を宣言し、処理パイプラインを作成します。

Pipelineフロー

ゲートウェイはデータを 3 つの独立したパイプライン (メトリクス、イベントとログ、トレース) に編成します。 この分離により、たとえば大量のログが重要なパフォーマンス トレースの処理や配信を妨げることがなくなります。

各パイプラインは、次の 3 つの機能ステージで構成されます。

  1. レシーバー (イングレス) レシーバーはデータのエントリ ポイントです。ゲートウェイは、次のものからの着信テレメトリを自動的にリッスンします。
  • OpenTelemetry (OTLP): OTel SDK およびコレクターからの標準データ。

  • New Relicエージェント:独自のテレメトリーエージェント。

  1. プロセッサ (ロジックと変換) ここでカスタム ルールが適用されます。次の 3 つの主要なプロセッサ タイプを使用して、データの処理方法を定義します。
  • サンプル:確率的または条件付きサンプリングによってボリュームを減らす

  • フィルター:条件に基づいて特定のレコードまたは属性を削除します。

  • 変換: OpenTelemetry Transformation Language (OTTL) を使用して、ログを解析したり、属性の名前を変更したり、メタデータでデータを拡充したりします。

  1. エクスポーター (出力) データが処理、フィルタリング、サンプリングされると、エクスポーターは残りの高価値テレメトリをNew Relic cloudに安全に送信します。

YAML でパイプラインを定義するときは、プロセッサを特定のテレメトリ タイプにマッピングします。 設定を整理するために、標準の命名パターンprocessor_type/telemetry_typeを使用します。

例:

  • 変換/ログ:変換ロジックを特にログ データに適用します。

  • フィルター/メトリクス:ドロップ ルールを特にメトリクスに適用します。

  • サンプリング/トレース:ディストリビューティッド(分散)トレースのボリュームを管理します。

注意:

  • cloudルール (アカウント固有) とは異なり、ゲートウェイ ルールは組織全体に適用されます。
  • プロセッサは、名前に指定されたテレメトリ タイプにのみ影響します。 フィルター/ログ ルールによって、メトリクスやトレースが誤って削除されることはありません。

設定方法

UIベースの設定

Gateway UI は、YAML を記述せずにルールを作成するためのフォームベースのインターフェースを提供します。

  • 変換ルール:ガイド付き OTTL ステートメント ビルダーを使用して属性を追加/変更する
  • ドロップルール:条件ビルダーを使用して NRQL ベースのフィルタリングルールを作成する
  • サンプルレートルール:スライダーを使用して、グローバルおよび条件付きサンプリング率を設定します。

UIバックグラウンドで YAML 設定を生成し、随時プレビューを提供します。 詳細な手順については、 UI ガイドを参照してください。

YAML設定

上級ユーザーまたはインフラストラクチャ-as-code ワークフローの場合は、YAML 設定ファイルを直接編集します。

  • プロセッサの順序とパイプライン構造を完全に制御
  • Gitによるバージョン管理
  • CI/CDによる自動デプロイメント
  • UI に公開されていない高度な OTTL 機能へのアクセス

設定のリファレンスについては、 YAML の概要を参照してください。

設定デプロイメント

ゲートウェイは統一設定モデルを使用します。

  1. すべての処理ステップを定義するYAML設定ファイルを作成します
  2. UI(YAMLアップロード)経由でクラスタにデプロイします
  3. ゲートウェイは組織内のすべてのゲートウェイクラスタに設定を適用します
  4. すべてのクラスターは同じルールを使用してデータを同じように処理します

バージョン管理:

  • 設定を変更するたびに新しいバージョンが作成されます
  • バージョン履歴を表示し、必要に応じてロールバックする
  • 「デプロイメントが必要」バッジは保留中の変更を示します

次のステップ

パスを選択してください:

または、特定のプロセッサ タイプについて詳しく見てみましょう。

Copyright © 2026 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.