Closed n473- closed 9 years ago
This can be fixed with the use of an additional grok:
# Pull out the Syslog Priority
grok {
match => { "message" => "<%{INT:syslog_pri}>" }
}
# Check if the message has syslog headers
grok {
match => { "message" => "%{SYSLOGBASE}" }
add_tag => "syslogbase"
}
# Convert the syslog priority it to human readable
syslog_pri { }
# Move the Syslog Message into a new field named syslog_message (to capture the original)
if ("syslogbase" in [tags]) {
mutate {
rename => ["message", "syslog_message"]
}
# Apply the SYSLOG GROK to the message to parse out the syslog headers, then place the left overs
# in message where we expect it to be.
grok {
match => ["syslog_message", "%{SYSLOGBASE} %{GREEDYDATA:message}"]
}
}
Which example is this? I'll clarify the documentation as this is Specifically related to remote syslog, not watching a file.
This is inclusive of remote syslog messages that for whatever reason do not arrive at the logstash rsyslog input with additional syslog headers. I'm not suggesting you modify the source, it's rather just an FYI in case anyone else has the same issues as I did :)
If the incoming message is devoid of the %{SYSLOGBASE}, or has a slightly different format, the full message is still mutated to syslog_message, leaving "message" empty. This will cause problems if grok patterns are matched to "message".
For example:
Filter:
Output:
Note how the [message] tag is empty or non-existent. Thus when grok attempts to match [message], it results in a _grokparsefailure.