Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[discuss] cloud context in kibana / stack monitoring alerts for cloud-automated monitoring #110453

Open
Kushmaro opened this issue Aug 30, 2021 · 4 comments
Open

[discuss] cloud context in kibana / stack monitoring alerts for cloud-automated monitoring #110453

Kushmaro opened this issue Aug 30, 2021 · 4 comments
Labels
discuss estimate:needs-research Estimated as too large and requires research to break down into workable issues Team:Monitoring Stack Monitoring team Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)

Comments

@Kushmaro
Copy link

Kushmaro commented Aug 30, 2021 •
edited
Loading

Overview

Today, Kibana alerting doesn't have any specific context fields that are Elastic Cloud specific. This means that kibana alerting doesn't have the proper context for being more "cloud-aware". These are beneficial in two ways - one, for customers setting up their own alerts, and another for us as elastic operating on customer alerts.

Use cases

  1. Linking to the production deployment's cloud console, to be able to respond to an alert from cloud UI [user facing]
  2. Linking to the production deployment's Kibana UI, to respond to an alert directly from the stack [user facing]
  3. Linking to the monitoring deployment's kibana instance, to further drill down on an alert from the production cluster [user facing / elastic internal]
  4. Linking to production deployment in admin-console [elastic internal]
  5. Reporting/analyzing on deployments and/or customers which experience the most amount of alerts [elastic internal]
  6. Understanding an alert's urgency by customer-specific data like support level [elastic internal]
  7. Being able to analyze the time from alert being fired to resolution [elastic internal]

From the above use cases, the following fields are required:

Fields for the alerted cluster (#101018)

  • Cloud Deployment Id
  • Region
  • Deployment name (already available as cluster.name)
  • Cloud Base URL (for env related differences)

Fields that are customer-specific (no issue yet)

  • Customer Id / Organization Id for alerted deployment
  • Subscription Id / subscription level for alerted deployment

Discussing

  • The context for this issue is the monitoring service project in Elastic Cloud, which will require us to further enhance kibana alerting with potential customer-specific data.
  • Are there any further means of enriching the stack monitoring index with customer data that don't include adding data directly to kibana alerts?
  • Discuss further use cases for elastic-internal required data
  • Do these "elastic-internal" fields be documented / exposed for all or internal (I suspect the latter)

/cc @ravikesarwani
@botelastic botelastic bot added the needs-team Issues missing a team label label Aug 30, 2021
@Kushmaro Kushmaro added Feature:Stack Monitoring and removed needs-team Issues missing a team label labels Aug 30, 2021
@botelastic botelastic bot added the needs-team Issues missing a team label label Aug 30, 2021
@Kushmaro Kushmaro added Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more and removed Feature:Stack Monitoring labels Aug 30, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-stack-management (Team:Stack Management)

@botelastic botelastic bot removed the needs-team Issues missing a team label label Aug 30, 2021
@mikecote mikecote added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Team:Monitoring Stack Monitoring team and removed Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more labels Aug 30, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@elasticmachine
Copy link
Contributor

Pinging @elastic/stack-monitoring (Team:Monitoring)

@matschaffer
Copy link
Contributor

cc @cyrille-leclerc since I'm fairly sure this intersects with Actionable o11y

@mikecote mikecote added the estimate:needs-research Estimated as too large and requires research to break down into workable issues label Sep 1, 2021
@kobelb kobelb added the needs-team Issues missing a team label label Jan 31, 2022
@botelastic botelastic bot removed the needs-team Issues missing a team label label Jan 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
discuss estimate:needs-research Estimated as too large and requires research to break down into workable issues Team:Monitoring Stack Monitoring team Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams)
Projects
No open projects
AppEx: ResponseOps - Rules & Alerts Management
Status: No status
Milestone
No milestone
Development

No branches or pull requests
5 participants
@matschaffer @kobelb @mikecote @Kushmaro @elasticmachine