トランスフォームプロセッサー 🔗

変換プロセッサーは OpenTelemetry Collector コンポーネントであり、ステートメントによって、一致するスパン、メトリクス、またはログを変更します。使用例としては、メトリクススを別のタイプに変換する、キーを置換または削除する、定義済みの条件に応じてフィールドを設定するなどがあります。

ステートメントは OpenTelemetry Transformation Language (OTTL) の関数で、リスト内の順序に従ってテレメトリに適用されます。変換プロセッサーには、メトリクスタイプを変換するための追加関数があります。ステートメントは、定義した OTTL コンテキスト（Span や DataPoint など）に従ってデータを変換します。

トランスフォームプロセッサーは、以下のコンテキストをサポートしています：

シグナル	サポートされているコンテキスト
トレース	`resource` → `scope` → `span` → `spanevent`
メトリクス	`resource` → `scope` → `metric` → `datapoint`
ログ	`resource` → `scope` → `logs`

ステートメントは、より高いコンテキストのテレメトリを変換することができます。例えば、データポイントに適用されたステートメントは、データポイントのメトリクスとリソースにアクセスできます。例えば、spanステートメントを使用して単一のspanイベントを変換することはできません。一般的なルールとして、変換したいコンテキストにステートメントを関連付けます。

注意

テレメトリを変更すると、スパンやログの取り残し、アイデンティティの競合、誤ったメトリクス変換など、意図しない結果が生じる可能性があります。本番環境でリリースする前に、必ず変換をテストしてください。

はじめに 🔗

以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください：

Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします。はじめに：Collectorを理解して使用するを参照してください。
次のセクションで説明するように、TCPログレシーバーを設定します。
Collector を再起動します。

サンプル構成 🔗

パイプラインのトランスフォームプロセッサーを有効にするには、設定の processors セクションに transform を追加します。例：

transform:
  error_mode: ignore
  # Statements can be trace, metric, or log
  <trace|metric|log>_statements:
    - context: <context>
      statements:
        - <statement>
        - <statement>
        - <statement>
     - context: <context>
        statements:
        - <statement>
        - <statement>
        - <statement>

その後、互換性のあるパイプラインに変換プロセッサーを追加することができます。例：

:emphasize-lines: 6, 14, 22

service:
  pipelines:
    traces:
      receivers: [jaeger, otlp, zipkin]
      processors:
      - transform
      - memory_limiter
      - batch
      - resourcedetection
      exporters: [sapm, signalfx]
    metrics:
      receivers: [hostmetrics, otlp, signalfx]
      processors:
      - transform
      - memory_limiter
      - batch
      - resourcedetection
      exporters: [signalfx]
    logs:
      receivers: [fluentforward, otlp]
      processors:
      - transform
      - memory_limiter
      - batch
      - resourcedetection
      exporters: [splunk_hec]

error_mode フィールドは、ステートメントを処理する際にプロセッサーがどのようにエラーに対応するかを記述します：

error_mode: ignore は、エラーを無視して実行を続行するようにプロセッサーに指示します。これがデフォルトのエラー・モードです。
error_mode: propagate はエラーを返すようにプロセッサーに指示します。Collector は結果としてペイロードをドロップします。

OTTLの関数と構文の詳細については、こちらを参照してください：

OTTL 構文： https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/README.md
OTTL 関数： https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/ottlfuncs
OTTL コンテキスト： https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/contexts

設定例 🔗

以下のサンプル構成は、スパン、メトリクス、およびログに対してさまざまな変換を実行する方法を示しています。

Kubernetesのオブジェクトログを変換する 🔗

次の例は、k8sobjects レシーバーを使用して受信したログを編集する方法を示しています。ログを短縮すると、ダッシュボードでオブジェクトを視覚化したり、アラートを設定したりするときに便利です。

transform:
  error_mode: ignore
  log_statements:
    - context: log
      statements:
        - replace_all_patterns(attributes, "(object\.)(.*\.)", "object.")

リソースとスパンを編集してサイズを調整する 🔗

次の例は、属性の数を制限し、4,096文字に切り詰めることによって、リソースとスパンを編集する方法を示しています。resource 文は、keep_keys で示されたキー以外のすべてのキーを削除します。

transform:
  error_mode: ignore
  trace_statements:
     - context: resource
       statements:
         # Only keep the following keys
         - keep_keys(attributes, ["service.name", "service.namespace", "cloud.region", "process.command_line"])
         - limit(attributes, 100, [])
         - truncate_all(attributes, 4096)
     - context: span
       statements:
         - limit(attributes, 100, [])
         - truncate_all(attributes, 4096)

データポイントを異なるタイプに変換する 🔗

以下の例では、変換プロセッサーに含まれる関数を使用して、データポイントをメトリクス名によって異なるタイプに変換する方法を示しています。

transform:
  metric_statements:
    - context: metric
      statements:
        - set(description, "Sum") where type == "Sum"
    - context: datapoint
      statements:
        - convert_sum_to_gauge() where metric.name == "system.processes.count"
        - convert_gauge_to_sum("cumulative", false) where metric.name == "prometheus_metric"

設定 🔗

次の表は、属性プロセッサーの設定オプションを示します：

メトリクス関数 🔗

メトリクスコンテキストには以下の関数を適用できます：

convert_sum_to_gauge: sum型のメトリクスをgauge型に変換します。データポイントを保持します。
convert_gauge_to_sum:Gauge型のメトリクスをSum型に変換します。データポイントを保持。集計の一時性 ( cumulative または delta ) と単調性 (ブーリアン) を引数に取ります。
convert_summary_count_val_to_sum:要約のカウント値からsum型のメトリクスを作成します。引数として集約の一時性 ( cumulative または delta ) と単調性 (ブーリアン) を取ります。新しいメトリクスの名前は <summary metric name>_count の形式です。タイムスタンプ、属性、説明は保持されます。
convert_summary_sum_val_to_sum:要約のカウント値からsum型のメトリクスを作成します。引数として集約の一時性 ( cumulative または delta ) と単調性 (ブーリアン) を取ります。新しいメトリクスの名前は <summary metric name>_sum の形式です。タイムスタンプ、属性、説明は保持されます。

注意

変換関数を使用すると、メトリクスのセマンティクスが壊れる可能性があります。

トラブルシューティング 🔗

Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。

Splunk Observability Cloudをご利用のお客様

Submit a case in the Splunk Support Portal .
Contact Splunk Support .

見込み客および無料トライアルユーザー様

Splunk Answers のコミュニティサポートで質問し、回答を得る
Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルのチャットグループを参照してください。

このページは 2024年12月12日に最終更新されました。

Related Topics