Remove nested JSON fields in Logstash

Use mutate with a bracket-delimited field reference to remove a nested field. For example, [request][headers][authorization] identifies authorization inside the headers object inside request.

Remove a child field or its entire parent

filter {
  mutate {
    remove_field => [
      "[user][password]",
      "[request][headers]",
      "debug_info"
    ]
  }
}

For this event:

{"user":{"name":"tom","password":"example-secret"},"action":"login"}

The password child is removed while user.name and action remain. Removing [request][headers] removes that whole object rather than one header.

Parse a JSON string before removing its children

If JSON is still stored as text in message, its properties are not yet event fields. Parse it into a known target first:

filter {
  json {
    source => "message"
    target => "parsed"
    tag_on_failure => ["_payload_json_failure"]
  }
  if "_payload_json_failure" not in [tags] {
    mutate {
      remove_field => ["[parsed][data][token]", "message"]
    }
  }
}

This removes both the parsed token and the original JSON string that still contains it. Scope the failure tag to this parsing stage. Failed messages retain their raw text for investigation, so route them to a restricted destination if that text can contain secrets. Inspect other copies such as event.original as well; removing one representation is not complete redaction if another survives.

The event remains structured after parsing. Choose an output codec to serialize it as JSON if needed rather than treating the original string as the cleaned output.

Avoid ambiguous paths

user.password names a literal field with a dot; it does not address the nested field [user][password]. A wrong or absent path will not remove the intended value. Use a test event and inspect the resulting structure.

remove_field does not provide general wildcard or regex matching for field names. For patterns across dynamic fields or arrays of objects, use a carefully scoped Ruby filter and test the traversal. Prune is an alternative for top-level allowlists, but it does not solve arbitrary nested removal.

Removing large unused fields can reduce stored data, but savings depend on mappings, compression, and retained copies. It does not erase previously indexed documents.

References

• Elastic: filters mutate
• Elastic: filters json
• Elastic: filters prune