-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Always use summary events for monitor info #82376
Always use summary events for monitor info #82376
Conversation
Fixes elastic#81942 With synthetics we no longer are guaranteed to have the URL or other monitor info fields in every single event. This PR patches the monitor status API to only query summary fields for this info. As an added benefit, this is a bit more consistent as well because we tend to only show data from completed, not partial checks, in most places. This also removes the status check parameter from this API, which otherwise would need to be refactored. Checking the codebase it appears unused.
Pinging @elastic/uptime (Team:uptime) |
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, make sense to me !!
@@ -46,7 +47,6 @@ export const getLatestMonitor: UMElasticsearchQueryFn<GetLatestMonitorParams, Pi | |||
}, | |||
}, | |||
}, | |||
...(status ? [{ term: { 'monitor.status': status } }] : []), |
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.
You will also need to remove status from the function receiving params
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
* Always use summary events for monitor info Fixes elastic#81942 With synthetics we no longer are guaranteed to have the URL or other monitor info fields in every single event. This PR patches the monitor status API to only query summary fields for this info. As an added benefit, this is a bit more consistent as well because we tend to only show data from completed, not partial checks, in most places. This also removes the status check parameter from this API, which otherwise would need to be refactored. Checking the codebase it appears unused. * Remove unneeded params
* Always use summary events for monitor info Fixes elastic#81942 With synthetics we no longer are guaranteed to have the URL or other monitor info fields in every single event. This PR patches the monitor status API to only query summary fields for this info. As an added benefit, this is a bit more consistent as well because we tend to only show data from completed, not partial checks, in most places. This also removes the status check parameter from this API, which otherwise would need to be refactored. Checking the codebase it appears unused. * Remove unneeded params
* Always use summary events for monitor info Fixes #81942 With synthetics we no longer are guaranteed to have the URL or other monitor info fields in every single event. This PR patches the monitor status API to only query summary fields for this info. As an added benefit, this is a bit more consistent as well because we tend to only show data from completed, not partial checks, in most places. This also removes the status check parameter from this API, which otherwise would need to be refactored. Checking the codebase it appears unused. * Remove unneeded params
* Always use summary events for monitor info Fixes #81942 With synthetics we no longer are guaranteed to have the URL or other monitor info fields in every single event. This PR patches the monitor status API to only query summary fields for this info. As an added benefit, this is a bit more consistent as well because we tend to only show data from completed, not partial checks, in most places. This also removes the status check parameter from this API, which otherwise would need to be refactored. Checking the codebase it appears unused. * Remove unneeded params
Fixes #81942
With synthetics we no longer are guaranteed to have the URL or other monitor info fields in every single event. This PR patches the monitor status API to only query summary fields for this info.
As an added benefit, this is a bit more consistent as well because we tend to only show data from completed, not partial checks, in most places.
This also removes the status check parameter from this API, which otherwise would need to be refactored. Checking the codebase it appears unused.
Summary
Summarize your PR. If it involves visual changes include a screenshot or gif.
For maintainers