mirror of
https://github.com/elastic/kibana.git
synced 2025-04-23 17:28:26 -04:00
[Alerting][Docs] Review usages of Alerting vs alerting (#119314)
* Alerting vs alerting * PR feedback * Reverting unnecessary changes * Apply suggestions from code review Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com> * PR feedback * PR feedback * Removing {kib} * Apply suggestions from code review Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com> * Removing {kib} Co-authored-by: gchaps <33642766+gchaps@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
This commit is contained in:
parent
194d5a94ba
commit
3de6de98a7
11 changed files with 18 additions and 18 deletions
|
@ -1,7 +1,7 @@
|
|||
[[alerting-apis]]
|
||||
== Alerting APIs
|
||||
|
||||
The following APIs are available for {kib} alerting.
|
||||
The following APIs are available for Alerting.
|
||||
|
||||
* <<create-rule-api, Create rule API>> to create a rule
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
<titleabbrev>List rule types</titleabbrev>
|
||||
++++
|
||||
|
||||
Retrieve a list of alerting rule types that the user is authorized to access.
|
||||
Retrieve a list of rule types that the user is authorized to access.
|
||||
|
||||
Each rule type includes a list of consumer features. Within these features, users are authorized to perform either `read` or `all` operations on rules of that type. This helps determine which rule types users can read, but not create or modify.
|
||||
|
||||
|
|
|
@ -107,7 +107,7 @@ From this page, you can disable, mute, and delete APM alerts.
|
|||
[[apm-alert-more-info]]
|
||||
=== More information
|
||||
|
||||
See {kibana-ref}/alerting-getting-started.html[alerting and actions] for more information.
|
||||
See {kibana-ref}/alerting-getting-started.html[Alerting] for more information.
|
||||
|
||||
NOTE: If you are using an **on-premise** Elastic Stack deployment with security,
|
||||
communication between Elasticsearch and Kibana must have TLS configured.
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
<titleabbrev>Alerting and action settings</titleabbrev>
|
||||
++++
|
||||
|
||||
Alerts and actions are enabled by default in {kib}, but require you configure the following in order to use them:
|
||||
Alerting and actions are enabled by default in {kib}, but require you to configure the following:
|
||||
|
||||
. <<using-kibana-with-security,Set up {kib} to work with {stack} {security-features}>>.
|
||||
. <<configuring-tls-kib-es,Set up TLS encryption between {kib} and {es}>>.
|
||||
|
|
|
@ -125,18 +125,18 @@ image::images/rule-concepts-summary.svg[Rules, connectors, alerts and actions wo
|
|||
[[alerting-concepts-differences]]
|
||||
== Differences from Watcher
|
||||
|
||||
{kib} alerting and <<watcher-ui,Watcher>> are both used to detect conditions and can trigger actions in response, but they are completely independent alerting systems.
|
||||
Alerting and <<watcher-ui,Watcher>> are both used to detect conditions and can trigger actions in response, but they are completely independent alerting systems.
|
||||
|
||||
This section will clarify some of the important differences in the function and intent of the two systems.
|
||||
|
||||
Functionally, {kib} alerting differs in that:
|
||||
Functionally, Alerting differs in that:
|
||||
|
||||
* Scheduled checks are run on {kib} instead of {es}
|
||||
* {kib} <<alerting-concepts-conditions, rules hide the details of detecting conditions>> through *rule types*, whereas watches provide low-level control over inputs, conditions, and transformations.
|
||||
* {kib} rules track and persist the state of each detected condition through *alerts*. This makes it possible to mute and throttle individual alerts, and detect changes in state such as resolution.
|
||||
* Actions are linked to *alerts* in {kib} alerting. Actions are fired for each occurrence of a detected condition, rather than for the entire rule.
|
||||
* Actions are linked to *alerts* in Alerting. Actions are fired for each occurrence of a detected condition, rather than for the entire rule.
|
||||
|
||||
At a higher level, {kib} alerting allows rich integrations across use cases like <<xpack-apm,*APM*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, and <<uptime-app,*Uptime*>>.
|
||||
At a higher level, Alerting allows rich integrations across use cases like <<xpack-apm,*APM*>>, <<metrics-app,*Metrics*>>, <<xpack-siem,*Security*>>, and <<uptime-app,*Uptime*>>.
|
||||
Pre-packaged *rule types* simplify setup and hide the details of complex, domain-specific detections, while providing a consistent interface across {kib}.
|
||||
|
||||
--
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
<titleabbrev>Set up</titleabbrev>
|
||||
++++
|
||||
|
||||
The Alerting feature is automatically enabled in {kib}, but might require some additional configuration.
|
||||
Alerting is automatically enabled in {kib}, but might require some additional configuration.
|
||||
|
||||
[float]
|
||||
[[alerting-prerequisites]]
|
||||
|
@ -17,9 +17,9 @@ If you are using an *on-premises* Elastic Stack deployment:
|
|||
|
||||
If you are using an *on-premises* Elastic Stack deployment with <<using-kibana-with-security, *security*>>:
|
||||
|
||||
* If you are unable to access Alerting, ensure that you have not {ref}/security-settings.html#api-key-service-settings[explicitly disabled API keys].
|
||||
* If you are unable to access {kib} Alerting, ensure that you have not {ref}/security-settings.html#api-key-service-settings[explicitly disabled API keys].
|
||||
|
||||
The Alerting framework uses queries that require the `search.allow_expensive_queries` setting to be `true`. See the scripts {ref}/query-dsl-script-query.html#_allow_expensive_queries_4[documentation].
|
||||
The alerting framework uses queries that require the `search.allow_expensive_queries` setting to be `true`. See the scripts {ref}/query-dsl-script-query.html#_allow_expensive_queries_4[documentation].
|
||||
|
||||
[float]
|
||||
[[alerting-setup-production]]
|
||||
|
@ -27,7 +27,7 @@ The Alerting framework uses queries that require the `search.allow_expensive_que
|
|||
|
||||
When relying on alerting and actions as mission critical services, make sure you follow the <<alerting-production-considerations,Alerting production considerations>>.
|
||||
|
||||
See <<alerting-scaling-guidance>> for more information on the scalability of {kib} alerting.
|
||||
See <<alerting-scaling-guidance>> for more information on the scalability of Alerting.
|
||||
|
||||
[float]
|
||||
[[alerting-security]]
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
<titleabbrev>Troubleshooting</titleabbrev>
|
||||
++++
|
||||
|
||||
The Alerting framework 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]]
|
||||
|
|
|
@ -35,7 +35,7 @@ Actions run long after the status of a rule changes, sending a notification of t
|
|||
*Solution*
|
||||
|
||||
Rules and actions run as background tasks by each {kib} instance at a default rate of ten tasks every three seconds.
|
||||
When diagnosing issues related to Alerting, focus on the tasks that begin with `alerting:` and `actions:`.
|
||||
When diagnosing issues related to alerting, focus on the tasks that begin with `alerting:` and `actions:`.
|
||||
|
||||
Alerting tasks always begin with `alerting:`. For example, the `alerting:.index-threshold` tasks back the <<rule-type-index-threshold, index threshold stack rule>>.
|
||||
Action tasks always begin with `actions:`. For example, the `actions:.index` tasks back the <<index-action-type, index action>>.
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
= {kib} alerts
|
||||
|
||||
The {stack} {monitor-features} provide
|
||||
<<alerting-getting-started,{kib} alerting rules>> out-of-the box to notify you
|
||||
<<alerting-getting-started,Alerting rules>> out-of-the box to notify you
|
||||
of potential issues in the {stack}. These rules are preconfigured based on the
|
||||
best practices recommended by Elastic. However, you can tailor them to meet your
|
||||
specific needs.
|
||||
|
|
|
@ -975,7 +975,7 @@ server log [12:41:33.672] [info][plugins][taskManager][taskManager] TaskManager
|
|||
--------------------------------------------------
|
||||
|
||||
If you see that message and no other errors that relate to Task Manager, it’s most likely that Task Manager is running fine and has simply not had the chance to pick the task up yet.
|
||||
If, on the other hand, the runAt is severely overdue, then it’s worth looking for other Task Manager or Alerting related errors, as something else may have gone wrong.
|
||||
If, on the other hand, the runAt is severely overdue, then it’s worth looking for other Task Manager or alerting-related errors, as something else may have gone wrong.
|
||||
It’s worth looking at the status field, as it might have failed, which would explain why it hasn’t been picked up or it might be running which means the task might simply be a very long running one.
|
||||
|
||||
[float]
|
||||
|
|
|
@ -11,9 +11,9 @@ This guide introduces you to three of {kib}'s security features: spaces, roles,
|
|||
[float]
|
||||
=== Spaces
|
||||
|
||||
Do you have multiple teams or tenants using {kib}? Do you want a “playground” to experiment with new visualizations or alerts? If so, then <<xpack-spaces,{kib} Spaces>> can help.
|
||||
Do you have multiple teams or tenants using {kib}? Do you want a “playground” to experiment with new visualizations or rules? If so, then <<xpack-spaces,{kib} Spaces>> can help.
|
||||
|
||||
Think of a space as another instance of {kib}. A space allows you to organize your <<dashboard, dashboards>>, <<alerting-getting-started, alerts>>, <<xpack-ml, machine learning jobs>>, and much more into their own categories. For example, you might have a Marketing space for your marketeers to track the results of their campaigns, and an Engineering space for your developers to {apm-guide-ref}/apm-overview.html[monitor application performance].
|
||||
Think of a space as another instance of {kib}. A space allows you to organize your <<dashboard, dashboards>>, <<alerting-getting-started, rules>>, <<xpack-ml, machine learning jobs>>, and much more into their own categories. For example, you might have a Marketing space for your marketeers to track the results of their campaigns, and an Engineering space for your developers to {apm-guide-ref}/apm-overview.html[monitor application performance].
|
||||
|
||||
The assets you create in one space are isolated from other spaces, so when you enter a space, you only see the assets that belong to that space.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue