属性プロセッサーによるグループ化

Group by Attributes プロセッサを使用すると、スパン、ログレコード、メトリクスのデータポイントを、指定した属性に一致するリソースに再関連付けできます。その結果、指定された属性に同じ値を持つすべてのスパン、ログレコード、またはメトリクスデータポイントが同じリソースの下にグループ化されます。

Group by Attributes プロセッサは、OpenTelemetry Collector のコンポーネントであり、スパン、ログレコード、メトリクスのデータポイントを、指定した属性に一致するリソースに再関連付けします。その結果、指定された属性に同じ値を持つすべてのスパン、ログレコード、またはメトリクスデータポイントが同じリソースの下にグループ化されます。

サポートされるパイプラインタイプは、tracesmetricslogs です。詳細については「パイプラインでデータを処理する」を参照してください。

はじめに

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

  1. Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします:

  2. 次のセクションで説明するように、groupbyattrs プロセッサーを設定します。

  3. Collector を再起動します。

サンプル構成

リソースプロセッサーを有効にするには、設定ファイルの groupbyattrs セクションに processors を追加します。以下の例のように、スパン、ログレコード、またはメトリクスデータポイントを「グループ化」するために使用する属性キーの配列を指定します。

processors:
  groupbyattrs:
    keys:
      - foo
      - bar

keysプロパティは、どの属性キーがグループ化の対象となるかを記述します:

  • 処理されたスパン、ログレコード、およびメトリクスデータポイントが、指定された属性キーの少なくとも 1 つを持つ場合、これらの属性に同じ値を持つリソースに移動されます。同じ属性を持つリソースが存在しない場合は、リソースが作成されます。

  • 指定された属性キーが処理されたスパン、ログレコード、またはメトリクスデータポイントに存在しない場合、それは変更されることなく、同じリソースに関連付けられたままです。

設定を完了するには、構成ファイルの service セクションの任意のパイプラインにプロセッサを含めます。例:

service:
  pipelines:
    metrics:
      processors: [groupbyattrs]
    logs:
      processors: [groupbyattrs]
    traces:
      processors: [groupbyattrs]

コンフィグ仕様については config.go を参照してください。

代表的なユースケース

プロセッサーを使用して、以下のアクションを実行します:

  • Fluentbit ログや Prometheus メトリクスなどの「フラット」なデータフォーマットからリソースを抽出します。

  • すべてのメトリクスに存在するラベルに基づいて、Prometheus メトリクスを、関連するホストを記述するリソースに関連付けます。

  • 共通の属性を抽出することで、データのパッケージングを最適化。

  • 空のキーリストが指定された場合、同じ resource および InstrumentationLibrary 属性を共有する複数のレコードであっても、複数の ResourceSpansResourceMetrics、または ResourceLogs に属するものを、単一の ResourceSpansResourceMetrics、または ResourceLogsまとめます

    • これは例えば、groupbytrace プロセッサーを使用する場合や、データが複数のリクエストで送られてくる場合などに起こります。

    • データを圧縮すれば、メモリの使用量が抑えられ、その処理とシリアル化はより効率的になります。エクスポートリクエストの数も削減できます。

Tip

連続する手順として、groupbyattrsプロセッサと batch プロセッサを一緒に活用します。一致するリソースや InstrumentationLibrary の下にレコードをグループ化することで、データの断片化を減らすことができます。

高度な設定例

ホストごとにメトリクスをグループ化

すべて元は同じリソースに関連付けられている、以下のメトリクスを考えてみます:

Resource {host.name="localhost",source="prom"}
  Metric "gauge-1" (GAUGE)
    DataPoint {host.name="host-A",id="eth0"}
    DataPoint {host.name="host-A",id="eth0"}
    DataPoint {host.name="host-B",id="eth0"}
  Metric "gauge-1" (GAUGE) // Identical to previous Metric
    DataPoint {host.name="host-A",id="eth0"}
    DataPoint {host.name="host-A",id="eth0"}
    DataPoint {host.name="host-B",id="eth0"}
  Metric "mixed-type" (GAUGE)
    DataPoint {host.name="host-A",id="eth0"}
    DataPoint {host.name="host-A",id="eth0"}
    DataPoint {host.name="host-B",id="eth0"}
  Metric "mixed-type" (SUM)
    DataPoint {host.name="host-A",id="eth0"}
    DataPoint {host.name="host-A",id="eth0"}
  Metric "dont-move" (Gauge)
    DataPoint {id="eth0"}

以下の構成を使用して、 host.name属性の値に基づいて、host-A または host-B のいずれかにメトリクスを再度関連付けます。

processors:
  groupbyattrs:
    keys:
      - host.name

プロセッサーの出力は次のようになります:

Resource {host.name="localhost",source="prom"}
  Metric "dont-move" (Gauge)
    DataPoint {id="eth0"}

Resource {host.name="host-A",source="prom"}
  Metric "gauge-1"
    DataPoint {id="eth0"}
    DataPoint {id="eth0"}
    DataPoint {id="eth0"}
    DataPoint {id="eth0"}
  Metric "mixed-type" (GAUGE)
    DataPoint {id="eth0"}
    DataPoint {id="eth0"}
  Metric "mixed-type" (SUM)
    DataPoint {id="eth0"}
    DataPoint {id="eth0"}

Resource {host.name="host-B",source="prom"}
  Metric "gauge-1"
    DataPoint {id="eth0"}
    DataPoint {id="eth0"}
  Metric "mixed-type" (GAUGE)
    DataPoint {id="eth0"}

groupbytrace プロセッサーは以下を実現しています:

  • gauge-1 メトリクスの DataPoints は、もともと2つのメトリクス・インスタンスに分割されていたが、出力では統合されています。

  • mixed-type gauge と混合型 sum メトリクスの DataPoints は、DataType が異なるため、同じメトリクスの下に統合されていません。

  • dont-move メトリクス DataPointshost.name 属性を持たないため、元のリソースの下に残っています。

  • 新しいリソースは、元のリソース(source="prom")から属性を継承し、処理されたメトリクス(host.name="host-A" または host.name="host-B")から指定された属性を継承します。

  • 新しいリソースに設定された指定されたグルーピング属性は、メトリクス DataPoints からも削除されます。

  • この例では示していないが、プロセッサーは、InstrumentationLibrary に一致するレコードのコレクションもマージします。

データのコンパクト化

場合によっては、データが Collector に単一のリクエストで送信されたり、groupbytraceプロセッサの使用が原因でフラグメント化されたりすることがあります。バッチ処理した後でも、ResourceSpans または ResourceMetrics または ResourceLogs オブジェクトが複数重複している可能性があります。これは、メモリの追加消費、処理コストの増加、非効率的なシリアライズ、またはエクスポート要求の増加につながります。

これを改善するには、groupbyattrs プロセッサーを使用して、ResourceInstrumentationLibrary プロパティを照合してデータをコンパクトにします。

例えば、次のような入力を考えてみます:

Resource {host.name="localhost"}
  InstumentationLibrary {name="MyLibrary"}
  Spans
    Span {span_id=1, ...}
  InstumentationLibrary {name="OtherLibrary"}
  Spans
    Span {span_id=2, ...}

Resource {host.name="localhost"}
  InstumentationLibrary {name="MyLibrary"}
  Spans
    Span {span_id=3, ...}

Resource {host.name="localhost"}
  InstumentationLibrary {name="MyLibrary"}
  Spans
    Span {span_id=4, ...}

Resource {host.name="otherhost"}
  InstumentationLibrary {name="MyLibrary"}
  Spans
    Span {span_id=5, ...}

以下の設定を使用して、Resource および InstrumentationLibrary に一致するスパンを再度関連付けます。

processors:
  batch:
  groupbyattrs:

pipelines:
  traces:
    processors: [batch, groupbyattrs/grouping]
    ...

プロセッサーの出力は次のようになります:

Resource {host.name="localhost"}
  InstumentationLibrary {name="MyLibrary"}
  Spans
    Span {span_id=1, ...}
    Span {span_id=3, ...}
    Span {span_id=4, ...}
  InstumentationLibrary {name="OtherLibrary"}
  Spans
    Span {span_id=2, ...}

Resource {host.name="otherhost"}
  InstumentationLibrary {name="MyLibrary"}
  Spans
    Span {span_id=5, ...}

設定

次の表は、groupbyattrs プロセッサーの構成オプションを示します:

内部メトリクス

groupbyattrs プロセッサーは、以下の内部メトリクスを記録します:

メトリクス

説明

num_grouped_spans

属性がグループ化されたスパンの数

num_non_grouped_spans

属性がグループ化されていないスパンの数

span_groups

スパンで抽出されたグループの分布

num_grouped_logs

属性がグループ化されたログの数

num_non_grouped_logs

属性がグループ化されていないログの数

log_groups

ログから抽出されたグループの分布

num_grouped_metrics

属性がグループ化されたメトリクスの数

num_non_grouped_metrics

属性がグループ化されていないメトリクスの数

metric_groups

メトリクスのために抽出されたグループの分布

トラブルシューティング

__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____

_________ __ ______ _____________ _____ _________

_________ __ ___________ _________ ___ ____ _____ _____

  • ___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________

  • ____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______