Certs page should only show currently active certs #199
Assignees
Labels
Comments
andrewvc
added a commit
to andrewvc/kibana
that referenced
this issue
May 13, 2020
Fixes elastic/uptime#199 Also fixes some duplicate constants used in the queries here. For default index we just use a literal `0` now since there's no way that'd ever change.
2 tasks
andrewvc
added a commit
to elastic/kibana
that referenced
this issue
May 14, 2020
* [Uptime] Only show ~latest checks on certs page/alert Fixes elastic/uptime#199 Also fixes some duplicate constants used in the queries here. For default index we just use a literal `0` now since there's no way that'd ever change. * Change window to 5m * Fix dependency issues in FTR suite for certs page. * Ensures tests can run independently, and always navigate to the certs page * Ensures that the not_after field is consistent * Ensures that timespan field is always present in checked documents
andrewvc
added a commit
to andrewvc/kibana
that referenced
this issue
May 14, 2020
* [Uptime] Only show ~latest checks on certs page/alert Fixes elastic/uptime#199 Also fixes some duplicate constants used in the queries here. For default index we just use a literal `0` now since there's no way that'd ever change. * Change window to 5m * Fix dependency issues in FTR suite for certs page. * Ensures tests can run independently, and always navigate to the certs page * Ensures that the not_after field is consistent * Ensures that timespan field is always present in checked documents
andrewvc
added a commit
to andrewvc/kibana
that referenced
this issue
May 14, 2020
* [Uptime] Only show ~latest checks on certs page/alert Fixes elastic/uptime#199 Also fixes some duplicate constants used in the queries here. For default index we just use a literal `0` now since there's no way that'd ever change. * Change window to 5m * Fix dependency issues in FTR suite for certs page. * Ensures tests can run independently, and always navigate to the certs page * Ensures that the not_after field is consistent * Ensures that timespan field is always present in checked documents # Conflicts: # x-pack/test/functional/apps/uptime/certificates.ts
andrewvc
added a commit
to elastic/kibana
that referenced
this issue
May 14, 2020
* [Uptime] Only show ~latest checks on certs page/alert Fixes elastic/uptime#199 Also fixes some duplicate constants used in the queries here. For default index we just use a literal `0` now since there's no way that'd ever change. * Change window to 5m * Fix dependency issues in FTR suite for certs page. * Ensures tests can run independently, and always navigate to the certs page * Ensures that the not_after field is consistent * Ensures that timespan field is always present in checked documents # Conflicts: # x-pack/test/functional/apps/uptime/certificates.ts
andrewvc
added a commit
to elastic/kibana
that referenced
this issue
May 14, 2020
* [Uptime] Only show ~latest checks on certs page/alert Fixes elastic/uptime#199 Also fixes some duplicate constants used in the queries here. For default index we just use a literal `0` now since there's no way that'd ever change. * Change window to 5m * Fix dependency issues in FTR suite for certs page. * Ensures tests can run independently, and always navigate to the certs page * Ensures that the not_after field is consistent * Ensures that timespan field is always present in checked documents
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Today we use a 24h window for our cert report page. The problem is that means it can take up to 24 hours for a fix to be reflected in an alert. Your alert will still fire for a full day after you've fixed the issue.
This is somewhat tricky to calculate efficiently on a real-time basis. However, given that all events with cert data support the new timespan fields we can look back 5m over
monitor.timespan. This will give us a 5m resolution time and also be very efficient.The downside is that users need to have pipelines that get data into ES within 5m, but this is generous window. This would only happen if someone has over-tuned their ES cluster with a long refresh policy. We should document this behavior.
I don't think this is common in the real world, and may never happen. If it does, we can respond then.
The text was updated successfully, but these errors were encountered: