github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-23 17:28:26 -04:00
Code Issues Projects Releases Packages Wiki Activity

[DOCS] Update details about alert visibility in Stack Management (#130202)

Browse source 
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
This commit is contained in:
Eric Davis 2022-05-04 12:19:25 -04:00 • committed by GitHub
parent 29705c01e4
commit f4d558a6da
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 35 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

32
docs/user/alerting/alerting-troubleshooting.asciidoc
View file

@ -1,11 +1,7 @@
[role="xpack"]
[[alerting-troubleshooting]]
== Troubleshooting
++++
<titleabbrev>Troubleshooting</titleabbrev>
++++
== Troubleshooting and limitations
Alerting provides many options for diagnosing problems with Rules and Connectors.
Alerting provides many options for diagnosing problems with rules and connectors.
[float]
[[alerting-kibana-log]]
@ -85,7 +81,7 @@ The result of this http request (and printed to stdout by https://github.com/pmu
[[alerting-error-banners]]
=== Look for error banners
The Rule Management and Rule Details pages contain an error banner, which helps to identify the errors for the rules:
The *Rule Management* and *Rule Details* pages contain an error banner, which helps to identify the errors for the rules:
[role="screenshot"]
image::images/rules-management-health.png[Rule management page with the errors banner]
@ -96,14 +92,14 @@ image::images/rules-details-health.png[Rule details page with the errors banner]
[[task-manager-diagnostics]]
=== Task Manager diagnostics
Under the hood, Rules and Connectors uses a plugin called Task Manager, which handles the scheduling, execution, and error handling of the tasks.
Under the hood, *Rules and Connectors* uses a plugin called Task Manager, which handles the scheduling, execution, and error handling of the tasks.
This means that failure cases in Rules or Connectors will, at times, be revealed by the Task Manager mechanism, rather than the Rules mechanism.
Task Manager provides a visible status which can be used to diagnose issues and is very well documented <<task-manager-health-monitoring,health monitoring>> and <<task-manager-troubleshooting,troubleshooting>>.
Task Manager uses the `.kibana_task_manager` index, an internal index that contains all the saved objects that represent the tasks in the system.
[float]
==== Getting from a Rule to its Task
==== Getting from a rule to its task
When a rule is created, a task is created, scheduled to run at the interval specified. For example, when a rule is created and configured to check every 5 minutes, then the underlying task will be expected to run every 5 minutes. In practice, after each time the rule runs, the task is scheduled to run again in 5 minutes, rather than being scheduled to run every 5 minutes indefinitely.
If you use the <<alerting-apis,Alerting REST APIs>> to fetch the underlying rule, you’ll get an object like so:
@ -190,12 +186,28 @@ When diagnosing the health state of the task, you will most likely be interested
Investigating the underlying task can help you gauge whether the problem you’re seeing is rooted in the rule not running at all, whether it’s running and failing, or whether it is running, but exhibiting behavior that is different than what was expected (at which point you should focus on the rule itself, rather than the task).
In addition to the above methods, broadly used the next approaches and common issues:
In addition to the above methods, refer to the following approaches and common issues:
* <<alerting-common-issues, Alerting common issues>>
* <<event-log-index, Querying Event log index>>
* <<testing-connectors, Testing connectors using Connectors UI and `kbn-action` tool>>
[discrete]
[[alerting-limitations]]
=== Limitations
The following limitations and known problems apply to the {version} release of
the {kib} {alert-features}.
[discrete]
==== Alert visibility
If you create a rule in the {observability} or {security-app}, its alerts are
not visible in *{stack-manage-app} > {rules-ui}*. You can view them only in the
{kib} app where you created the rule. If you use the
<<create-rule-api,create rule API>>, the visibility of the alerts is related to
the `consumer` property.
include::troubleshooting/alerting-common-issues.asciidoc[]
include::troubleshooting/event-log-index.asciidoc[]
include::troubleshooting/testing-connectors.asciidoc[]

14
docs/user/alerting/rule-types.asciidoc
View file

@ -41,6 +41,12 @@ see {subscriptions}[the subscription page].
Observability rules are categorized into APM and User Experience, Logs, Metrics, Stack Monitoring, and Uptime.
[NOTE]
==============================================
If you create a rule in the {observability} app, its alerts are not visible in
*{stack-manage-app} > {rules-ui}*. They are visible only in the {observability} app.
==============================================
[cols="2*<"]
|===
@ -72,7 +78,13 @@ beta:[] {ml-docs}/ml-configuring-alerts.html[{ml-cap} rules] run scheduled check
[[security-rules]]
=== Security rules
Security rules detect suspicious source events with pre-built or custom rules and create alerts when a rule’s conditions are met. For more information, refer to {security-guide}/prebuilt-rules.html[Security rules].
Security rules detect suspicious source events with pre-built or custom rules and create alerts when a rule's conditions are met. For more information, refer to {security-guide}/prebuilt-rules.html[Security rules].
[NOTE]
==============================================
Alerts associated with security rules are visible only in the {security-app};
they are not visible in *{stack-manage-app} > {rules-ui}*.
==============================================
include::rule-types/index-threshold.asciidoc[]
include::rule-types/es-query.asciidoc[]