jmeher2020
commented
1 month ago Hi, We are also effected with a similar kind of situation and the monitor is missing some records and not resulting accurately.
The period_end should refer to the time the monitor is expected to run/execute. The period_start should be the period_end minus the interval. However, we are running into a situation where the above is not true.
In our situation, The period_start seems to be when the monitor triggered or some in-between time which is unpredictable, and period_end seems to be period_start + the monitor interval (which is in the future).
Our challenge is to get the fine grained range with a start/from time including the previous execution duration of monitor + monitor interval.
Linked Bug : https://github.com/opendistro-for-elasticsearch/alerting/issues/389
Example/Assumptions: period_start = start/run/execution time of the monitor minus monitor interval period_end = start/run/execution time of the monitor
Suppose Interval set to 3 mins and first time the monitor runs at 10:15
"from": "{{period_start}}", -> 10:12 "to": "{{period_end}}", -> 10:15
Let Execution duration took 2 min and finished at 10:17. : 2 min -> End at 10:17 Monitor Interval : 3 min -> Next run 10:20
"from": "{{period_start}}", -> 10:17 "to": "{{period_end}}", -> 10:20
Missed time period : 10:15 to 10:17 the monitor execution time
The challenge is to set and get the previous end time or previous execution duration dynamically of monitor so that the query should look like and work with dynamic calculation: "from": "{{period_start}}|| -{{prev_exec_duration}}" or "from": "{{prev_execution_end}}" -> 10:15 "to": "{{period_end}}", -> 10:20
Appreciate any help or resolution. Thanks in advance.
Regards, J Meher
Is your feature request related to a problem? Please describe.
Currently, when defining a monitor, {{period_end}} is defined as the current time at monitor runtime, and {{period_start}} is defined as {{period_end}} minus the interval time.
However, usually I want the period to cover more time than the interval time. That way there's less chance for late messages to be missed if they come right around the end of an interval.
Describe the solution you'd like
It would be helpful to be able to define the period size separately from the interval size.
Describe alternatives you've considered
As a workaround, I could just specify {{period_end}}||-5m or similar in my extraction query rather than {{period_start}}. However it would be more useful if I could control the value of {{period_start}} in the monitor settings, that way I do not need to repeat the duration in multiple places.
Thanks for considering this idea.