Remap JSON attribute fields to top-level log event fields

The remapper transform moves or copies log event attributes to top-level log event fields, such as message or eventTimestamp, or to tags. You can also rename attributes by moving a value from one attribute path to another. See The remapper transform rename rules.

When you use the Grepr UI to create a pipeline, a remapper that transforms a default set of commonly used fields is automatically added to the pipeline, but you can modify which fields are transformed based on your requirements.

Example remapper transformation

For example, this event:

{
  "id": "ABCDEF",
  "eventTimestamp": 1765481731051,
  "message": "",
  "severity": "",
  "tags": {},
  "attributes": {
    "syslog": {
      "severity": "10",
      "appname": "test name"
    },
    "status": "5",
    "msg": "message 1",
    "timestamp": {
      "ms_since_epoch": 1765481730000
    },
    "eventTime": " "
  }
}

Would be transformed using the default configuration to:

{
  "id": "ABCDEF",
  "eventTimestamp": 1765481731051,
  "message": "message 1",
  "severity": "5",
  "tags": {
    "service": "test name"
  },
  "attributes": {
    "syslog": {
      "severity": "10",
      "appname": "test name"
    },
    "status": "5",
    "timestamp": {
      "ms_since_epoch": 1765481730000
    },
    "eventTime": " ",
    "greprMeta": {
      "messageAttributePath": "msg"
    }
  }
}

• severity uses status: "5" instead of syslog.severity: "10" because status has a higher priority in the default configuration.
• tags.service uses syslog.appname: "test name".
• The attribute msg is removed because it’s remapped to the top-level message field and the message field has preserve source disabled by default.
  • The greprMeta.messageAttributePath attribute is added to indicate which attribute was used for the remapped message field.
  • If the message attribute is a nested field, for example, log.msg, only the msg field is removed. The parent log object remains, even if it is empty.
• Other remapped attributes like status and syslog.appname remain in their original locations because their corresponding fields have preserve source enabled by default.
• timestamp: {} and eventTime: " " are not used because they do not contain a valid timestamp value.

The remapper transform default configuration

The following is the default remapper configuration. The Transformed attribute or tag column shows the field name in the transformed event after the input event is processed. The Preserve source column indicates whether the source attribute is kept in the original location after its value is copied to the target field, and Default paths searched are where the remapper looks in the input event for fields to transform.

You can toggle the Preserve source setting for each field in the pipelines UI. When preserve source is enabled, the source attribute remains in its original location after the value is copied to the target field. When disabled, the source attribute is removed after remapping. For example, the message field has preserve source disabled by default, so the original msg attribute is deleted after being copied to the top-level message field.

Tag mappings also support the preserve source option. You can configure whether the source attribute is kept or removed after its value is copied to a tag.

For the full list of default configuration settings, see the LogAttributesRemapper specification.

Map status values to severities

The remapper converts the raw value it finds in a status attribute, such as WARN, err, or 13, to one of Grepr’s standard severities: TRACE, DEBUG, INFO, WARN, ERROR, or FATAL. The event’s severity field stores the number at the start of that severity’s OpenTelemetry range, such as 13 for WARN. See The Grepr processing and data models.

The default status mapping

By default, the remapper recognizes the following names and the first three and first four characters of each name, such as war and warn:

Each name is recognized in lowercase, uppercase, and capitalized form, such as error, ERROR, and Error. Other casings, such as eRRoR, aren’t recognized. A number from 1 to 24 is kept as its OpenTelemetry severity number, so a finer level such as 14, which is WARN2, is preserved.

Define your own status mapping

To classify status values that the default mapping doesn’t recognize, set the statusMapping field of the log attributes remapper. For each severity, list exact values and prefixes, and add numberRanges for numeric status values. Your mapping replaces the default mapping and isn’t combined with it, so include every value you want classified.

Grepr removes leading and trailing whitespace from a status value, then classifies it as follows:

• A value equal to one of a severity’s exact values gets that severity.
• Otherwise, a value that starts with one of a severity’s prefixes gets that severity. When several prefixes match, the longest one applies, so emerg takes precedence over e for emergency.
• A whole number within one of the numberRanges, including both bounds, gets that range’s severity. A range within 1 to 24 can set severity to KEEP_NUMBER to keep the matched number as the OpenTelemetry severity number.

Matching is case-sensitive, so list each casing you expect, such as e and E. A string that contains a number, such as "3", is matched only by exact values and prefixes. If nothing matches a value, the remapper tries the next attribute in the status attribute list.

Because the order in which you list values doesn’t matter, each value can appear only once among all exact values and once among all prefixes, and number ranges can’t overlap. A value can be both an exact value and a prefix, in which case the exact match applies.

To edit the status mapping in the pipelines UI, click JSON Parser in the navigation menu, click Edit next to Attribute Remapper, then select the Status Remapping tab. Type a value and press Enter to add it, or end it with * to add a prefix. To match a value that ends with a literal *, end it with \* instead. Add all casings adds the lowercase, uppercase, and capitalized forms of what you type; click a value marked Aa to see and remove each casing. To return to Grepr’s default mapping, click Reset to Defaults.

Example status mapping

An application logs its own levels, such as SEV-CRIT and sev-lo, and also logs syslog-style numeric levels from 0 to 7. The following mapping classifies both:

{
  "type": "log-attributes-remapper",
  "statusMapping": {
    "fatal": { "exact": ["SEV-HI", "SEV-CRIT"] },
    "error": { "exact": ["sev-hi", "sev-err"] },
    "debug": { "prefixes": ["sev-lo", "sev-dbg"] },
    "info": { "prefixes": ["sev"] },
    "numberRanges": [
      { "min": 0, "max": 2, "severity": "FATAL" },
      { "min": 3, "max": 3, "severity": "ERROR" },
      { "min": 4, "max": 4, "severity": "WARN" },
      { "min": 5, "max": 6, "severity": "INFO" },
      { "min": 7, "max": 7, "severity": "DEBUG" }
    ]
  }
}

This mapping classifies status values as follows:

When a value isn’t classified, the remapper tries the next status attribute, and if none matches, the event keeps its existing severity.

Search by status after remapping

In log searches, status:error matches events whose severity is ERROR, whichever raw value the mapping classified as ERROR. To search for a raw status value, such as one that your mapping classifies, search the attribute it arrived in, such as @status:sev-mid or @level:sev-mid. This works only while the remapper preserves the source status attribute, which it does by default.

The remapper transform rename rules

To move or copy an attribute value from one path to another path, use a rename rule. Rename rules move an attribute value from one path to another in the same log event. Each rule has a Preserve source setting that controls whether the source attribute is kept or removed after its value is copied to the target path. If the target path already exists, its value is overwritten.

To add rename rules in the pipelines UI, click JSON Parser in the navigation menu, click Edit next to Attribute Remapper, then select the Rename Rules tab. Rules can be reordered by dragging them, and they are applied in order from top to bottom.

Example rename rule

Given the following attributes:

{
  "attributes": {
    "request": {
      "method": "POST",
      "path": "/api/users"
    }
  }
}

A rename rule with source request.method and target http_method produces:

{
  "attributes": {
    "request": {
      "path": "/api/users"
    },
    "http_method": "POST"
  }
}

The source field request.method is removed, while sibling fields like request.path are preserved.

Preserving the source attribute

When Preserve source is disabled on a rename rule, the source attribute is removed after its value is copied to the target. To keep the source attribute in its original location, enable the Preserve source checkbox on the rule. This copies the value to the target path without removing the original.

Using the same example above, with Preserve source enabled, the result would be:

{
  "attributes": {
    "request": {
      "method": "POST",
      "path": "/api/users"
    },
    "http_method": "POST"
  }
}

The value is copied to http_method, but request.method remains in its original location.

Write a path as an array of attribute names

A source or target path can be written in two forms. In a dotted string, each . steps into a nested attribute, so http.user.agent means http → user → agent. In a JSON array, each entry is one attribute name, used exactly as written, so ["http", "user", "agent"] is the same path.

Because array entries are never split, the array form can also name an attribute whose name contains a dot. In {"http": {"user.agent": "curl/8.4.0"}}, a rule with source ["http", "user.agent"] and target user_agent copies curl/8.4.0 to user_agent.

Conditional rename rules

Each rename rule can include an optional filter query. When a filter is set, the rule only applies to log events that match the query. This allows you to define multiple rules for the same source attribute with different filters, so each rule targets a different subset of events.

For example, you could configure two rules for the same source origin:

• origin → cloud.provider when the filter matches env:production
• origin → debug.origin when the filter matches env:staging

Because the filters are mutually exclusive, only one rule applies per event.

Rule ordering

Rename rules are applied sequentially in the order they appear. If two rules share the same source attribute, the first matching rule removes the source value. Subsequent rules for the same source will not find a value unless their filters prevent the earlier rule from applying.

See the AttributeRemappingRule specification.