NEW PLAN
After discussing with @liciavale it makes more sense to not implement this flow but the forthcoming suites management flow, which is closer to the new synthetics app and thus will be less effort with maximal code re-use. Let's pause on this till the right issue is filed there.
IGNORE BELOW
This supercedes #431 in solving elastic/beats#27924 .
Blocked on elastic/beats#29917
After a discussion with @liciavale , with a follow-up with @liciavale @paulb-elastic and @drewpost we agreed that the generic error facility mentioned in #431 had too many downsides to proceed with. The main issue is that dealing with history is strange, and we still have a weird UX due to the lake of symmetry between the upcoming monitor management UI and the overview page.
We want to keep on working on this problem for the future synthetics app, but for the immediate future we propose the following ACs:
- Add a new tab allowing you to switch from the current monitors table on the uptime overview page to a new 'suites' table.
- List all suites in a new suites table when the tab is clicked.
- The columns for that table would be:
1. Suite Name
2. Source: An abbreviated version of the source, usually a URL
3. Errors: Either the last received error or the text "No current errors" if none present
4. Monitors: A link to the overview page filtered (via KQL) to show all monitors contained by the suite
5. If it is easy to add a "All | With Errors" filter to the new suites tab let's do it, if not, let's not
6. Timestamp of last suite run
- To support these features heartbeat would issue a new type of suite run document, probably just the same way a monitor runs before each suite run.
- We determined that the status of a suite was not the sum of all jobs statuses, but rather that suites would not have a status, just a notion of current errors.
- Suite errors should not trigger existing alerting rules, adding alerts will be a todo for a future issue
- Mappings updated for new suites doc field
Given that our current design resources are limited, we're only going to be reaching out to @liciavale for approval on this and try for a lightweight iterative review process.
The changes to the current page would be something like what's listed below.
NEW PLAN
After discussing with @liciavale it makes more sense to not implement this flow but the forthcoming suites management flow, which is closer to the new synthetics app and thus will be less effort with maximal code re-use. Let's pause on this till the right issue is filed there.
IGNORE BELOW
This supercedes #431 in solving elastic/beats#27924 .
Blocked on elastic/beats#29917
After a discussion with @liciavale , with a follow-up with @liciavale @paulb-elastic and @drewpost we agreed that the generic error facility mentioned in #431 had too many downsides to proceed with. The main issue is that dealing with history is strange, and we still have a weird UX due to the lake of symmetry between the upcoming monitor management UI and the overview page.
We want to keep on working on this problem for the future synthetics app, but for the immediate future we propose the following ACs:
1. Suite Name
2. Source: An abbreviated version of the source, usually a URL
3. Errors: Either the last received error or the text "No current errors" if none present
4. Monitors: A link to the overview page filtered (via KQL) to show all monitors contained by the suite
5. If it is easy to add a "All | With Errors" filter to the new suites tab let's do it, if not, let's not
6. Timestamp of last suite run
- We determined that the status of a suite was not the sum of all jobs statuses, but rather that suites would not have a status, just a notion of current errors.
Given that our current design resources are limited, we're only going to be reaching out to @liciavale for approval on this and try for a lightweight iterative review process.
The changes to the current page would be something like what's listed below.