[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:
ymao1 2021-11-30 19:24:45 -05:00 committed by GitHub
parent 194d5a94ba
commit 3de6de98a7
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
11 changed files with 18 additions and 18 deletions

View file

@ -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

View file

@ -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.

View file

@ -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.

View file

@ -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}>>.

View file

@ -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}.
--

View file

@ -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]]

View file

@ -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]]

View file

@ -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>>.

View file

@ -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.

View file

@ -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, its 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 its 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 its worth looking for other Task Manager or alerting-related errors, as something else may have gone wrong.
Its worth looking at the status field, as it might have failed, which would explain why it hasnt been picked up or it might be running which means the task might simply be a very long running one.
[float]

View file

@ -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.