Skip to content
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

Add metricset.period to each metricbeat event #6929

Closed
wants to merge 1 commit into from

Conversation

ruflin
Copy link
Contributor

@ruflin ruflin commented Apr 24, 2018

Having the period as part of each event makes it possible for Kibana or ML to predict when the next event is potentially missing or delayed based on the period of the previous events. It can always be that the period changed but as soon as the next event comes in, this can be used as the new expected period.

Only the schedule events will contain the metricset.period field.

@ruflin ruflin added in progress Pull request is currently in progress. Metricbeat Metricbeat labels Apr 24, 2018
@ruflin
Copy link
Contributor Author

ruflin commented Apr 24, 2018

@andrewkroh Can you have a look and share your thoughts? It also seems to be time to get rid of some of the old interfaces to clean up the code.

Copy link
Member

@andrewkroh andrewkroh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another case to handle is that events from push metricsets should not have metricset.period field unless they explicitly set a value in the event (like if some metric is received at a known interval).

@@ -27,7 +27,7 @@ type Event struct {

// BeatEvent returns a new beat.Event containing the data this Event. It does
// mutate the underlying data in the Event.
func (e *Event) BeatEvent(module, metricSet string, modifiers ...EventModifier) beat.Event {
func (e *Event) BeatEvent(module, metricSet string, period time.Duration, modifiers ...EventModifier) beat.Event {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of a new parameter here, I think a Period field inside of Event might be better. If Period is not set then the configured period is used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will change it accordingly as it allows every event to set a period if needed.

@ruflin ruflin added review and removed in progress Pull request is currently in progress. labels Apr 27, 2018
@ruflin
Copy link
Contributor Author

ruflin commented Apr 27, 2018

@andrewkroh I adjusted the implementation accordingly, rebased and squashed and it's ready for an other review.

Having the period as part of each event makes it possible for Kibana or ML to predict when the next event is potentially missing or delayed based on the period of the previous events. It can always be that the period changed but as soon as the next event comes in, this can be used as the new expected period.

Only the schedule events will contain the `metricset.period` field.
- name: metricset.period
type: long
description: >
Current data collection period for this events in micro seconds.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/events/event/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/micro seconds/microseconds/

@@ -97,6 +98,9 @@ func AddMetricSetInfo(module, metricset string, event *Event) {
if event.Took > 0 {
info["rtt"] = event.Took / time.Microsecond
}
if event.Period > 0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also update the godocs to mention period and show period in the sample JSON.

@@ -308,6 +308,9 @@ func (r reporterV2) Event(event mb.Event) bool {
if event.Took == 0 && !r.start.IsZero() {
event.Took = time.Since(r.start)
}
if r.msw.Module().Config().Period > 0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all LGTM, except that Period will be set to 10s even for the push metricsets (I think). So events from push metricsets will get a period and I'd like for that to not happen.

Can you check if this is the case? And if so, see if there is something else we can check to avoid adding period to push metricset events by default.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried it with the http/server metricset and unfortunately you are right. Need to figure out how we can detect this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be possible from to determine from the msw value whether or not it's push or pull.

Maybe you could add an enum to the metricSetWrapper that identifies the type as being push vs pull. You'd want to do this rather than doing a type assertion on each event.

@ruflin ruflin added the in progress Pull request is currently in progress. label May 1, 2018
@ruflin
Copy link
Contributor Author

ruflin commented May 1, 2018

Set to in progress again based on the comment from @andrewkroh #6929 (comment) as this should not happen and I need to test it.

@ruflin
Copy link
Contributor Author

ruflin commented May 31, 2018

@andrewkroh Didn't find here a good automatic solution yet. Best thing I came up with so far is to let every metricset decide if it wants to set the value or not.

@ruflin
Copy link
Contributor Author

ruflin commented Nov 22, 2018

@andrewkroh Never had time to investigate this further. Interested to take this on? I think it would be helpful in general to have this info.

@ycombinator Also relevant for stack-monitoring I think.

@ruflin ruflin added the Team:Integrations Label for the Integrations team label Nov 27, 2018
@andrewkroh
Copy link
Member

@ruflin I think I could talk someone through the changes to the metricSetWrapper (rather than taking it on myself). There is existing code in that file that checks to see what type of MetricSet it is (push/pull) so it shouldn’t be too bad.

@ruflin ruflin removed their assignment Dec 14, 2018
@ruflin
Copy link
Contributor Author

ruflin commented Jan 17, 2019

Closing this for now as we didn't need this in the UI so far. We can tackle this later again if needed.

@jsoriano
Copy link
Member

Continuing with this in #13242

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in progress Pull request is currently in progress. Metricbeat Metricbeat review Team:Integrations Label for the Integrations team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants