属性プロセッサーによるグループ化 🔗
Group by AttributesプロセッサーはOpenTelemetry Collectorのコンポーネントで、スパン、ログレコード、メトリクスデータポイントを、指定された属性に一致するリソースに再関連付けします。その結果、指定された属性に同じ値を持つすべてのスパン、ログレコード、またはメトリクスデータポイントが同じリソースにグループ化されます。
サポートされるパイプラインタイプは、traces 、metrics 、logs です。詳細は パイプラインでデータを処理する を参照してください。
はじめに 🔗
以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください：
Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします：
次のセクションで説明するように、
groupbyattrsプロセッサーを設定します。Collector を再起動します。
サンプル構成 🔗
リソースプロセッサーを有効にするには、設定ファイルの processors セクションに groupbyattrs を追加します。以下の例のように、スパン、ログレコード、またはメトリクスデータポイントを「グループ化」するために使用する属性キーの配列を指定します：
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属性を共有するが、複数のResourceSpansまたはResourceMetricsまたはResourceLogsの下にある複数のレコード を、単一のResourceSpansまたはResourceMetricsまたはResourceLogsにコンパクト化します。これは例えば、
groupbytraceプロセッサーを使用する場合や、データが複数のリクエストで送られてくる場合などに起こります。If you compact data it takes less memory, it’s more efficiently processed and serialized, and the number of export requests is reduced.
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-typegaugeと混合型sumメトリクスのDataPointsは、DataTypeが異なるため、同じメトリクスの下に統合されていません。dont-moveメトリクスDataPointsはhost.name属性を持たないため、元のリソースの下に残っています。新しいリソースは、元のリソース（source=」prom」）から属性を継承し、処理されたメトリクス（
host.name="host-A"またはhost.name="host-B"）から指定された属性を継承します。新しいリソースに設定された指定されたグルーピング属性は、メトリクス
DataPointsからも削除されます。この例では示していないが、プロセッサーは、
InstrumentationLibraryに一致するレコードのコレクションもマージします。
データのコンパクト化 🔗
場合によっては、データがCollectorへの単一リクエストで送られてきたり、groupbytrace プロセッサーの使用により断片化されたりすることがあります。バッチ処理した後でも、ResourceSpans または ResourceMetrics または ResourceLogs オブジェクトが複数重複している可能性があります。これは、メモリの追加消費、処理コストの増加、非効率的なシリアライズ、またはエクスポート要求の増加につながります。
これを改善するには、groupbyattrs プロセッサーを使用して、Resource と InstrumentationLibrary プロパティを照合してデータをコンパクトにします。
例えば、次のような入力を考えてみます：
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 プロセッサーは、以下の内部メトリクスを記録します：
メトリクス |
説明 |
|---|---|
|
属性がグループ化されたスパンの数 |
|
属性がグループ化されていないスパンの数 |
|
スパンで抽出されたグループの分布 |
|
属性がグループ化されたログの数 |
|
属性がグループ化されていないログの数 |
|
ログから抽出されたグループの分布 |
|
属性がグループ化されたメトリクスの数 |
|
属性がグループ化されていないメトリクスの数 |
|
メトリクスのために抽出されたグループの分布 |
トラブルシューティング 🔗
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 マニュアルの チャットグループ を参照してください。