属性プロセッサーによるグループ化
Group by Attributes プロセッサを使用すると、スパン、ログレコード、メトリクスのデータポイントを、指定した属性に一致するリソースに再関連付けできます。その結果、指定された属性に同じ値を持つすべてのスパン、ログレコード、またはメトリクスデータポイントが同じリソースの下にグループ化されます。
Group by Attributes プロセッサは、OpenTelemetry Collector のコンポーネントであり、スパン、ログレコード、メトリクスのデータポイントを、指定した属性に一致するリソースに再関連付けします。その結果、指定された属性に同じ値を持つすべてのスパン、ログレコード、またはメトリクスデータポイントが同じリソースの下にグループ化されます。
サポートされるパイプラインタイプは、traces、metrics、logs です。詳細については「パイプラインでデータを処理する」を参照してください。
はじめに
以下の手順に従って、コンポーネントの設定とアクティベーションを行ってください:
-
Splunk Distribution of OpenTelemetry Collector をホストまたはコンテナプラットフォームにデプロイします:
-
次のセクションで説明するように、
groupbyattrsプロセッサーを設定します。 -
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属性を共有する複数のレコードであっても、複数のResourceSpans、ResourceMetrics、またはResourceLogsに属するものを、単一のResourceSpans、ResourceMetrics、または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-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 プロセッサーは、以下の内部メトリクスを記録します:
|
メトリクス |
説明 |
|---|---|
|
|
属性がグループ化されたスパンの数 |
|
|
属性がグループ化されていないスパンの数 |
|
|
スパンで抽出されたグループの分布 |
|
|
属性がグループ化されたログの数 |
|
|
属性がグループ化されていないログの数 |
|
|
ログから抽出されたグループの分布 |
|
|
属性がグループ化されたメトリクスの数 |
|
|
属性がグループ化されていないメトリクスの数 |
|
|
メトリクスのために抽出されたグループの分布 |
トラブルシューティング
__ ___ ___ _ ______ _____________ _____ ________ ___ ___ ___ ____ __ ___ ____ ____ __ ______ _____________ ______ ___ ___ ___ ____ __ ___ _________ _____
_________ __ ______ _____________ _____ _________
-
______ _ ____ __ ___ ______ _______ _______
-
_______ ______ ________
_________ __ ___________ _________ ___ ____ _____ _____
-
___ _ ________ ___ ___ _______ _______ _________ _______ __ ______ ________
-
____ ___ ______ ______________ ____ _____ _____ _______ __ ___________ ____ __________ _________ ___ ______ _________ __________ __ _____ ___ ____ _______