-
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
server Metricset for Zookeeper Metricbeat module #10341
server Metricset for Zookeeper Metricbeat module #10341
Conversation
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.
Looks pretty good already. Left a few minor comments, changelog is missing.
return output, nil | ||
} | ||
|
||
func parseXid(line string) (common.MapStr, error){ |
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.
Any chance to get some unit tests for the parse functions?
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.
Maybe you have missed it but those functions are tested by the global parseSrvr
that uses all of them. In that test all possible values are checked so I considered it tested (75% of coverage is achieved too).
Do you want individual tests too or it is enough with the global test?
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.
Works for me for the moment. In general I think we mainly test the "correct" cases but probably also should check the error cases. Not critical here.
"sent": 47, | ||
"version": { | ||
"date": "06/29/2018 04:05 GMT", | ||
"id": "3.4.13-2d71af4dbe22557fda74f9a9b4309b15a7487f03" |
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 service version should go under service.version
as it is an ECS field. Interesting to see that you extraced the date here. @webmat Thoughts?
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.
Version has been moved to service.version
and I have left the date there as version_date
. Maybe I should simply remove it as it's something that it's not going to change and it provides not much 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.
If you easily can skip the date then let's not add it to the event. Not sure how it would be used.
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.
FWIW - I don't feel there's a use-case for version_date
. It's not breaking BC if we introduce it in the future, so we might as well drop it (at least for now).
Thanks for your comments @ruflin I'll address the necessary changes asap. I have unset the |
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.
Left one nice to have suggestion on service fields
"name": "server" | ||
}, | ||
"service": { | ||
"address": "localhost:2181", |
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.
Would be nice if this was also broken up as service.ip
and service.port
.
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.
But we would still keep service.address
too I would assume. As ip does not match localhost for example.
BTW: This is not something related to this PR as it's done in the module logic. @webmat Could you open a separte issue for this? Nice thing here is we can always add this logic as it's not breaking but addition.
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.
Yes, we'd keep service.address
as the source of truth.
0687ce5
to
b9e63be
Compare
@@ -707,7 +707,7 @@ metricbeat.modules: | |||
#------------------------------ ZooKeeper Module ------------------------------ |
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 seems that this file in x-pack
must be manually updated now. @ruflin do you think that I should open an issue to automate this when running make update
from OSS?
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.
manually = running mage update
in the x-pack directory or manually you mean by hand and CI will not detect it has missing content?
What behaviour do we have in filebeat here?
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.
+1 on creating an issue to follow up on the discussion.
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.
Sorry, I mean by manually running mage update
in x-pack
folder. Opening issue #10369
f9e6c11
to
b5fab40
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.
LGTM. I suggest we backport this to 6.x if there are no major conflicts?
(cherry picked from commit 3895a23) # Conflicts: # metricbeat/module/zookeeper/fields.go # x-pack/metricbeat/module/mssql/performance/data_integration_test.go
…module (#10375) Cherry pick wasn't completed clean as we needed to adjust `service.version` field, which is documented in `fields.yml` on the module as (in master it is in ECS but ECS is not merged in 6.x)
The current metricset uses the
srvr
4 letter word command from Zookeeper to extract server information. Includes all the fields that are returned from the mentioned call. It looks like the following:You can see how the output is gonna look like in the data.json file.
A better description of the fields is missing. I have just written what I guess what they are but I might be wrong. I'm trying to find a good source of documentation to write a proper description of them.
GA
data.json
exists and an automated way to generate it exists (go test -data
)