-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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] Kibana Alerting #49219
[Monitoring] Kibana Alerting #49219
Conversation
…after creating alerts
… storing the email to receive alerts
Nice find! Fixed in 3c4924b |
Fixed in The icon here suggests that clicking on it will launch a new window or a different tab but instead, clicking on it displays the content in the same page. |
That would work for me! :) |
@chrisronline What if we just show them |
@chrisronline I would only show from |
💚 Build Succeeded |
💚 Build Succeeded |
My fear with trying to do this is the string that comes before it is a localized string. I think we should leave it as, knowing that it will get addressed before this feature is GA. Thoughts? |
The problem with the errors from actions like this, is that most of the time, the action isn't going to know exactly what the problem is, it's encoded in the message coming back from the service, in this case gmail. Yahoo's email service likely returns something similar, yet completely different, and so parsing the interesting bit from the service (line split here for readability) is going to be impossible:
Somehow, we need to make that message available to users, but we could potentially do a better job in the action result to accomodate this. Here's what the action currently returns:
We could send the following instead:
|
@pmuellr Makes sense. I think that little change (including the raw error message on the error object) will help us here, and exactly what we're looking to get. |
Question for @elastic/stack-monitoring What was our intention with handling multi-cluster monitoring and cluster alerts? Do we want to require the user to go to each cluster's overview page and create Kibana alerts? Or do we want to be able to create these alerts and have them function for every monitored cluster (this would be dynamic in that our alerting code will just do a terms agg across |
I prefer the second option. I don't think a user is going to want to go cluster-by-cluster and I think it simplifies things. |
💔 Build FailedTo update your PR or re-run it, just comment with: |
The comments are a bit much and stale at this point. I'm going to close and re-open a new one for this work. |
Relates to #42960
This PR lays the ground work for migrating cluster alerts to Kibana alerting. Part of this involves migrating a single alert for now -
xpack_license_expiration
.In addition to migrating the
xpack_license_expiration
alert, there is also a UI exposed in this PR that helps the user do their work for the migration. We discussed this and want to require the user to click a button to initiate the migration, which is in this PR.Also, we need a way to disable watcher-based cluster alerts as well. This PR does not do anything for that effort, as the plan is to disable them all when all alerts are migrated. This will involve a PR to Elasticsearch at some point. (See elastic/elasticsearch#50032)
Now you may be wondering why would we merge this PR with these new UIs right now? Well, we want to progressively merge into master the work around this migration, so we added a new constant in the code that indicates if kibana alerting is enabled or not for monitoring. For devs and testers, you will need to change this to
true
for any of this code to work. Once we are done migrating all alerts, we can just remove that constant.Screenshots
Setup
Testing
Testing
/dev/repos/kibana
and/dev/repos/elasticsearch
), pull down this PR, then runyarn es source
inside of kibana to use that custom ES build.kibana.dev.yml
:elasticsearch.yml
:true
GET .watches/_search?filter_path=hits.total.value
.monitoring-es-*
indices:This should cause the alert to fire. You can get it to the "resolved" state by simply removing the ingest pipeline from the index:
TODO
.monitoring-alerts-*
should be removeddefault_admin_email
logic since we aren't using that in the Kibana alerting world