Relabel

Analytics Metrics

Synopsis

Rewrites OTLP metric attribute keys and values through an ordered list of actions — rename, copy, set, delete or hash — at either datapoint or resource scope.

Schema

- relabel:
    actions:
      - op: <enum>
        key: <string>
        to: <string>
        value: <string>
        salt: <string>
        resource: <boolean>
    filter: <script>
    description: <text>
    if: <script>
    ignore_failure: <boolean>
    on_failure: <processor[]>
    on_success: <processor[]>
    tag: <string>

Configuration

Field	Required	Default	Description
actions	Y	-	Ordered list of actions. At least one is required
filter	N	-	Cribl-style JavaScript truthiness expression evaluated after if. A falsy result skips the processor
description	N	-	Explanatory note
if	N	-	Condition to run
ignore_failure	N	false	See Handling Failures
on_failure	N	-	See Handling Failures
on_success	N	-	See Handling Success
tag	N	-	Identifier
disabled	N	false	When true, the processor is skipped and the event continues to the next one. Lets you take a processor out of the path without removing its configuration

Action

Field	Required	Default	Description
op	Y	-	rename, copy, set, delete or hash
key	Y	-	Attribute key the action applies to
to	Y*	-	Destination key. Required by rename and copy
value	Y*	-	Literal value to write. Required by set, and must not be empty
salt	N	-	Prefix mixed into the digest. Used by hash only
resource	N	false	Act on the resource attributes instead of the datapoint attributes

* = Conditionally required, by op. Every requirement here is checked at load, so a malformed action fails the configuration rather than silently doing nothing at runtime.

Details

Actions run in the order given, each seeing the result of the one before. A rename followed by an action naming the old key finds nothing; naming the new key works. Ordering is the whole vocabulary here, so read a list top to bottom.

resource is set per action, not per processor, so one list can rewrite attributes at both levels.

hash replaces the value in place with the hex-encoded SHA-256 digest of salt followed by the value. The key keeps its name and the attribute stays present — this is for making a high-cardinality value opaque while remaining groupable, not for removing it. Two events with the same value hash the same, which is what allows counting distinct values without carrying them; a salt makes that mapping unguessable across tenants or exports.

To remove an attribute entirely, use delete here, or Drop Dimensions for a list of keys at once.

Examples

Renaming an Attribute

Aligning an incoming attribute with the convention used downstream...	- relabel: actions: - op: rename key: svc to: service.name resource: true
at resource scope, since that is where the attribute lives:	# resource{svc="checkout"} # becomes # resource{service.name="checkout"}

Pseudonymizing a Value

Making a value opaque while keeping it groupable...	- relabel: actions: - op: hash key: customer_id salt: "$secret{id=7}"
the attribute stays present, so series can still be counted per customer:	# {customer_id="acme-corp"} # becomes # {customer_id="9f2c…"} (SHA-256 of salt + value)

Ordered Actions

Each action sees the result of the previous one...	- relabel: actions: - op: copy key: route to: route_raw - op: set key: route value: "redacted" - op: delete key: request_id
so the original is preserved before being overwritten:	# {route="/v1/users/42", request_id="abc"} # becomes # {route="redacted", route_raw="/v1/users/42"}