You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In one or two sentences, describe the customer or community need, and what impact it has if we don’t address it.
Users who have narrowed down on something in their Dashboards are frustrated that they have to have to leave the context that they are looking at to create an alert. The user should be able to manage alerts based on what they are looking at in context.
What matters most to users & customers?
Describe the most important customer benefits and needs. Highlight any research, proposals, requests, issues, forum posts, anecdotes that signal this is the right thing to build.
Users will improve accuracy and reduce cognitive load when they create alerts based on what they are looking at instead of moving to a separate plugin page. Users will also benefit from seeing an overlay of alerts fired when reviewing a visualization tied to an alert.
What matters most to OpenSearch?
Describe the value that this feature will bring to the OpenSearch community, partners, or the project.
Making it easier for users to setup alerts and feel more confident in the systems they are responsible for which would result in higher adoption.
What does the user experience look like?
Describe the product feature requirements/specification. You may include low-fidelity sketches or wireframes, APIs stubs, or other examples of how a customer would use the feature. Using a bulleted list or simple diagrams to outline features is okay.
User narrows down what they are looking at (e.g. troubleshooting a problem, setting up new service) in a visualization within Dashboards.
Technical folk will use the Alerting plugin interface.
Non technical will take advantage of the dashboards they are accustomed to or have built.
The user selects the secondary menu from the visualization drop down after creating a visualization on a Dashboard.
The user is then shown a consolidated experience of creating a new monitor/alert where the form is pre-filled based on the context. If the user decides that they want to the normal monitor/alert flow, they will be sent over to the normal monitor/alert workflow with their visualization information filled in.
Error handling will be handled within the consolidated creation view.
Alert creation will be confirmed with a toast message on the dashboard.
Create alert flow
As a user, I want to be able to create an alert from a Dashboard visualization, so I can quickly create an alert based on what I’m looking at in the moment
As a user, I want my “create alert” form to be a simple experience, so I can quickly setup an alert and not be overwhelmed by configuration options.
As a user, I want my create alert form to be pre-filled in based on what I’m looking at, so I don’t fight to get the right information in when setting them up.
As a user, I want to know if there are errors when setting up a new alert, so I can fix them on the form.
As an advanced user, I want the ability to move to the normal alert creation flow and retain all my pre-filled information, so I can setup the alert just the way I want it.
View alerts tied to visualizations
If an alert is tied to a visualization, it is tied to the Saved Object
Once an alert has been created, I want to be able to see it on the visualization, so I can easily view what is happening for a context I am interested in.
If I am looking at a visualization, I want to edit an alert’s attributes, so that I save time by not going into the plugin.
If the visualization is refreshed with a new timescale, I want to see alerts associated with the updated timescale.
Performance / Bench Marking
Need to answer the following questions...
How much additional time will it take to fetch alert finding data and what will that do to page load times?
How will adding 100, 1000, 10000 new monitors to a cluster affect cluster performance?
How will we be logging performance data for later consumption in logs?
Administration
Default State (on)
Turn on/off
As an administrator who is concerned about users creating alerts in my system, I want to turn off the feature for all users, so I can rest easy that detectors are not using critical indexing resources
If alerts in the visualization is turned off, no users will see the feature
Performance
As an administrator, I want a mechanism which will tell me monitors are taking up too much compute, so I can react before things get bad on my cluster.
As an administrator, I want to know what monitors are using inefficient queries, so I can optimize performance.
As an administrator who wants to lock down their system, I want to know what predefined roles are required for displaying alerts on visualizations on dashboards
Either for Dashboards
opensearch_dashboards_read_only - A special role that prevents users from making changes to visualizations, dashboards, and other OpenSearch Dashboards objects.
opensearch_dashboards_user - Grants permissions to use OpenSearch Dashboards: cluster-wide searches, index monitoring, and write to various OpenSearch Dashboards indices.
Either for Alerting
alerting_ack_alerts - Grants permissions to view and acknowledge alerts, but not modify destinations or monitors.
alerting_read_access - Grants permissions to view monitors, but not create, modify, or delete detectors.
alerting_full_access - Grants full permissions to all alerting actions.
As an administrator who wants to lock down their system, I want to designate users/groups who can view alerts on visualizations in dashboards
opensearch_dashboards_read_only + alerting_ack_alerts or alerting_read_access = can view monitors created by others
opensearch_dashboards_read_only + alerting_full_access = can view monitors created by others
opensearch_dashboards_read_only + alerting_read_access = can view monitors created by others
As an administrator who wants to lock down their system, I want to designate users/groups who can create alerts on visualizations in dashboards
opensearch_dashboards_user + alerting_full_access = can create dashboards and create monitors
Role Conflicts
If a user who does not have alerting_full_access or alerting_read_access is provided a dashboard link which has visualizations with alerting enabled, they will not be able to see them because they won’t have alerting permissions.
Not included in the initial release
Setting up many alerts..
As someone who has to setup many alerts which are essentially the same thing, I want an easy way to mimic an alert’s details to make it easy to create new alerts
brijos
changed the title
[Feature Proposal] - Manage Alerts from Discovery or Dashboards (e.g. Observability)
[Feature Proposal] - Manage Alerts from OpenSearch Dashboards
Oct 18, 2022
brijos
changed the title
[Feature Proposal] - Manage Alerts from OpenSearch Dashboards
[Feature Proposal] - Augmenting Visualizations with Alerts
Dec 10, 2022
lezzago
transferred this issue from opensearch-project/alerting
Jan 25, 2023
What / Why
What are we building, and why?
Users who have narrowed down on something in their Dashboards are frustrated that they have to have to leave the context that they are looking at to create an alert. The user should be able to manage alerts based on what they are looking at in context.
What matters most to users & customers?
Users will improve accuracy and reduce cognitive load when they create alerts based on what they are looking at instead of moving to a separate plugin page. Users will also benefit from seeing an overlay of alerts fired when reviewing a visualization tied to an alert.
What matters most to OpenSearch?
Making it easier for users to setup alerts and feel more confident in the systems they are responsible for which would result in higher adoption.
What does the user experience look like?
User narrows down what they are looking at (e.g. troubleshooting a problem, setting up new service) in a visualization within Dashboards.
The user selects the secondary menu from the visualization drop down after creating a visualization on a Dashboard.
The user is then shown a consolidated experience of creating a new monitor/alert where the form is pre-filled based on the context. If the user decides that they want to the normal monitor/alert flow, they will be sent over to the normal monitor/alert workflow with their visualization information filled in.
Error handling will be handled within the consolidated creation view.
Alert creation will be confirmed with a toast message on the dashboard.
Create alert flow
View alerts tied to visualizations
Performance / Bench Marking
Administration
Not included in the initial release
The text was updated successfully, but these errors were encountered: