-
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
Convert Filebeat system.syslog to ECS #9135
Conversation
ba62d3c
to
c4f68a1
Compare
"system.syslog.program": "GoogleSoftwareUpdateAgent", | ||
"message": "2016-12-13 11:35:28.421 GoogleSoftwareUpdateAgent[21412/0x700007399000] [lvl=2] -[KSUpdateEngine updateAllExceptProduct:] KSUpdateEngine updating all installed products, except:'com.google.Keystone'.", | ||
"process.name": "GoogleSoftwareUpdateAgent", | ||
"process.pid": "21412", |
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.
IIRC process.pid needs converted to number.
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.
I have the same issue in an other PR. I need to investigate if during the testing the ECS templates are also properly loaded.
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.
This PR has not changed the fact that the PID was never properly cast to an int.
It's a trivial thing to fix in the grok, however. I'd be ok with fixing that in places where I see these values improperly cast. Could this introduce a breaking change, though? Visualizations are not affected by the field in _source
being a string or an int, so that part should be fine. But are there other things that could be affected by these values going from a string to an int?
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.
Actually haproxy/log
has it the worst. It has a mix of int and strings, both for the PID and for the port. If this was a problem, we would have heard about it by now. I'll go around and do this small improvement on all of my open PRs.
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.
It's a rabbit hole, though. Now I notice that IIS response code and response times are not converted to ints...
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.
I don't think it's a grok issue here. It's more of a template issue in the tests.
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.
No, all of these fields have proper long
mappings. It really is as simple as adding :int
at the end of the GROK expression, so that the value in the JSON document is a integer rather than a quoted string.
I've actually gone deep in the rabbit hole and changed all of the occurrences I saw in this PR and all of the other ones I'm working on at the moment.
c4f68a1
to
40d8ee1
Compare
@ruflin Ready for review. Make sure to check out caveats. Sorry on this app I can’t add the “review“ tag 😂 |
Modified title and assigned label ;-) |
I think this one is ready to go. We can do further adjustments in follow up PR's. |
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.
Test failure was a random network hiccup. Will re-trigger the build by pushing the deletion of system.syslog.timestamp
and rebasing. Should be good for merging after that.
40d8ee1
to
57078b7
Compare
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.
For the caveats:
- Let's go with
host.hostname
for now. I don't think we can tell if it comes from a device or host - I'm good with keeping
beat.timezone
for now until we figured out things in ECS. Let's add this to a "todo" list somewhere so we don't forget - event.original: Lets handle this in Filebeat modules: keep raw message #8083 as proposed, not here.
57078b7
to
b3ebfe6
Compare
@ruflin Trying to add field aliases towards their ECS equivalent seems not to make these fields into aliases in the mapping. It also does the wrong thing in the documentation generated. Steps to confirming the mapping:
Result: I'm seeing all of the aliased fields as normal Also, check out how all of the system.syslog fields I'm aliasing get replaced directly with their ECS equivalent here, that doesn't seem ok. My take would be to
|
b3ebfe6
to
edc9cf7
Compare
Only failure appears to be with this flaky test: #9207 |
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.
I opened a PR to skip the failing test. Ready to be merged.
- system.syslog.hostname => host.hostname - system.syslog.program => process.name - system.syslog.pid => process.pid - system.syslog.message => message
edc9cf7
to
dc67401
Compare
Caveats
host.hostname
. What should we do withdevice.hostname
?timezone
field, but should have one. Currently leaving tobeats.timezone
.ECS Fields temporarily defined locally
Renames
TODO
system.syslog.timestamp
Noticed
event.original
. Should we offer that as an option?convert_timezone
. Is there a way to add a test for this? Added to [WIP] Filebeat module issues found during ECS conversion #9208