-
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
[Heartbeat] Report next_run info per event #13672
Conversation
Add support for `next_run` and `next_run_in` fields to the monitors object in events. This allows for the computation of SLA statistics in elasticsearch.
Pinging @elastic/uptime |
@@ -63,6 +63,21 @@ | |||
description: > | |||
A token unique to a simultaneously invoked group of checks as in the case where multiple IPs are checked for a single DNS entry. | |||
|
|||
- name: next_run |
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 normally stumble over names which are foo
and foo_bar
as it seems foo
should probably be an object because the two are somehow related. I guess this is the case here, but not sure what I should recommend as a name ...
BTW: 100% personal preference.
I think I also missed the reasoning why we need both. Wouldn't one be enough?
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.
That's a good point. I think we only need next_run_in
. This is in support of timelines in the future. Let me leave this PR open for now, when we get the Kibana side of this going and we're sure this does everything we need I can come back to this and merge it.
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.
SGTM. Ping me when I should have a look again.
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.
Code wise LGTM. Left one question.
Could you make hound happy?
heartbeat/monitors/pluginconf.go
Outdated
@@ -20,6 +20,8 @@ package monitors | |||
import ( | |||
"github.com/pkg/errors" | |||
|
|||
"github.com/elastic/beats/heartbeat/scheduler/schedule" | |||
|
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.
usual nit
@@ -55,7 +61,7 @@ func Parse(in string) (*Schedule, error) { | |||
return &Schedule{s}, nil | |||
} | |||
|
|||
func (s intervalScheduler) Next(t time.Time) time.Time { | |||
func (s IntervalScheduler) Next(t time.Time) time.Time { |
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.
exported method IntervalScheduler.Next should have comment or be unexported
interval time.Duration | ||
} | ||
|
||
func (s IntervalScheduler) QuantizedPeriod(now time.Time) (gte time.Time, lt time.Time) { |
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.
exported method IntervalScheduler.QuantizedPeriod should have comment or be unexported
@@ -29,10 +31,14 @@ type Schedule struct { | |||
scheduler.Schedule | |||
} | |||
|
|||
type intervalScheduler struct { | |||
type IntervalScheduler struct { |
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.
exported type IntervalScheduler should have comment or be unexported
|
||
import "time" | ||
|
||
func Quantize(t time.Time, period time.Duration) (start time.Time, end time.Time) { |
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.
exported function Quantize should have comment or be unexported
This field is needed to optimize the overview page queries. By adding the time range this monitor is responsible for we can use a range query to substantially narrow the candidate document set in queries. This takes over from the experiments in #13672 and should be production quality. It only adds this single necessary field.
This field is needed to optimize the overview page queries. By adding the time range this monitor is responsible for we can use a range query to substantially narrow the candidate document set in queries. This takes over from the experiments in elastic#13672 and should be production quality. It only adds this single necessary field. (cherry picked from commit 416aab0)
This field is needed to optimize the overview page queries. By adding the time range this monitor is responsible for we can use a range query to substantially narrow the candidate document set in queries. This takes over from the experiments in #13672 and should be production quality. It only adds this single necessary field. (cherry picked from commit 416aab0)
This pull request is now in conflicts. Could you fix it? 🙏
|
This pull request does not have a backport label. Could you fix it @andrewvc? 🙏
NOTE: |
@andrewvc - Closing this one as there were no activity for a while |
Add support for
next_run
andnext_run_in
fields to the monitors object in events. This allows for the computation of SLA statistics in elasticsearch.