-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cisco_ios: fix grok for ASR format logs #3694
Conversation
🌐 Coverage report
|
@@ -28,7 +28,7 @@ processors: | |||
- grok: | |||
field: _temp_.header | |||
patterns: | |||
- '^<%{NONNEGINT:log.syslog.priority:long}>%{NUMBER:event.sequence}?: (?:%{SYSLOGHOST:log.syslog.hostname}: )?%{CISCO_TIMESTAMP:_temp_.cisco_timestamp}' | |||
- '^<%{NONNEGINT:log.syslog.priority:long}>%{NUMBER:event.sequence}?: (?:%{SYSLOGHOST:log.syslog.hostname}: )?(?:%{NUMBER:cisco.ios.sequence}: )?(%{CISCO_TIMESTAMP:_temp_.cisco_timestamp}|%{NOTSPACE:cisco.ios.uptime}:)' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The next line below uses event.sequence
for what I think is the same value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think that's probably right. It's not at all clear to me what is the appropriate way to deal with the potential complexity here. Depending on configuration, there are four ways that the log lines can be formatted wrt these sequence numbers, and depending on the history of the configuration (AFAICS) the sequence numbers may either agree or not. The choice that I made here to leave that alone was based on it being the only sequence number present, and so using it as the ECS field. In the case above, I have retained the Cisco event count as the sequence number to avoid confusion (rather than fixing it), and put the sequence number in the cisco.* fields in case it is wanted. The complexity here is discussed in the issue.
My conclusion was that so long as the user doesn't change their configuration for these numbers, things will work. So I was planning to add some documentation about how to configure them as a recommendation, with a caveat not to change it if they already are getting these values.
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
/test |
I'll wait a bit to get feedback from @fgierlinger to see that the documentation here matches his experience with the device. |
What does this PR do?
This allows log lines emitted by ASR devices to be processed.
Checklist
changelog.yml
file.Author's Checklist
How to test this PR locally
Related issues
Screenshots