Skip to main content

Group By Attributes

Overview​

The Group By Attributes processor re-groups records by promoting one or more attributes from the record level up to the resource level. Records sharing the same value for every listed key end up under a single shared resource, and the attribute is removed from the record (since it now lives on the resource).

Common use cases:

  • Per-tenant routing. Promote tenant.id so a downstream router/exporter can fan out by tenant resource.
  • Per-host aggregation. Promote host.name so metrics for the same host land under one resource.
  • Compress wire size. When a high-cardinality attribute (e.g. service.name) is repeated on every record, promoting it deduplicates it across all records under that group.

Supported types: Logs · Metrics · Traces

Configuration​

ParameterTypeDefaultRequiredDescription
keysstring[]—YesAttribute keys to lift from record level to resource level. At least one key is required. Records that don't have a key get an empty value for it on the new resource.

Example Configuration​

{
  "keys": ["tenant.id", "service.name"],
}

A record {tenant.id: "acme", service.name: "billing", message: "..."} and another {tenant.id: "acme", service.name: "billing", message: "..."} end up under a single resource {tenant.id: "acme", service.name: "billing"} with both records (and the two attributes removed from each record body).

Notes​

  • Order matters. Run this processor before any aggregation that depends on resource identity (batch, transform, k8sattributes resource enrichment). The grouping changes which records share a resource.
  • Cardinality. The number of resource groups is bounded by the cartesian product of the keys' values. Picking a high-cardinality key (pod.name in a 10k-pod cluster) creates 10k resources per batch — heavy on downstream cost.
  • No ordering guarantee within a group. The processor reorders records into their groups; downstream processors that depend on input order should not be placed after this one.