We'd like to be able to centrally manage monitors in Uptime via the UI vs using the Heartbeat YML as is done today. We can look at the Security app for inspiration, an Uptime monitor is somewhat analogous to a security policy.
UI ACs:
- Ability to perform CRUD (Create Read Update Delete) operations on all monitors from within the Uptime app.
- Ability to deploy "Uptime" integration to any agent
- Add use heartbeat under the beats agent
Key flows:
We can divide user activities here into two parts:
- Maintaining infrastructure: Configuring IM agents and policies, deploying servers, etc.
- Actually using Uptime: Creating uptime monitors (IM integrations)
The infrastructure maintenance part only really needs to be done once, or as needed for maintenance. This is the process of adding a new server to run agent/heartbeat on, enrolling it, and creating a policy for it. The second part is the day-to-day work of creating, editing, updating, and deleting monitors. In cloud we can probably make the first part mostly invisible by doing this work for the user.
So, a user when setting up Uptime on prem would first:
- Provision any physical servers needed for agent/heartbeat
- Go to IM
- Add a policy
- Enroll agents to be used for Uptime
- Add these agents to the policy they created
At that point they would be able to perform CRUD actions on monitors, either with the Uptime UI or the integrations package directly in IM.
On cloud, users won't need to deal with any of the provisioning stuff, and could simply use the Uptime app directly.
We'd like to be able to centrally manage monitors in Uptime via the UI vs using the Heartbeat YML as is done today. We can look at the Security app for inspiration, an Uptime monitor is somewhat analogous to a security policy.
UI ACs:
synthetics/*types should not change themonitor.typefield: [Heartbeat] Refactor config system beats#23467synthetics-*) [Uptime] Support agent data streams by default in Uptime kibana#91031Key flows:
We can divide user activities here into two parts:
The infrastructure maintenance part only really needs to be done once, or as needed for maintenance. This is the process of adding a new server to run agent/heartbeat on, enrolling it, and creating a policy for it. The second part is the day-to-day work of creating, editing, updating, and deleting monitors. In cloud we can probably make the first part mostly invisible by doing this work for the user.
So, a user when setting up Uptime on prem would first:
At that point they would be able to perform CRUD actions on monitors, either with the Uptime UI or the integrations package directly in IM.
On cloud, users won't need to deal with any of the provisioning stuff, and could simply use the Uptime app directly.