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 - 組織メタデータ:
team、cost_center、regionをすべてのテレメトリーに追加します - ビジネスコンテキストを充実させる: チェックアウトエンドポイントに
business_criticality=HIGHを追加します - 環境名を標準化:
env、environment、deploy_env→deployment.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.0autoscaling: minReplicas: 6 maxReplicas: 10 targetCPUUtilizationPercentage: 60configuration: 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/Logs、filter/Metrics) - 出力チェーン: 各ステップは出力目標を宣言し、処理パイプラインを作成します。
Pipelineフロー
ゲートウェイはデータを 3 つの独立したパイプライン (メトリクス、イベントとログ、トレース) に編成します。 この分離により、たとえば大量のログが重要なパフォーマンス トレースの処理や配信を妨げることがなくなります。
各パイプラインは、次の 3 つの機能ステージで構成されます。
- レシーバー (イングレス) レシーバーはデータのエントリ ポイントです。ゲートウェイは、次のものからの着信テレメトリを自動的にリッスンします。
OpenTelemetry (OTLP): OTel SDK およびコレクターからの標準データ。
New Relicエージェント:独自のテレメトリーエージェント。
- プロセッサ (ロジックと変換) ここでカスタム ルールが適用されます。次の 3 つの主要なプロセッサ タイプを使用して、データの処理方法を定義します。
サンプル:確率的または条件付きサンプリングによってボリュームを減らす
フィルター:条件に基づいて特定のレコードまたは属性を削除します。
変換: OpenTelemetry Transformation Language (OTTL) を使用して、ログを解析したり、属性の名前を変更したり、メタデータでデータを拡充したりします。
- エクスポーター (出力) データが処理、フィルタリング、サンプリングされると、エクスポーターは残りの高価値テレメトリを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 の概要を参照してください。
設定デプロイメント
ゲートウェイは統一設定モデルを使用します。
- すべての処理ステップを定義するYAML設定ファイルを作成します
- UI(YAMLアップロード)経由でクラスタにデプロイします
- ゲートウェイは組織内のすべてのゲートウェイクラスタに設定を適用します
- すべてのクラスターは同じルールを使用してデータを同じように処理します
バージョン管理:
- 設定を変更するたびに新しいバージョンが作成されます
- バージョン履歴を表示し、必要に応じてロールバックする
- 「デプロイメントが必要」バッジは保留中の変更を示します
次のステップ
パスを選択してください:
- ビジュアル設定:ゲートウェイUIを使用する
- YAML設定: YAMLの構造を学ぶ
または、特定のプロセッサ タイプについて詳しく見てみましょう。
- 変換プロセッサ- OTTL を使用してデータを変更、強化、解析する
- フィルタープロセッサ- OTTL条件を使用して不要なデータをドロップします
- サンプリングプロセッサ- 条件付きレートベースのサンプリングでデータ量を削減