Summary of the problem (If there are multiple problems or use cases, prioritize them)
This is the design issue corresponding to #235
The main issue here is that users would like to be able to configure (CRUD) monitors via the Kibana GUI instead of YAML.
Rough Design Outline
Our initial discussion here has been around:
- UI to be built primarily in Uptime with simple or no UI in IM. Will cross-link from IM to Uptime's richer UI.
- Only supporting HTTP monitors for parity with the IM UI (which can only show one type for now, due to technical constraints. HTTP is the most popular).
- Making the 'add data' button link to a simple form for creating a new monitor with
Name, Schedule, and URL, Tags (combo box) as basic options with some expandable advanced area. Tags don't have to be in MVP.
- Adding an
edit button for individual monitors that will also trigger the same form.
- As a stretch goal we can add additional advanced options, probably hidden by default
- Will be a flyout
User stories
As an Uptime user I'd like to be able to create, edit, update, and delete monitors if I have 'all' access to the app (Read access users would not be able to).
List known (technical) restrictions and requirements
This has to work with the ingest manager. Each monitor config would be analogous to the Ingest manager's 'policy' objects, which are created in the Security UI. There's a back and forth between ingest management and Uptime in this case due to how Ingest management works.
Ideally we'd support all of the Heartbeat monitor options at some point. There's quite a few (especially for HTTP monitors). We'll probably have to segment options between basic and advanced.
The only mandatory fields are:
Name: human readable name for the monitorSchedule: how often the monitor runs, e.g. every minute, day etc. (Note: Heartbeat supports a cron style syntax as well, but for our MVP I think it's much easier to just support common intervals of seconds, minutes and hours).Host/URL: Host for TCP and ICMP, URL for HTTP, e.g. http://www.elastic.co
There are heaps other options in the docs too of course.
Summary of the problem (If there are multiple problems or use cases, prioritize them)
This is the design issue corresponding to #235
The main issue here is that users would like to be able to configure (CRUD) monitors via the Kibana GUI instead of YAML.
Rough Design Outline
Our initial discussion here has been around:
Name,Schedule, andURL,Tags (combo box)as basic options with some expandable advanced area. Tags don't have to be in MVP.editbutton for individual monitors that will also trigger the same form.User stories
As an Uptime user I'd like to be able to create, edit, update, and delete monitors if I have 'all' access to the app (Read access users would not be able to).
List known (technical) restrictions and requirements
This has to work with the ingest manager. Each monitor config would be analogous to the Ingest manager's 'policy' objects, which are created in the Security UI. There's a back and forth between ingest management and Uptime in this case due to how Ingest management works.
Ideally we'd support all of the Heartbeat monitor options at some point. There's quite a few (especially for HTTP monitors). We'll probably have to segment options between basic and advanced.
The only mandatory fields are:
Name: human readable name for the monitorSchedule: how often the monitor runs, e.g. every minute, day etc. (Note: Heartbeat supports a cron style syntax as well, but for our MVP I think it's much easier to just support common intervals of seconds, minutes and hours).Host/URL: Host for TCP and ICMP, URL for HTTP, e.g.http://www.elastic.coThere are heaps other options in the docs too of course.