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.

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

[Monitoring] Migrate license expiration alert to Kibana alerting #54260

Closed

Conversation

chrisronline
Copy link
Contributor

@chrisronline chrisronline commented Jan 8, 2020

Relates to #42960
Replaces #49219

This is the first PR of a set of PRs aimed to migrate the six watcher-based cluster alerts to use the Kibana alerting framework.

This PR focuses on the license expiration alert, as well as laying out the foundation of how the rest of the alerts will be migrated.

There are three main things we need to do to accomplish this:

  1. Disable the (potentially) existing watcher-based cluster alerts
  2. Create a UI that allows the user to create kibana-based cluster alerts.
  3. Ensure UX parity between watcher-based and kibana-based cluster alerts.

For the first one, the ES team will be introducing an api that will allow us to do that from the UI (pending ticket creation). For testing this PR, let's assume those are disabled properly and we don't need to worry about that now.

For the second one, we want to slowly merge all of this work into master (to avoid one large PR) so we are going to add a constant that will be set to false until all of the alerts are ready. Then, the final PR will remove this constant and all of the new alerts will be available to users.

Finally, for the last one, we want to ensure the messaging is consistent (even though it might be somewhat poor) for this phase.

Screenshots

alerting

Screen Shot 2020-01-08 at 10 15 45 AM

Screen Shot 2020-01-08 at 10 15 50 AM

Testing

  1. Flip this switch to true

We need to easily simulate the scenario in which this alert would fire. To do that, we'll leverage the monitoring ingest pipeline to set an expiration date in the near future. See these commands:

# Add the ingest pipeline
PUT _ingest/pipeline/force_license_expiration
{
  "processors": [
    {
      "script": {
        "lang": "painless",
        "source": """
          if (ctx.type == "cluster_stats") {
            ctx.license.expiry_date_in_millis = Instant.ofEpochMilli(new Date().getTime()).plusSeconds(60 * 60 * 24 * 3).getEpochSecond() * 1000;
          }
        """
      }
    }
  ]
}
# Ensure a local exporter is explictly configured so the default pipeline is established
PUT _cluster/settings
{
  "transient": {
    "xpack.monitoring.exporters": { 
      "local": {
        "type": "local",
        "use_ingest": false
      }
    }
  }
}
# Use the created pipeline
PUT .monitoring-es-7-*/_settings
{
  "index.required_pipeline": "force_license_expiration"
}

# This will unset the pipeline (and therefore resolve the alert)
PUT .monitoring-es-7-*/_settings
{
  "index.required_pipeline": null
}

TODO

  • Once migrated, all stored alerts in .monitoring-alerts-* should be removed
  • Only users with the right permissions should be able to interact with this UI, see [Monitoring] Only elevated permission users should see Setup Mode #50327
  • Should we perform CCS queries when searching for monitoring data in the alert?
  • Create follow up issues to remove the default_admin_email logic since we aren't using that in the Kibana alerting world

chrisronline and others added 30 commits October 16, 2019 16:28
@kibanamachine
Copy link
Contributor

💔 Build Failed

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants