Defining top-level key for grok matches?

I'm attempting to clean-up our Logstash configs to manage ingestion from numerous disparate sources (forwarded from other Logstash clients, filebeat, winlogbeat, etc.), and I encountered an issue with using some of the default patterns, specifically with collisions on matched field names.

As an example, from linux-syslog in logstash-patterns-core:
CRONLOG %{SYSLOGBASE} \(%{USER:user}\) %{CRON_ACTION:action} \(%{DATA:message}\)

Using the grok filter with that pre-existing pattern registers a top-level "user" field ... which happens to collide with a provided winlogbeat field (which is a hash) in our setup.

Obviously I can avoid this issue by accepting the suggestion to setup source-specific templates in Elasticsearch and segregating my logs that way, or by implementing logic in my Logstash configs to move the troublesome fields under a new key, etc. ... but I was curious if it was perhaps feasible to define a top-level key under which to put all fields matched by a grok? This would make it easier to re-use core patterns but segregate fields. If necessary, I could even work on a pull request to accomplish this, but I wanted to make the proposal beforehand in case there were architectural considerations that would immediately discount the idea (assuming it's not already possible via an over-looked option to grok).

This isn't possible right now but a PR sounds reasonable to me.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.