-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Use process.name and event.outcome in filebeat system auth module #11231
Conversation
Not adding changelog entry as this was not released yet and there was already one for ECS migration included in #9138. |
Good stuff! Looks a bit like work I had started here but haven't had time to get back to yet. Notice that over in my PR, I'm doing grok twice. Once for the syslog header (instead of repeating in every single pattern) and then a second grok for the various kinds of messages. No big deal if we keep as a single grok definition, though (I suspect it's faster this way). One thing that worries me is that in this PR we're putting the source's raw values in On the other hand, nobody's had time to do significant work on building these lists of expected values yet. Perhaps it's ok to keep the raw values for now, and change around to the normalized values when these are ready. Thoughts, @ruflin, @elastic/secops ? |
@webmat your PR looks much more complete 🙂 if you plan to finish it for 7.0 I am fine with closing this PR. If not I think that we could merge this as it addresses the main issues I see (loss of process information after migration to ECS and use of So as you prefer. |
I'm good with both options as long as we hit 7.0 with it :-) |
My PR will definitely not make 7.0, it was an experiment. Please proceed with yours. |
(cherry picked from commit a2e6d3a)
Before migration to ECS (#9138), we could rely on the presence of specific fields to know the process originating the events, but this is not so reliable after some of these fields have been moved to common places. Add process.name also for known messages so we keep this info in a known place. Also use event.outcome instead of event.action for the result of the logged action. (cherry picked from commit a2e6d3a)
Before migration to ECS (#9138), we could rely on the presence of specific
fields to know the process originating the events, but this is not so reliable
after some of these fields have been moved to common places. Add
process.name
also for known messages so we keep this info in a knownplace.
Also use
event.outcome
instead ofevent.action
for the result of thelogged action.