honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[DOCS] Moves Watcher content into Elasticsearch book (#47147) (#47255) 

Co-Authored-By: James Rodewig <james.rodewig@elastic.co>
This commit is contained in:
Lisa Cawley 2019-09-30 10:18:50 -07:00 committed by GitHub
parent 8f1a80a43d
commit 0c3ee0b15c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
66 changed files with 431 additions and 437 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/java-rest/high-level/watcher/ack-watch.asciidoc
View File

@ -11,7 +11,7 @@
[id="{upid}-{api}-request"]
==== Execution
{stack-ov}/actions.html#actions-ack-throttle[Acknowledging a watch] enables you
{ref}/actions.html#actions-ack-throttle[Acknowledging a watch] enables you
to manually throttle execution of a watch's actions. A watch can be acknowledged
through the following request:

4
docs/painless/painless-contexts.asciidoc
View File

@ -49,9 +49,9 @@ specialized code may define new ways to use a Painless script.
| Bucket selector aggregation | <<painless-bucket-selector-agg-context, Painless Documentation>>
| {ref}/search-aggregations-pipeline-bucket-selector-aggregation.html[Elasticsearch Documentation]
| Watcher condition | <<painless-watcher-condition-context, Painless Documentation>>
| {xpack-ref}/condition-script.html[Elasticsearch Documentation]
| {ref}/condition-script.html[Elasticsearch Documentation]
| Watcher transform | <<painless-watcher-transform-context, Painless Documentation>>
| {xpack-ref}/transform-script.html[Elasticsearch Documentation]
| {ref}/transform-script.html[Elasticsearch Documentation]
|====
include::painless-contexts/index.asciidoc[]

2
docs/painless/painless-contexts/painless-watcher-condition-context.asciidoc
View File

@ -1,7 +1,7 @@
[[painless-watcher-condition-context]]
=== Watcher condition context
Use a Painless script as a {xpack-ref}/condition-script.html[watch condition]
Use a Painless script as a {ref}/condition-script.html[watch condition]
that determines whether to execute a watch or a particular action within a watch.
Condition scripts return a Boolean value to indicate the status of the condition.

2
docs/painless/painless-contexts/painless-watcher-context-variables.asciidoc
View File

@ -29,7 +29,7 @@ The following variables are available in all watcher contexts.
`ctx['payload']` (`Map`, read-only)::
The accessible watch data based upon the
{xpack-ref}/input.html[watch input].
{ref}/input.html[watch input].
*API*

2
docs/painless/painless-contexts/painless-watcher-transform-context.asciidoc
View File

@ -1,7 +1,7 @@
[[painless-watcher-transform-context]]
=== Watcher transform context
Use a Painless script as a {xpack-ref}/transform-script.html[watch transform]
Use a Painless script as a {ref}/transform-script.html[watch transform]
to transform a payload into a new payload for further use in the watch.
Transform scripts return an Object value of the new payload.

3
docs/reference/commands/syskeygen.asciidoc
View File

@ -21,7 +21,8 @@ bin/elasticsearch-syskeygen
The command generates a `system_key` file, which you can use to symmetrically
encrypt sensitive data. For example, you can use this key to prevent {watcher}
from returning and storing information that contains clear text credentials. See {xpack-ref}/encrypting-data.html[Encrypting sensitive data in {watcher}].
from returning and storing information that contains clear text credentials. See
<<encrypting-data>>.
IMPORTANT: The system key is a symmetric key, so the same key must be used on
every node in the cluster.

2
docs/reference/ilm/apis/slm-api.asciidoc
View File

@ -80,7 +80,7 @@ The top-level keys that the policy supports are described below:
| `schedule` | A periodic or absolute time schedule. Supports all values
supported by the cron scheduler:
{xpack-ref}/trigger-schedule.html#schedule-cron[Cron scheduler configuration]
<<schedule-cron,Cron scheduler configuration>>
| `name` | A name automatically given to each snapshot performed by this policy.
Supports the same <<date-math-index-names,date math>> supported in index

2
docs/reference/ilm/getting-started-slm.asciidoc
View File

@ -97,7 +97,7 @@ PUT /_slm/policy/nightly-snapshots
--------------------------------------------------
// TEST[continued]
<1> when the snapshot should be taken, using
{xpack-ref}/trigger-schedule.html#schedule-cron[Cron syntax], in this
<<schedule-cron,Cron syntax>>, in this
case at 1:30AM each day
<2> whe name each snapshot should be given, using
<<date-math-index-names,date math>> to include the current date in the name

2
docs/reference/index.asciidoc
View File

@ -56,6 +56,8 @@ include::high-availability.asciidoc[]
include::security/index.asciidoc[]
include::{xes-repo-dir}/watcher/index.asciidoc[]
include::commands/index.asciidoc[]
include::how-to.asciidoc[]

34
docs/reference/settings/notification-settings.asciidoc
View File

@ -27,14 +27,12 @@ Set to `false` to disable {watcher} on the node.
`xpack.watcher.encrypt_sensitive_data`::
Set to `true` to encrypt sensitive data. If this setting is enabled, you
must also specify the `xpack.watcher.encryption_key` setting. For more
information, see
{xpack-ref}/encrypting-data.html[Encrypting sensitive data in {watcher}].
information, see <<encrypting-data>>.
`xpack.watcher.encryption_key` (<<secure-settings,Secure>>)::
Specifies the path to a file that contains a key for encrypting sensitive data.
If `xpack.watcher.encrypt_sensitive_data` is set to `true`, this setting is
required. For more information, see
{xpack-ref}/encrypting-data.html[Encrypting sensitive data in {watcher}].
required. For more information, see <<encrypting-data>>.
`xpack.watcher.history.cleaner_service.enabled`::
added:[6.3.0,Default changed to `true`.]
@ -88,7 +86,7 @@ include::ssl-settings.asciidoc[]
==== Email Notification Settings
You can configure the following email notification settings in
`elasticsearch.yml`. For more information about sending notifications
via email, see {xpack-ref}/actions-email.html#configuring-email-actions[Configuring Email].
via email, see <<configuring-email-actions>>.
`xpack.notification.email.account`::
Specifies account information for sending notifications via email. You
@ -98,14 +96,15 @@ can specify the following email account attributes:
[[email-account-attributes]]
`profile` (<<cluster-update-settings,Dynamic>>);;
The {xpack-ref}/actions-email.html#configuring-email[email profile] to use to build the MIME
The <<configuring-email,email profile>> to use to build the MIME
messages that are sent from the account. Valid values: `standard`, `gmail` and
`outlook`. Defaults to `standard`.
`email_defaults.*` (<<cluster-update-settings,Dynamic>>);;
An optional set of email attributes to use as defaults
for the emails sent from the account. See {xpack-ref}/actions-email.html#email-action-attributes[
Email Action Attributes] for the supported attributes.
for the emails sent from the account. See
<<email-action-attributes>> for the supported
attributes.
`smtp.auth` (<<cluster-update-settings,Dynamic>>);;
Set to `true` to attempt to authenticate the user using the
@ -166,9 +165,9 @@ can specify the following email account attributes:
`xpack.notification.email.html.sanitization.allow`::
Specifies the HTML elements that are allowed in email notifications. For
more information, see {xpack-ref}/actions-email.html#email-html-sanitization[Configuring HTML
Sanitization Options]. You can specify individual HTML elements
and the following HTML feature groups:
more information, see
<<email-html-sanitization>>. You can
specify individual HTML elements and the following HTML feature groups:
+
--
[[html-feature-groups]]
@ -229,7 +228,7 @@ include::ssl-settings.asciidoc[]
==== Slack Notification Settings
You can configure the following Slack notification settings in
`elasticsearch.yml`. For more information about sending notifications
via Slack, see {xpack-ref}/actions-slack.html#configuring-slack-actions[Configuring Slack].
via Slack, see <<configuring-slack-actions>>.
`xpack.notification.slack` ::
Specifies account information for sending notifications
@ -270,7 +269,7 @@ via Slack. You can specify the following Slack account attributes:
==== Jira Notification Settings
You can configure the following Jira notification settings in
`elasticsearch.yml`. For more information about using notifications
to create issues in Jira, see {xpack-ref}/actions-jira.html#configuring-jira-actions[Configuring Jira].
to create issues in Jira, see <<configuring-jira-actions>>.
`xpack.notification.jira` ::
Specifies account information for using notifications to create
@ -290,7 +289,7 @@ issues in Jira. You can specify the following Jira account attributes:
`issue_defaults`;;
Default fields values for the issue created in Jira. See
{xpack-ref}/actions-jira.html#jira-action-attributes[Jira Action Attributes] for more information.
<<jira-action-attributes>> for more information.
Optional.
--
@ -299,7 +298,7 @@ issues in Jira. You can specify the following Jira account attributes:
==== PagerDuty Notification Settings
You can configure the following PagerDuty notification settings in
`elasticsearch.yml`. For more information about sending notifications
via PagerDuty, see {xpack-ref}/actions-pagerduty.html#configuring-pagerduty-actions[Configuring PagerDuty].
via PagerDuty, see <<configuring-pagerduty-actions>>.
[[pagerduty-account-attributes]]
@ -318,8 +317,9 @@ PagerDuty API key] to use to access PagerDuty. Required.
--
+
`event_defaults`;;
Default values for {xpack-ref}/actions-pagerduty.html#pagerduty-event-trigger-incident-attributes[
PagerDuty event attributes]. Optional.
Default values for
<<pagerduty-event-trigger-incident-attributes,PagerDuty event attributes>>.
Optional.
+
--
`description`::

3
docs/reference/setup/bootstrap-checks-xes.asciidoc
View File

@ -14,8 +14,7 @@ If you use {watcher} and have chosen to encrypt sensitive data (by setting
the secure settings store.
To pass this bootstrap check, you must set the `xpack.watcher.encryption_key`
on each node in the cluster. For more information, see
{xpack-ref}/encrypting-data.html[Encrypting Sensitive Data in {watcher}].
on each node in the cluster. For more information, see <<encrypting-data>>.
[float]
=== PKI realm check

2
x-pack/docs/en/rest-api/watcher/ack-watch.asciidoc
View File

@ -5,7 +5,7 @@
<titleabbrev>Ack watch</titleabbrev>
++++
{stack-ov}/actions.html#actions-ack-throttle[Acknowledging a watch] enables you
<<actions-ack-throttle,Acknowledging a watch>> enables you
to manually throttle execution of the watch's actions.
[[watcher-api-ack-watch-request]]

3
x-pack/docs/en/rest-api/watcher/activate-watch.asciidoc
View File

@ -5,8 +5,7 @@
<titleabbrev>Activate watch</titleabbrev>
++++
A watch can be either
{stack-ov}/how-watcher-works.html#watch-active-state[active or inactive]. This
A watch can be either <<watch-active-state,active or inactive>>. This
API enables you to activate a currently inactive watch.
[[watcher-api-activate-watch-request]]

3
x-pack/docs/en/rest-api/watcher/deactivate-watch.asciidoc
View File

@ -5,8 +5,7 @@
<titleabbrev>Deactivate watch</titleabbrev>
++++
A watch can be either
{stack-ov}/how-watcher-works.html#watch-active-state[active or inactive]. This
A watch can be either <<watch-active-state,active or inactive>>. This
API enables you to deactivate a currently active watch.
[[watcher-api-deactivate-watch-request]]

9
x-pack/docs/en/rest-api/watcher/execute-watch.asciidoc
View File

@ -65,14 +65,14 @@ This API supports the following fields:
that will be used during the watch execution
| `ignore_condition` | no | false | When set to `true`, the watch execution uses the
{stack-ov}/condition-always.html[Always condition].
<<condition-always,always condition>>.
This can also be specified as an HTTP parameter.
| `alternative_input` | no | null | When present, the watch uses this object as a payload
instead of executing its own input.
| `action_modes` | no | null | Determines how to handle the watch actions as part of the
watch execution. See <<watcher-api-execute-watch-action-mode, Action Execution Modes>>
watch execution. See <<watcher-api-execute-watch-action-mode>>
for more information.
| `record_execution` | no | false | When set to `true`, the watch record representing the watch
@ -81,8 +81,7 @@ This API supports the following fields:
watch is updated, possibly throttling subsequent executions.
This can also be specified as an HTTP parameter.
| `watch` | no | null | When present, this
{stack-ov}/how-watcher-works.html#watch-definition[watch] is used
| `watch` | no | null | When present, this <<watch-definition,watch>> is used
instead of the one specified in the request. This watch is
not persisted to the index and record_execution cannot be set.
|======
@ -99,7 +98,7 @@ are five possible modes an action can be associated with:
| `simulate` | The action execution is simulated. Each action type
define its own simulation operation mode. For example, the
{stack-ov}/actions-email.html[email] action creates
<<actions-email,`email` action>> creates
the email that would have been sent but does not actually
send it. In this mode, the action might be throttled if the
current state of the watch indicates it should be.

14
x-pack/docs/en/rest-api/watcher/put-watch.asciidoc
View File

@ -32,8 +32,8 @@ IMPORTANT: You must use {kib} or this API to create a watch. Do not put a watch
privileges on the `.watches` index.
When adding a watch you can also define its initial
{stack-ov}/how-watcher-works.html#watch-active-state[active state]. You do that
by setting the `active` parameter.
<<watch-active-state,active state>>. You do that by setting the `active`
parameter.
[[watcher-api-put-watch-security]]
===== Security integration
@ -65,16 +65,16 @@ A watch has the following fields:
|======
| Name | Description
| `trigger` | The {stack-ov}/trigger.html[trigger] that defines when
| `trigger` | The <<trigger,trigger>> that defines when
the watch should run.
| `input` | The {stack-ov}/input.html[input] that defines the input
| `input` | The <<input,input>> that defines the input
that loads the data for the watch.
| `condition` | The {stack-ov}/condition.html[condition] that defines if
| `condition` | The <<condition,condition>> that defines if
the actions should be run.
| `actions` | The list of {stack-ov}/actions.html[actions] that will be
| `actions` | The list of <<actions,actions>> that will be
run if the condition matches
| `metadata` | Metadata json that will be copied into the history entries.
@ -163,7 +163,7 @@ PUT _watcher/watch/my-watch
--------------------------------------------------
When you add a watch you can also define its initial
{stack-ov}/how-watcher-works.html#watch-active-state[active state]. You do that
<<watch-active-state,active state>>. You do that
by setting the `active` parameter. The following command adds a watch and sets
it to be inactive by default:

17
x-pack/docs/en/watcher/actions.asciidoc
View File

@ -3,7 +3,7 @@
== Actions
When a watch's condition is met, its actions are executed unless it is being
<<actions-ack-throttle, throttled>>. A watch can perform multiple actions.
<<actions-ack-throttle,throttled>>. A watch can perform multiple actions.
The actions are executed one at a time and each action executes independently.
Any failures encountered while executing an action are recorded in the
action result and in the watch history.
@ -16,13 +16,13 @@ support their execution in any way they need. For example, the payload might
serve as a model for a templated email body.
{watcher} supports the following types of actions:
<<actions-email, email>>, <<actions-webhook, webhook>>, <<actions-index, index>>,
<<actions-logging, logging>>, <<actions-slack, Slack>>,
and <<actions-pagerduty, pagerduty>>.
<<actions-email,`email`>>, <<actions-webhook,`webhook`>>, <<actions-index,`index`>>,
<<actions-logging,`logging`>>, <<actions-slack,`slack`>>,
and <<actions-pagerduty,`pagerduty`>>.
[float]
[[actions-ack-throttle]]
=== Acknowledgement and Throttling
=== Acknowledgement and throttling
During the watch execution, once the condition is met, a decision is made per
configured action as to whether it should be throttled. The main purpose of
@ -94,7 +94,7 @@ PUT _watcher/watch/error_logs_alert
<1> There will be at least 15 minutes between subsequent `email_administrator`
action executions.
<2> See <<actions-email, Email Action>> for more information.
<2> See <<actions-email>> for more information.
You can also define a throttle period at the watch level. The watch-level
throttle period serves as the default throttle period for all of the actions
@ -165,15 +165,14 @@ xpack.watcher.execution.default_throttle_period: 15m
--------------------------------------------------
{watcher} also supports acknowledgement-based throttling. You can acknowledge a
watch using the {ref}/watcher-api-ack-watch.html[Ack Watch API] to prevent the
watch using the <<watcher-api-ack-watch,ack watch API>> to prevent the
watch actions from being executed again while the watch condition remains `true`.
This essentially tells {watcher} "I received the notification and I'm handling
it, please do not notify me about this error again". An acknowledged watch action
remains in the `acked` state until the watch's condition evaluates to `false`.
When that happens, the action's state changes to `awaits_successful_execution`.
To acknowledge an action, you use the
{ref}/watcher-api-ack-watch.html[Ack Watch API]:
To acknowledge an action, you use the <<watcher-api-ack-watch,ack watch API>>:
[source,console]
----------------------------------------------------------------------

39
x-pack/docs/en/watcher/actions/email.asciidoc
View File

@ -1,6 +1,6 @@
[role="xpack"]
[[actions-email]]
=== Email Action
=== Email action
Use the `email` action to send email notifications. To send email, you must
<<configuring-email, configure at least one email account>> in
@ -16,7 +16,7 @@ account configuration. The required attributes must either be set in the email
action definition or the account's `email_defaults`.
[[configuring-email-actions]]
==== Configuring Email Actions
==== Configuring email actions
You configure email actions in the `actions` array. Action-specific attributes
are specified using the `email` keyword.
@ -48,7 +48,7 @@ the watch payload in the email body:
account configuration.
[[configuring-email-attachments]]
==== Configuring Email Attachments
==== Configuring email attachments
You can attach the execution context payload or data from an any HTTP service to
the email notification. There is no limit on the number of attachments you can
@ -152,20 +152,15 @@ killed by firewalls or load balancers in-between.
[[email-action-reports]]
===== Attaching Reports to an Email
===== Attaching reports to an email
You can use the `reporting` attachment type in an `email` action to automatically
generate a Kibana report and distribute it via email.
include::{kib-repo-dir}/user/reporting/watch-example.asciidoc[]
include::{kib-repo-dir}/user/reporting/report-intervals.asciidoc[]
For more information, see
{kibana-ref}/automating-report-generation.html[Automating Report Generation].
See {kibana-ref}/automating-report-generation.html[Automating report generation].
[[email-action-attributes]]
==== Email Action Attributes
==== Email action attributes
[cols=",^,,", options="header"]
|======
@ -250,7 +245,7 @@ A list of addresses can be specified as a an
array: `[ 'Personal Name <user1@host.domain>', 'user2@host.domain' ]`.
[[configuring-email]]
==== Configuring Email Accounts
==== Configuring email accounts
{watcher} can send email using any SMTP email service. Email
messages can contain basic HTML tags. You can control which groups of tags are
@ -279,14 +274,14 @@ email system.
For more information about configuring {watcher} to work with different email
systems, see:
* <<gmail, Sending Email from Gmail>>
* <<outlook, Sending Email from Outlook>>
* <<exchange, Sending Email from Exchange>>
* <<amazon-ses, Sending Email from Amazon SES>>
* <<gmail>>
* <<outlook>>
* <<exchange>>
* <<amazon-ses>>
If you configure multiple email accounts, you must either configure a default
account or specify which account the email should be sent with in the
<<actions-email, `email`>> action.
<<actions-email,`email`>> action.
[source,yaml]
--------------------------------------------------
@ -301,7 +296,7 @@ xpack.notification.email:
[float]
[[gmail]]
===== Sending Email From Gmail
===== Sending email from Gmail
Use the following email account settings to send email from the
https://mail.google.com[Gmail] SMTP service:
@ -339,7 +334,7 @@ for more information.
[float]
[[outlook]]
===== Sending Email from Outlook.com
===== Sending email from Outlook.com
Use the following email account settings to send email action from the
https://www.outlook.com/[Outlook.com] SMTP service:
@ -375,7 +370,7 @@ NOTE: You need to use a unique App Password if two-step verification is enable
[float]
[[amazon-ses]]
===== Sending Email from Amazon SES (Simple Email Service)
===== Sending email from Amazon SES (Simple Email Service)
Use the following email account settings to send email from the
http://aws.amazon.com/ses[Amazon Simple Email Service] (SES) SMTP service:
@ -412,7 +407,7 @@ NOTE: You need to use your Amazon SES SMTP credentials to send email through
[float]
[[exchange]]
===== Sending Email from Microsoft Exchange
===== Sending email from Microsoft Exchange
Use the following email account settings to send email action from Microsoft
Exchange:
@ -447,7 +442,7 @@ bin/elasticsearch-keystore add xpack.notification.email.account.exchange_account
[float]
[[email-html-sanitization]]
===== Configuring HTML Sanitization Options
===== Configuring HTML sanitization options
The `email` action supports sending messages with an HTML body. However, for
security reasons, {watcher} https://en.wikipedia.org/wiki/HTML_sanitization[sanitizes]

12
x-pack/docs/en/watcher/actions/index.asciidoc
View File

@ -1,11 +1,11 @@
[role="xpack"]
[[actions-index]]
=== Index Action
=== Index action
Use the `index` action to index data into Elasticsearch.
See <<index-action-attributes>> for the supported attributes.
==== Configuring Index Actions
==== Configuring index actions
The following snippet shows a simple `index` action definition:
@ -24,14 +24,14 @@ The following snippet shows a simple `index` action definition:
--------------------------------------------------
// NOTCONSOLE
<1> The id of the action
<2> An optional <<condition, condition>> to restrict action execution
<3> An optional <<transform, transform>> to transform the payload and prepare the data that should be indexed
<2> An optional <<condition,condition>> to restrict action execution
<3> An optional <<transform,transform>> to transform the payload and prepare the data that should be indexed
<4> The elasticsearch index to store the data to
<5> An optional `_id` for the document, if it should always be the same document.
[[index-action-attributes]]
==== Index Action Attributes
==== Index action attributes
[options="header"]
|======
@ -56,7 +56,7 @@ The following snippet shows a simple `index` action definition:
|======
[[anatomy-actions-index-multi-doc-support]]
==== Multi-Document Support
==== Multi-document support
Like with all other actions, you can use a <<transform, transform>> to replace
the current execution context payload with another and by that change the document

12
x-pack/docs/en/watcher/actions/jira.asciidoc
View File

@ -1,12 +1,12 @@
[role="xpack"]
[[actions-jira]]
=== Jira Action
=== Jira action
Use the `jira` action to create issues in https://www.atlassian.com/software/jira[Atlassian's Jira Software].
To create issues you need to <<configuring-jira, configure at least one Jira account>> in `elasticsearch.yml`.
[[configuring-jira-actions]]
==== Configuring Jira Actions
==== Configuring Jira actions
You configure Jira actions in the `actions` array. Action-specific attributes
are specified using the `jira` keyword.
@ -49,7 +49,7 @@ The following snippet shows a simple jira action definition:
<7> The priority of the Jira issue.
[[jira-action-attributes]]
==== Jira Action Attributes
==== Jira action attributes
Depending of how Jira projects are configured, the issues can have many different fields and values. Therefore
the `jira` action can accept any type of sub fields within its `issue` field. These fields will be directly used
@ -100,7 +100,7 @@ always required to create an issue in Jira.
|======
[[configuring-jira]]
==== Configuring Jira Accounts
==== Configuring Jira accounts
You configure the accounts {watcher} can use to communicate with Jira in the
`xpack.notification.jira` namespace in `elasticsearch.yml`.
@ -141,7 +141,7 @@ WARNING: It is strongly advised to use Basic Authentication with secured HTTPS
protocol only.
You can also specify defaults for the
{ref}/notification-settings.html#jira-account-attributes[Jira issues]:
<<jira-account-attributes,Jira issues>>:
[source,yaml]
--------------------------------------------------
@ -159,7 +159,7 @@ xpack.notification.jira:
If you configure multiple Jira accounts, you either need to configure a default
account or specify which account the notification should be sent with in the
<<actions-jira, jira>> action.
<<actions-jira,`jira`>> action.
[source,yaml]
--------------------------------------------------

4
x-pack/docs/en/watcher/actions/logging.asciidoc
View File

@ -8,7 +8,7 @@ logs. See <<logging-action-attributes>> for the supported attributes.
This action is primarily used during development and for debugging purposes.
[[configuring-logging-actions]]
==== Configuring Logging Actions
==== Configuring logging actions
You configure logging actions in the `actions` array. Action-specific attributes
are specified using the `logging` keyword.
@ -34,7 +34,7 @@ The following snippet shows a simple logging action definition:
[[logging-action-attributes]]
==== Logging Action Attributes
==== Logging action attributes
[options="header"]
|======

22
x-pack/docs/en/watcher/actions/pagerduty.asciidoc
View File

@ -1,13 +1,13 @@
[role="xpack"]
[[actions-pagerduty]]
=== PagerDuty Action
=== PagerDuty action
Use the PagerDuty action to create events in https://pagerduty.com/[
PagerDuty]. To create PagerDuty events, you must <<configuring-pagerduty,
configure at least one PagerDuty account>> in `elasticsearch.yml`.
[[configuring-pagerduty-actions]]
==== Configuring PagerDuty Actions
==== Configuring PagerDuty actions
You configure PagerDuty actions in the `actions` array. Action-specific attributes
are specified using the `pagerduty` keyword.
@ -31,7 +31,7 @@ The following snippet shows a simple PagerDuty action definition:
[[adding-context-and-payloads-to-pagerduty-actions]]
==== Adding Meta Information to a PagerDuty Incident
==== Adding meta information to a PagerDuty incident
To give the PagerDuty incident some more context, you can attach the
payload as well as an array of contexts to the action.
@ -65,7 +65,7 @@ payload as well as an array of contexts to the action.
[[pagerduty-action-attributes]]
==== Pagerduty Action Attributes
==== Pagerduty action attributes
[cols=",^,", options="header"]
|======
@ -76,7 +76,7 @@ payload as well as an array of contexts to the action.
[[pagerduty-event-trigger-incident-attributes]]
.Pagerduty Event Trigger Incident Attributes
.Pagerduty event trigger incident attributes
[cols=",^,", options="header"]
|======
| Name |Required | Description
@ -115,7 +115,7 @@ NOTE: All of those objects have templating support, so you can use data from the
context and the payload as part of all the fields.
[[pagerduty-event-trigger-context-attributes]]
.Pagerduty Event Trigger Context Attributes
.Pagerduty event trigger context attributes
[cols=",^,", options="header"]
|======
| Name |Required | Description
@ -129,7 +129,7 @@ NOTE: All of those objects have templating support, so you can use data from the
|======
[[configuring-pagerduty]]
==== Configuring PagerDuty Accounts
==== Configuring PagerDuty accounts
You configure the accounts {watcher} uses to communicate with PagerDuty in
the `xpack.notification.pagerduty` namespace in `elasticsearch.yml`.
@ -149,7 +149,7 @@ image::images/pagerduty-services.jpg[]
image::images/pagerduty-integrations.jpg[]
To configure a PagerDuty account in the keystore, you
must specify an account name and integration key, (see {ref}/secure-settings.html[secure settings]):
must specify an account name and integration key, (see <<secure-settings>>):
[source,yaml]
--------------------------------------------------
@ -158,8 +158,8 @@ bin/elasticsearch-keystore add xpack.notification.pagerduty.account.my_pagerduty
deprecated[7.0.0, "Storing the service api key in the YAML file or via cluster update settings is still supported, but the keystore setting should be used."]
You can also specify defaults for the <<pagerduty-event-trigger-incident-attributes,
PagerDuty event attributes>>:
You can also specify defaults for the
<<pagerduty-event-trigger-incident-attributes,PagerDuty event attributes>>:
.
[source,yaml]
@ -178,7 +178,7 @@ xpack.notification.pagerduty:
If you configure multiple PagerDuty accounts, you either need to set a default
account or specify which account the event should be sent with in the
<<actions-pagerduty, `pagerduty`>> action.
<<actions-pagerduty,`pagerduty`>> action.
[source,yaml]
--------------------------------------------------

18
x-pack/docs/en/watcher/actions/slack.asciidoc
View File

@ -4,11 +4,11 @@
Use the `slack` action to send messages to a https://slack.com/[Slack]
team's channels or users. To send Slack messages, you need to
<<configuring-slack, configure at least one Slack account>> in
<<configuring-slack,configure at least one Slack account>> in
`elasticsearch.yml`.
[[configuring-slack-actions]]
==== Configuring Slack Actions
==== Configuring Slack actions
You configure Slack actions in the `actions` array. Action-specific attributes
are specified using the `slack` keyword.
@ -36,7 +36,7 @@ The following snippet shows a simple slack action definition:
[[formatting-slack-messages]]
==== Using Attachments to Format Slack Messages
==== Using attachments to format Slack messages
In addition to sending simple text-based messages, you can use the Slack
https://api.slack.com/docs/attachments[attachment] mechanism to send formatted
@ -140,7 +140,7 @@ aggregation and the Slack action:
generated by the transform.
[[slack-action-attributes]]
==== Slack Action Attributes
==== Slack action attributes
[cols=",^,", options="header"]
|======
@ -168,7 +168,7 @@ aggregation and the Slack action:
| `message.dynamic_attachments` | no | Slack message attachments that can be populated
dynamically based on the current watch payload. For
more information, see
<<slack-dynamic-attachment, Using Attachments to Format Slack Messages>>.
<<slack-dynamic-attachment>>.
| `proxy.host` | no | The proxy host to use (only in combination with `proxy.port`)
@ -207,11 +207,11 @@ bin/elasticsearch-keystore add xpack.notification.slack.account.monitoring.secur
[WARNING]
======
You can no longer configure Slack accounts using `elasticsearch.yml` settings.
Please use {es}'s secure {ref}/secure-settings.html[keystore] method instead.
Please use {es}'s secure <<secure-settings,keystore>> method instead.
======
You can specify defaults for the {ref}/notification-settings.html#slack-account-attributes[Slack
notification attributes]:
You can specify defaults for the
<<slack-account-attributes,Slack notification attributes>>:
[source,yaml]
--------------------------------------------------
@ -233,7 +233,7 @@ xpack.notification.slack:
If you configure multiple Slack accounts, you either need to configure a default
account or specify which account the notification should be sent with in the
<<actions-slack, slack>> action.
<<actions-slack,`slack`>> action.
[source,yaml]
--------------------------------------------------

26
x-pack/docs/en/watcher/actions/webhook.asciidoc
View File

@ -1,14 +1,13 @@
[role="xpack"]
[[actions-webhook]]
=== Webhook Action
=== Webhook action
Use the `webhook` action to send a request to any web service. The
webhook action supports both HTTP and HTTPS connections. See
<<webhook-action-attributes, Webhook Action Attributes>> for the supported
attributes.
<<webhook-action-attributes>> for the supported attributes.
[[configuring-webook-actions]]
==== Configuring Webhook Actions
==== Configuring webhook actions
You configure webhook actions in the `actions` array. Action-specific attributes
are specified using the `webhook` keyword.
@ -33,9 +32,9 @@ The following snippet shows a simple webhook action definition:
--------------------------------------------------
// NOTCONSOLE
<1> The id of the action
<2> An optional <<transform, transform>> to transform the payload before
<2> An optional <<transform,transform>> to transform the payload before
executing the `webhook` action
<3> An optional <<actions-ack-throttle, throttle period>> for the action
<3> An optional <<actions-ack-throttle,throttle period>> for the action
(5 minutes in this example)
<4> The HTTP method to use when connecting to the host
<5> The host to connect to
@ -77,8 +76,9 @@ NOTE: By default, both the username and the password are stored in the `.watches
You can also use PKI-based authentication when submitting requests to a cluster
that has {es} {security-features} enabled. When you use PKI-based authentication
instead of HTTP basic auth, you don't need to store any authentication
information in the watch itself. To use PKI-based authentication, you {ref}/notification-settings.html#ssl-notification-settings
[configure the SSL key settings] for {watcher} in `elasticsearch.yml`.
information in the watch itself. To use PKI-based authentication, you
<<ssl-notification-settings,configure the SSL key settings>> for {watcher} in
`elasticsearch.yml`.
[[webhook-query-parameters]]
@ -136,7 +136,7 @@ the values serve as the header values:
<1> The header values can contain templated strings.
==== Webhook Action Attributes
==== Webhook action attributes
[[webhook-action-attributes]]
[cols=",^,^,", options="header"]
|======
@ -149,23 +149,23 @@ the values serve as the header values:
| `port` | yes | - | The port the HTTP service is listening on.
| `path` | no | - | The URL path. The path can be static text or include Mustache
<<templates, templates>>. URL query string parameters must be
<<templates,templates>>. URL query string parameters must be
specified via the `request.params` attribute.
| `method` | no | get | The HTTP method. Valid values are: `head`, `get`, `post`, `put`
and `delete`.
| `headers` | no | - | The HTTP request headers. The header values can be static text
or include Mustache <<templates, templates>>.
or include Mustache <<templates,templates>>.
| `params` | no | - | The URL query string parameters. The parameter values can be
static text or include Mustache <<templates, templates>>.
static text or include Mustache <<templates,templates>>.
| `auth` | no | - | Authentication related HTTP headers. Currently, only basic
authentication is supported.
| `body` | no | - | The HTTP request body. The body can be static text or include
Mustache <<templates, templates>>. When not specified, an empty
Mustache <<templates,templates>>. When not specified, an empty
body is sent.
| `proxy.host` | no | - | The proxy host to use when connecting to the host.

16
x-pack/docs/en/watcher/condition.asciidoc
View File

@ -5,29 +5,29 @@
When a watch is triggered, its condition determines whether or not to execute
the watch actions. {watcher} supports the following condition types:
* <<condition-always, `always`>>: set the watch condition to `true` so the watch
* <<condition-always,`always`>>: set the watch condition to `true` so the watch
actions are always executed.
* <<condition-never, `never`>>: set the watch condition to `false` so the watch
* <<condition-never,`never`>>: set the watch condition to `false` so the watch
actions are never executed.
* <<condition-compare, `compare`>>: perform simple comparisons against values
* <<condition-compare,`compare`>>: perform simple comparisons against values
in the watch payload to determine whether or not to execute the watch actions.
* <<condition-array-compare, `array_compare`>>: compare an array of values in the
* <<condition-array-compare,`array_compare`>>: compare an array of values in the
watch payload to a given value to determine whether or not to execute the watch
actions.
* <<condition-script, `script`>>: use a script to determine whether or not to
* <<condition-script,`script`>>: use a script to determine whether or not to
execute the watch actions.
NOTE: If you omit the condition definition from a watch, the condition defaults
to `always`.
When a condition is evaluated, it has full access to the watch execution context,
including the watch payload (`ctx.payload.*`). The <<condition-script, script>>,
<<condition-compare, compare>> and <<condition-array-compare, array_compare>>
including the watch payload (`ctx.payload.*`). The <<condition-script,script>>,
<<condition-compare,compare>> and <<condition-array-compare,array_compare>>
conditions can use the payload data to determine whether or not the necessary
conditions are met.
In addition to the watch wide condition, you can also configure conditions
per <<action-conditions, action>>.
per <<action-conditions,action>>.
include::condition/always.asciidoc[]

6
x-pack/docs/en/watcher/condition/always.asciidoc
View File

@ -1,15 +1,15 @@
[role="xpack"]
[[condition-always]]
=== Always Condition
=== Always condition
Use the `always` condition to set the condition to `true`. This forces the watch
actions to be executed unless they are <<actions-ack-throttle, throttled>>.
actions to be executed unless they are <<actions-ack-throttle,throttled>>.
The `always` condition enables you to perform watch actions on a fixed schedule,
such as, _"Every Friday at noon, send a status report email to
sys.admin@example.com."_
==== Using the Always Condition
==== Using the always condition
This is the default if you omit the condition definition from a watch.

20
x-pack/docs/en/watcher/condition/array-compare.asciidoc
View File

@ -1,20 +1,20 @@
[role="xpack"]
[[condition-array-compare]]
=== Array Compare Condition
=== Array compare condition
Use `array_compare` to compare an array of values in the execution context to a
given value. See <<condition-compare-operators, Supported Comparison Operators>>
given value. See <<condition-compare-operators>>
for the operators you can use.
==== Using an Array Compare Condition
==== Using an array compare condition
To use the `array_compare` condition, you specify the array in the execution
context that you want to evaluate, a <<condition-compare-operators,comparison
operator>>, and the value you want to compare against. Optionally, you
can specify the path to the field in each array element that you want to
evaluate.
context that you want to evaluate, a
<<condition-compare-operators,comparison operator>>, and the value you want to
compare against. Optionally, you can specify the path to the field in each array
element that you want to evaluate.
For example, the following `array_compare` condition returns `true` if there
is at least one bucket in the aggregation that has a `doc_count` greater
@ -39,14 +39,14 @@ than or equal to 25:
<1> The path to the array in the execution
context that you want to evaluate, specified in dot notation.
<2> The path to the field in each array element that you want to evaluate.
<3> The <<condition-compare-operators, comparison operator>> to use.
<3> The <<condition-compare-operators,comparison operator>> to use.
<4> The comparison value. Supports date math like the
<<compare-condition-date-math, compare condition>>.
<<compare-condition-date-math,compare condition>>.
NOTE: When using fieldnames that contain a dot this condition will not
work, use a <<condition-script,script condition>> instead.
==== Array-Compare Condition Attributes
==== Array-compare condition attributes
[options="header"]
|======

12
x-pack/docs/en/watcher/condition/compare.asciidoc
View File

@ -1,13 +1,13 @@
[role="xpack"]
[[condition-compare]]
=== Compare Condition
=== Compare condition
Use the `compare` condition to perform a simple comparison against a value in
the watch payload. You can use the `compare` condition without enabling
dynamic scripting.
[[condition-compare-operators]]
. Supported Comparison Operators
. Supported comparison operators
[options="header"]
|======
| Name | Description
@ -31,13 +31,13 @@ dynamic scripting.
given one (applies to numeric and string values)
|======
==== Using a Compare Condition
==== Using a compare condition
To use the `compare` condition, you specify the value in the execution context
that you want to evaluate, a <<condition-compare-operators,comparison operator>>,
and the value you want to compare against. For example, the following `compare`
condition returns `true` if the number of the total hits in the <<input-search,
search result>> is greater than or equal to 5:
condition returns `true` if the number of the total hits in the
<<input-search,search result>> is greater than or equal to 5:
[source,js]
--------------------------------------------------
@ -93,7 +93,7 @@ to the `ctx.payload.aggregations.handled.buckets.true.doc_count`:
--------------------------------------------------
// NOTCONSOLE
==== Accessing Values in the Execution Context
==== Accessing values in the execution context
You use "dot-notation" to access values in the execution context. Values loaded
into the execution context by the input are prefixed by `ctx.payload`.

4
x-pack/docs/en/watcher/condition/never.asciidoc
View File

@ -1,13 +1,13 @@
[role="xpack"]
[[condition-never]]
=== Never Condition
=== Never condition
Use the `never` condition to set the condition to `false`. This means the
watch actions are never executed when the watch is triggered. The watch input is
executed, a record is added to the watch history, and the watch execution ends.
This condition is generally used for testing.
==== Using the Never Condition
==== Using the never condition
There are no attributes to specify for the `never` condition. To use the it,
you specify the condition type and associate it with an empty object:

34
x-pack/docs/en/watcher/condition/script.asciidoc
View File

@ -1,15 +1,14 @@
[role="xpack"]
[[condition-script]]
=== Script Condition
=== Script condition
A watch <<condition, condition>> that evaluates a script. The default scripting
A watch <<condition,condition>> that evaluates a script. The default scripting
language is `painless`. You can use any of the scripting languages supported by
Elasticsearch as long as the language supports evaluating expressions to Boolean
values. Note that the `mustache` and `expression` languages are too limited to be
used by this condition. For more information, see {ref}/modules-scripting.html[Scripting]
in the Elasticsearch Reference.
used by this condition. For more information, see <<modules-scripting>>.
==== Using a Script Condition
==== Using a script condition
The following snippet configures an inline `script` condition that always returns
`true`:
@ -23,11 +22,11 @@ The following snippet configures an inline `script` condition that always return
// NOTCONSOLE
This example defines a script as a simple string. This format is actually a
shortcut for defining an <<condition-script-inline, inline>> script. The
shortcut for defining an <<condition-script-inline,inline>> script. The
formal definition of a script is an object that specifies the script type and
optional language and parameter values. If the `lang` attribute is omitted, the
language defaults to `painless`. Elasticsearch supports two types of scripts,
<<condition-script-inline, Inline>> and <<condition-script-stored, Stored>>.
<<condition-script-inline,inline>> and <<condition-script-stored,stored>>.
For example, the following snippet shows a formal definition of an `inline`
script that explicitly specifies the language and defines a single script
@ -48,7 +47,7 @@ parameter, `result`:
// NOTCONSOLE
[[condition-script-inline]]
==== Inline Scripts
==== Inline scripts
Inline scripts are scripts that are defined in the condition itself. The
following snippet shows the formal configuration of a simple painless script that
@ -65,10 +64,11 @@ always returns `true`.
// NOTCONSOLE
[[condition-script-stored]]
==== Stored Scripts
==== Stored scripts
Stored scripts refer to scripts that were {ref}/modules-scripting-using.html#modules-scripting-stored-scripts[stored]
in Elasticsearch. The following snippet shows how to refer to a script by its `id`:
Stored scripts refer to scripts that were
<<modules-scripting-stored-scripts,stored>> in Elasticsearch. The following
snippet shows how to refer to a script by its `id`:
[source,js]
--------------------------------------------------
@ -80,8 +80,8 @@ in Elasticsearch. The following snippet shows how to refer to a script by its `i
--------------------------------------------------
// NOTCONSOLE
As with <<condition-script-inline, Inline>>
scripts, you can also specify the script language and parameters:
As with <<condition-script-inline,inline>> scripts, you can also specify the
script language and parameters:
[source,js]
--------------------------------------------------
@ -96,14 +96,14 @@ scripts, you can also specify the script language and parameters:
// NOTCONSOLE
[[accessing-watch-payload]]
==== Accessing the Watch Payload
==== Accessing the watch payload
A script can access the current watch execution context, including the payload
data, as well as any parameters passed in through the condition definition.
For example, the following snippet defines a watch that uses a <<input-search, `search` input>>
and uses a `script` condition to check if the number of hits is above a specified
threshold:
For example, the following snippet defines a watch that uses a
<<input-search,`search` input>> and uses a `script` condition to check if the
number of hits is above a specified threshold:
[source,js]
--------------------------------------------------

69
x-pack/docs/en/watcher/customizing-watches.asciidoc
View File

@ -1,30 +1,31 @@
[role="xpack"]
[[customizing-watches]]
== Customizing Watches
== Customizing watches
Now that you've seen how to set up simple watches to <<watch-log-data, watch your log data>>
and <<watch-cluster-status, monitor your cluster health>>, let's take a closer
look at how you can customize a watch by modifying its <<changing-inputs, inputs>>,
<<changing-conditions, conditions>>, <<using-transforms, transforms>>, and
<<customizing-actions, actions>>.
Now that you've seen how to set up simple watches to
<<watch-log-data,watch your log data>> and
<<watch-cluster-status,monitor your cluster health>>, let's take a closer
look at how you can customize a watch by modifying its <<changing-inputs,inputs>>,
<<changing-conditions,conditions>>, <<using-transforms,transforms>>, and
<<customizing-actions,actions>>.
[[changing-inputs]]
=== Changing Inputs
=== Changing inputs
The Watch Input is called when the watch triggered to load an initial payload.
This payload is stored in the _Watch Execution Context_ and from then on is
available for other watch elements to access (e.g. watch conditions can
be evaluated based on the data in this payload).
{watcher} supports four types of inputs <<loading-static-data, simple>>,
<<loading-search-results, search>>, <<loading-http-data, http>>, and
<<input-chain, chain>>.
{watcher} supports four types of inputs <<loading-static-data,simple>>,
<<loading-search-results,search>>, <<loading-http-data,http>>, and
<<input-chain,chain>>.
[[loading-static-data]]
==== Loading a Static Payload with the Simple Input
==== Loading a static payload with the simple input
To load static data into the watch payload for testing purposes, you can use the
<<input-simple, simple>> input. For example, the following input stores three
<<input-simple,simple>> input. For example, the following input stores three
fields in the payload:
[source,js]
@ -42,13 +43,13 @@ fields in the payload:
See <<input-simple>> for more details.
[[loading-search-results]]
==== Loading a Payload from Elasticsearch with the Search Input
==== Loading a payload from Elasticsearch with the search input
You can use the `search` input to load Elasticsearch search results as the watch
initial payload.
A <<input-search, search>> input contains a `request` object that specifies the
indices you want to search, the {ref}/search-request-body.html#request-body-search-search-type[search type],
A <<input-search,search>> input contains a `request` object that specifies the
indices you want to search, the <<request-body-search-search-type,search type>>,
and the search request body. The `body` field of a search input is the same as
the body of an Elasticsearch `_search` request, making the full Elasticsearch
Query DSL available for you to use.
@ -82,7 +83,7 @@ For example, the following `search` input loads the latest VIX quote:
See <<input-search>> for more details.
[[loading-http-data]]
==== Loading a Payload from a remote HTTP Service with HTTP Input
==== Loading a payload from a remote HTTP service with HTTP input
Use the `http` input to issue an HTTP request and load the returned response as
the watch initial payload. This input expects the response body content type
@ -112,28 +113,28 @@ Amsterdam using http://openweathermap.org/appid[OpenWeatherMap] online service:
See <<input-http>> for more details.
[[chaining-inputs]]
==== Chaining Inputs
==== Chaining inputs
You can create an <<input-chain, input chain>> to load data from multiple sources
You can create an <<input-chain,input chain>> to load data from multiple sources
into a watch payload. The inputs in a chain are processed in order, so the the
data loaded by one input can be used by subsequent inputs.
See <<input-chain>> for more details.
[[changing-conditions]]
=== Changing Conditions
=== Changing conditions
The Watch Condition is evaluated as part of the watch execution. The condition
determines whether the actions associated with the watch should execute or not.
{watcher} supports four types of conditions <<condition-always, always>>,
<<condition-never, never>>, <<condition-compare, compare>>, and
<<condition-script, script>>.
{watcher} supports four types of conditions <<condition-always,always>>,
<<condition-never,never>>, <<condition-compare,compare>>, and
<<condition-script,script>>.
The first two are pretty self-explanatory--they are shortcuts for setting a
watch's condition to `true` or `false`.
==== Simple Value Comparison with the Compare Condition
==== Simple value comparison with the compare condition
The `compare` condition enables you to perform simple comparisons against values
in the Watch payload. While you can also do this with a `script` condition, with
@ -152,7 +153,7 @@ returned any hits:
// NOTCONSOLE
See <<condition-compare>> for more details.
==== Powerful Comparison Logic with the Script Condition
==== Powerful comparison logic with the script condition
For more complex conditional logic you can use the `script` condition. The
`script` condition accepts a script that when executed returns `true` (indicating
@ -161,7 +162,7 @@ language defaults to the default script language in Elasticsearch, but you can
also use any other supported language in the system.
NOTE: Starting with 5.0, Elasticsearch is shipped with the new
{ref}/modules-scripting-painless.html[Painless] scripting language.
<<modules-scripting-painless,Painless>> scripting language.
Painless was created and designed specifically for use in Elasticsearch.
Beyond providing an extensive feature set, its biggest trait is that it's
properly sandboxed and safe to use anywhere in the system (including in
@ -183,13 +184,13 @@ VIX quote loaded by the `http` input is either greater than 5% or lower than -5%
See <<condition-script>> for more details.
[[using-transforms]]
=== Using Transforms
=== Using transforms
Transforms are constructs in a watch that can change the current payload
associated with the watch execution context.
{watcher} supports three types of transforms <<transform-search, search>>,
<<transform-script, script>> and <<transform-chain, chain>>. A `search` transform
{watcher} supports three types of transforms <<transform-search,search>>,
<<transform-script,script>> and <<transform-chain,chain>>. A `search` transform
replaces the existing payload with the response of a new search request. You can
use `script` transforms to modify the existing payload. A `chain` transform
enables you to perform a series of `search` and `script` transforms.
@ -197,19 +198,19 @@ enables you to perform a series of `search` and `script` transforms.
See <<transform>> for more details.
[[customizing-actions]]
=== Customizing Actions
=== Customizing actions
Actions are associated with a watch and are executed as part of the watch execution
only when the watch condition is met.
{watcher} supports the following action types: <<actions-email, email>>,
<<actions-slack, slack>>, <<actions-pagerduty, pagerduty>>,
<<actions-index, index>>, <<actions-logging, logging>>, and <<actions-webhook, webhook>>.
{watcher} supports the following action types: <<actions-email,email>>,
<<actions-slack,slack>>, <<actions-pagerduty,pagerduty>>,
<<actions-index,index>>, <<actions-logging,logging>>, and <<actions-webhook,webhook>>.
To use the `email` action, you need to <<configuring-email, configure an email account>>
To use the `email` action, you need to <<configuring-email,configure an email account>>
in `elasticsearch.yml` that {watcher} can use to send email. Your custom email
messages can be plain text or styled using HTML. You can include information from
the watch execution payload using <<templates, templates>>, as well as attach the
the watch execution payload using <<templates,templates>>, as well as attach the
entire watch payload to the message.
For example, the following email action uses a template in the email body and

11
x-pack/docs/en/watcher/encrypting-data.asciidoc
View File

@ -1,6 +1,6 @@
[role="xpack"]
[[encrypting-data]]
== Encrypting Sensitive Data in {watcher}
== Encrypting sensitive data in {watcher}
Watches might have access to sensitive data such as HTTP basic authentication
information or details about your SMTP email service. You can encrypt this
@ -15,7 +15,7 @@ encrypted.
To encrypt sensitive data in {watcher}:
. Use the {ref}/syskeygen.html[elasticsearch-syskeygen] command to create a system key file.
. Use the <<syskeygen,elasticsearch-syskeygen>> command to create a system key file.
. Copy the `system_key` file to all of the nodes in your cluster.
+
@ -25,8 +25,7 @@ every node in the cluster.
--
. Set the
{ref}/notification-settings.html[`xpack.watcher.encrypt_sensitive_data` setting]:
. Set the <<notification-settings,`xpack.watcher.encrypt_sensitive_data` setting>>:
+
--
@ -37,8 +36,8 @@ xpack.watcher.encrypt_sensitive_data: true
--
. Set the
{ref}/notification-settings.html[`xpack.watcher.encryption_key` setting] in the
{ref}/secure-settings.html[{es} keystore] on each node in the cluster.
<<notification-settings,`xpack.watcher.encryption_key` setting>> in the
<<secure-settings,{es} keystore>> on each node in the cluster.
+
--
For example, run the following command to import the `system_key` file on

8
x-pack/docs/en/watcher/example-watches.asciidoc
View File

@ -1,14 +1,14 @@
[role="xpack"]
[[example-watches]]
== Example Watches
== Example watches
The following examples show how to set up watches to:
* <<watch-cluster-status, Monitor the Status of an Elasticsearch Cluster>>
* <<watching-meetup-data, Monitor Event Data>>
* <<watch-cluster-status,Monitor the status of an Elasticsearch cluster>>
* <<watching-meetup-data,Monitor event data>>
For more example watches you can use as a starting point for building custom
watches, see the https://github.com/elastic/examples/tree/master/Alerting[Example
Watches] in the Elastic Examples repo.
watches] in the Elastic Examples repo.
include::example-watches/example-watch-clusterstatus.asciidoc[]

40
x-pack/docs/en/watcher/example-watches/example-watch-clusterstatus.asciidoc
View File

@ -1,24 +1,24 @@
[role="xpack"]
[[watch-cluster-status]]
=== Watching the Status of an Elasticsearch Cluster
=== Watching the status of an Elasticsearch cluster
You can easily configure a basic watch to monitor the health of your
Elasticsearch cluster:
* <<health-add-input, Schedule the watch and define an input>> that gets the
* <<health-add-input,Schedule the watch and define an input>> that gets the
cluster health status.
* <<health-add-condition, Add a condition>> that evaluates the health status to
* <<health-add-condition,Add a condition>> that evaluates the health status to
determine if action is required.
* <<health-take-action, Take action>> if the cluster is RED.
* <<health-take-action,Take action>> if the cluster is RED.
[float]
[[health-add-input]]
==== Schedule the Watch and Add an Input
==== Schedule the watch and add an input
A watch <<trigger-schedule, schedule>> controls how often a watch is triggered.
The watch <<input, input>> gets the data that you want to evaluate.
A watch <<trigger-schedule,schedule>> controls how often a watch is triggered.
The watch <<input,input>> gets the data that you want to evaluate.
The simplest way to define a schedule is to specify an interval. For example,
the following schedule runs every 10 seconds:
@ -48,7 +48,7 @@ GET _cluster/health?pretty
// TEST[continued]
To load the health status into your watch, you simply add an
<<input-http, HTTP input>> that calls the cluster health API:
<<input-http,HTTP input>> that calls the cluster health API:
[source,console]
--------------------------------------------------
@ -69,7 +69,8 @@ PUT _watcher/watch/cluster_health_watch
}
--------------------------------------------------
If you're using Security, then you'll also need to supply some authentication credentials as part of the watch configuration:
If you're using Security, then you'll also need to supply some authentication
credentials as part of the watch configuration:
[source,console]
--------------------------------------------------
@ -96,9 +97,12 @@ PUT _watcher/watch/cluster_health_watch
}
--------------------------------------------------
It would be a good idea to create a user with the minimum privileges required for use with such a watch configuration.
It would be a good idea to create a user with the minimum privileges required
for use with such a watch configuration.
Depending on how your cluster is configured, there may be additional settings required before the watch can access your cluster such as keystores, truststores or certificates. For more information, see {ref}/notification-settings.html[Notification Settings].
Depending on how your cluster is configured, there may be additional settings
required before the watch can access your cluster such as keystores, truststores,
or certificates. For more information, see <<notification-settings>>.
If you check the watch history, you'll see that the cluster status is recorded
@ -120,9 +124,9 @@ GET .watcher-history*/_search
[float]
[[health-add-condition]]
==== Add a Condition
==== Add a condition
A <<condition, condition>> evaluates the data you've loaded into the watch and
A <<condition,condition>> evaluates the data you've loaded into the watch and
determines if any action is required. Since you've defined an input that loads
the cluster status into the watch, you can define a condition that checks that
status.
@ -174,11 +178,11 @@ GET .watcher-history*/_search?pretty
[float]
[[health-take-action]]
==== Take Action
==== Take action
Recording `watch_records` in the watch history is nice, but the real power of
{watcher} is being able to do something in response to an alert. A watch's
<<actions, actions>> define what to do when the watch condition is true--you
<<actions,actions>> define what to do when the watch condition is true--you
can send emails, call third-party webhooks, or write documents to an
Elasticsearch index or log when the watch condition is met.
@ -246,7 +250,7 @@ xpack.notification.email.account:
NOTE: If you have advanced security options enabled for your email account,
you need to take additional steps to send email from {watcher}. For more
information, see <<configuring-email, Working with Various Email Services>>.
information, see <<configuring-email>>.
You can check the watch history or the `status_index` to see that the action was
performed.
@ -264,13 +268,13 @@ GET .watcher-history*/_search?pretty
[float]
[[health-delete]]
==== Delete the Watch
==== Delete the watch
Since the `cluster_health_watch` is configured to run every 10 seconds, make
sure you delete it when you're done experimenting. Otherwise, you'll spam yourself
indefinitely.
To remove the watch, use the {ref}/watcher-api-delete-watch.html[DELETE watch API]:
To remove the watch, use the <<watcher-api-delete-watch,delete watch API>>:
[source,console]
-------------------------------------------------------

6
x-pack/docs/en/watcher/example-watches/example-watch-meetupdata.asciidoc
View File

@ -1,6 +1,6 @@
[role="xpack"]
[[watching-meetup-data]]
=== Watching Event Data
=== Watching event data
If you are indexing event data, such as log messages, network traffic, or a web feed, you can create a watch to email notifications when certain events occur.
For example, if you index a feed of RSVPs for meetup events happening around the world, you can create a watch that alerts you to interesting events.
@ -189,7 +189,7 @@ To set up the watch:
// NOTCONSOLE
--
NOTE: To enable Watcher to send emails, you must configure an email account in `elasticsearch.yml`. For more information, see <<configuring-email, Working with Various Email Services>>.
NOTE: To enable Watcher to send emails, you must configure an email account in `elasticsearch.yml`. For more information, see <<configuring-email>>.
The complete watch looks like this:
@ -291,7 +291,7 @@ PUT _watcher/watch/meetup
}
--------------------------------------------------
<1> The email body can include Mustache templates to reference data in the watch payload. By default,it will be <<email-html-sanitization, sanitized>> to block dangerous content.
<1> The email body can include Mustache templates to reference data in the watch payload. By default,it will be <<email-html-sanitization,sanitized>> to block dangerous content.
<2> Replace the `from` address with the email address you configured in `elasticsearch.yml`.
<3> Replace the `to` address with your email address to receive notifications.

4
x-pack/docs/en/watcher/example-watches/watching-time-series-data.asciidoc
View File

@ -1,6 +1,6 @@
[role="xpack"]
[[watching-time-series-data]]
=== Watching Time Series Data
=== Watching time series data
If you are indexing time-series data such as logs, RSS feeds, or network traffic,
you can use {watcher} to send notifications when certain events occur.
@ -152,7 +152,7 @@ you can then reference it by name in the watch condition.
NOTE: To use the email action, you must configure at least one email account in
`elasticsearch.yml`. If you configure multiple email accounts, you need to
specify which one you want to send the email with. For more information, see
<<configuring-email, Working with Various Email Services>>.
<<configuring-email>>.
The complete watch looks like this:

33
x-pack/docs/en/watcher/getting-started.asciidoc
View File

@ -4,7 +4,8 @@
TIP: To complete these steps, you must obtain a license that includes the
{alert-features}. For more information about Elastic license levels, see
https://www.elastic.co/subscriptions and <<license-management>>.
https://www.elastic.co/subscriptions and
{stack-ov}/license-management.html[License management].
[[watch-log-data]]
To set up a watch to start sending alerts:
@ -17,14 +18,14 @@ condition is met.
[float]
[[log-add-input]]
=== Schedule the Watch and Define an Input
=== Schedule the watch and define an input
A watch {xpack-ref}/trigger-schedule.html[schedule] controls how often a watch is triggered.
The watch {xpack-ref}/input.html[input] gets the data that you want to evaluate.
A watch <<trigger-schedule,schedule>> controls how often a watch is triggered.
The watch <<input,input>> gets the data that you want to evaluate.
To periodically search log data and load the results into the
watch, you could use an {xpack-ref}/trigger-schedule.html#schedule-interval[interval] schedule and a
{xpack-ref}/input-search.html[search] input. For example, the following Watch searches
watch, you could use an <<schedule-interval,interval>> schedule and a
<<input-search,search>> input. For example, the following Watch searches
the `logs` index for errors every 10 seconds:
[source,console]
@ -74,9 +75,9 @@ GET .watcher-history*/_search?pretty
[float]
[[log-add-condition]]
=== Add a Condition
=== Add a condition
A {xpack-ref}/condition.html[condition] evaluates the data you've loaded into the watch and
A <<condition,condition>> evaluates the data you've loaded into the watch and
determines if any action is required. Now that you've loaded log errors into
the watch, you can define a condition that checks to see if any errors were
found.
@ -107,7 +108,7 @@ PUT _watcher/watch/log_error_watch
}
--------------------------------------------------
<1> The {xpack-ref}/condition-compare.html[compare] condition lets you easily compare against
<1> The <<condition-compare,compare>> condition lets you easily compare against
values in the execution context.
For this compare condition to evaluate to `true`, you need to add an event
@ -149,11 +150,11 @@ GET .watcher-history*/_search?pretty
[float]
[[log-take-action]]
=== Configure an Action
=== Configure an action
Recording watch records in the watch history is nice, but the real power of
{watcher} is being able to do something when the watch condition is met. A
watch's {xpack-ref}/actions.html[actions] define what to do when the watch condition
watch's <<actions,actions>> define what to do when the watch condition
evaluates to `true`. You can send emails, call third-party webhooks, write
documents to an Elasticsearch index, or log messages to the standard
Elasticsearch log files.
@ -200,7 +201,7 @@ delete it when you're done experimenting. Otherwise, the noise from this sample
watch will make it hard to see what else is going on in your watch history and
log file.
To remove the watch, use the {ref}/watcher-api-delete-watch.html[DELETE watch API]:
To remove the watch, use the <<watcher-api-delete-watch,delete watch API>>:
[source,console]
--------------------------------------------------
@ -210,7 +211,7 @@ DELETE _watcher/watch/log_error_watch
[float]
[[required-security-privileges]]
=== Required Security Privileges
=== Required security privileges
To enable users to create and manipulate watches, assign them the `watcher_admin`
security role. Watcher admins can also view watches, watch history, and triggered
watches.
@ -221,11 +222,11 @@ allowed to execute read-only watch operations.
[float]
[[next-steps]]
=== Where to Go Next
=== Where to go next
* See {xpack-ref}/how-watcher-works.html[How {watcher} Works] for more information about the
* See <<how-watcher-works>> for more information about the
anatomy of a watch and the watch lifecycle.
* See {xpack-ref}/example-watches.html[Example Watches] for more examples of setting up
* See <<example-watches>> for more examples of setting up
a watch.
* See the https://github.com/elastic/examples/tree/master/Alerting[Example
Watches] in the Elastic Examples repo for additional sample watches you can use

2
x-pack/docs/en/watcher/gs-index.asciidoc
View File

@ -1,6 +1,6 @@
[role="xpack"]
[[xpack-alerting]]
= Alerting on Cluster and Index Events
= Alerting on cluster and index events
[partintro]
--

47
x-pack/docs/en/watcher/how-watcher-works.asciidoc
View File

@ -1,6 +1,6 @@
[role="xpack"]
[[how-watcher-works]]
== How {watcher} Works
== How {watcher} works
You <<watch-definition, add watches>> to automatically perform an action when
certain conditions are met. The conditions are generally based on data you've
@ -16,7 +16,7 @@ This topic describes the elements of a watch and how watches operate.
[float]
[[watch-definition]]
=== Watch Definition
=== Watch definition
A watch consists of a _trigger_, _input_, _condition_, and _actions_. The actions
define what needs to be done once the condition is met. In addition, you can
@ -44,7 +44,7 @@ Specify what happens when the watch condition is met.
[[watch-definition-example]]
For example, the following snippet shows a
{ref}/watcher-api-put-watch.html[Put Watch] request that defines a watch that
<<watcher-api-put-watch,put watch>> request that defines a watch that
looks for log error events:
[source,console]
@ -131,7 +131,7 @@ PUT _watcher/watch/log_errors
[float]
[[watch-execution]]
=== Watch Execution
=== Watch execution
[[schedule-scheduler]]
When you add a watch, {watcher} immediately registers its trigger with the
@ -198,7 +198,7 @@ image::images/watch-execution.jpg[align="center"]
[float]
[[watch-acknowledgment-throttling]]
=== Watch Acknowledgment and Throttling
=== Watch acknowledgment and throttling
{watcher} supports both time-based and acknowledgment-based throttling. This
enables you to prevent actions from being repeatedly executed for the same event.
@ -218,7 +218,7 @@ For more information, see <<actions-ack-throttle>>.
[float]
[[watch-active-state]]
=== Watch Active State
=== Watch active state
By default, when you add a watch it is immediately set to the _active_ state,
registered with the appropriate trigger engine, and executed according
@ -228,13 +228,13 @@ You can also set a watch to the _inactive_ state. Inactive watches are not
registered with a trigger engine and can never be triggered.
To set a watch to the inactive state when you create it, set the
{ref}/watcher-api-put-watch.html[`active`] parameter to _inactive_. To
<<watcher-api-put-watch,`active`>> parameter to _inactive_. To
deactivate an existing watch, use the
{ref}/watcher-api-deactivate-watch.html[Deactivate Watch API]. To reactivate an
<<watcher-api-deactivate-watch,deactivate watch API>>. To reactivate an
inactive watch, use the
{ref}/watcher-api-activate-watch.html[Activate Watch API].
<<watcher-api-activate-watch,activate watch API>>.
NOTE: You can use the {ref}/watcher-api-execute-watch.html[Execute Watch API]
NOTE: You can use the <<watcher-api-execute-watch,execute watch API>>
to force the execution of a watch even when it is inactive.
Deactivating watches is useful in a variety of situations. For example, if you
@ -247,7 +247,7 @@ deleting it from the system.
[float]
[[scripts-templates]]
=== Scripts and Templates
=== Scripts and templates
You can use scripts and templates when defining a watch. Scripts and templates
can reference elements in the watch execution context, including the watch payload.
@ -258,13 +258,12 @@ placeholders in a template.
<<inline-templates-scripts,inline>> and <<stored-templates-scripts, stored>>.
Scripts and templates are compiled
and cached by Elasticsearch to optimize recurring execution. Autoloading is also
supported. For more information, see {ref}/modules-scripting.html[Scripting] and
{ref}/modules-scripting-using.html[How to use scripts] in the Elasticsearch
Reference.
supported. For more information, see <<modules-scripting>> and
<<modules-scripting-using>>.
[float]
[[watch-execution-context]]
==== Watch Execution Context
==== Watch execution context
The following snippet shows the basic structure of the _Watch Execution Context_:
@ -298,14 +297,14 @@ The following snippet shows the basic structure of the _Watch Execution Context_
[float]
[[scripts]]
==== Using Scripts
==== Using scripts
You can use scripts to define <<condition-script, conditions>> and
<<transform-script, transforms>>. The default scripting language is
{ref}/modules-scripting-painless.html[Painless].
You can use scripts to define <<condition-script,conditions>> and
<<transform-script,transforms>>. The default scripting language is
<<modules-scripting-painless,Painless>>.
NOTE: Starting with 5.0, Elasticsearch is shipped with the new
{ref}/modules-scripting-painless.html[Painless] scripting language.
<<modules-scripting-painless,Painless>> scripting language.
Painless was created and designed specifically for use in Elasticsearch.
Beyond providing an extensive feature set, its biggest trait is that it's
properly sandboxed and safe to use anywhere in the system (including in
@ -323,7 +322,7 @@ access its value via the `color` variable.
[float]
[[templates]]
==== Using Templates
==== Using templates
You use templates to define dynamic content for a watch. At execution time,
templates pull in data from the watch execution context. For example, you can use
@ -353,7 +352,7 @@ in sent emails:
[float]
[[inline-templates-scripts]]
===== Inline Templates and Scripts
===== Inline templates and scripts
To define an inline template or script, you simply specify it directly in the
value of a field. For example, the following snippet configures the subject of
@ -415,9 +414,9 @@ The formal object definition for a script would be:
[float]
[[stored-templates-scripts]]
===== Stored Templates and Scripts
===== Stored templates and scripts
If you {ref}/modules-scripting-using.html#modules-scripting-stored-scripts[store]
If you <<modules-scripting-stored-scripts,store>>
your templates and scripts, you can reference them by id.
To reference a stored script or template, you use the formal object definition

8
x-pack/docs/en/watcher/input.asciidoc
View File

@ -9,12 +9,12 @@ input.
{watcher} supports four input types:
* <<input-simple, `simple`>>: load static data into the execution context.
* <<input-search, `search`>>: load the results of a search into the execution
* <<input-simple,`simple`>>: load static data into the execution context.
* <<input-search,`search`>>: load the results of a search into the execution
context.
* <<input-http, `http`>>: load the results of an HTTP request into the execution
* <<input-http,`http`>>: load the results of an HTTP request into the execution
context.
* <<input-chain, `chain`>>: use a series of inputs to load data into the
* <<input-chain,`chain`>>: use a series of inputs to load data into the
execution context.
NOTE: If you don't define an input for a watch, an empty payload is loaded

6
x-pack/docs/en/watcher/input/chain.asciidoc
View File

@ -1,6 +1,6 @@
[role="xpack"]
[[input-chain]]
=== Chain Input
=== Chain input
Use the `chain` input to load data from multiple sources into the watch
execution context when the watch is triggered. The inputs in a chain
@ -45,12 +45,12 @@ path set by a `simple` input:
arbitrary objects.)
<2> Loads the `path` set by the `first` input.
==== Accessing Chained Input Data
==== Accessing chained input data
To reference data loaded by a particular input, you use the input's name,
`ctx.payload.<input-name>.<value>`.
==== Transforming Chained Input Data
==== Transforming chained input data
In certain use-cases the output of the first input should be used as input
in a subsequent input. This requires you to do a transform, before you pass

34
x-pack/docs/en/watcher/input/http.asciidoc
View File

@ -1,10 +1,10 @@
[role="xpack"]
[[input-http]]
=== HTTP Input
=== HTTP input
Use the `http` input to submit a request to an HTTP endpoint and load the
response into the watch execution context when the watch is triggered. See
<<http-input-attributes, Input Attributes>> for all of the supported attributes.
<<http-input-attributes>> for all of the supported attributes.
With the `http` input, you can:
@ -14,15 +14,14 @@ With the `http` input, you can:
need to search clusters that are running different Elasticsearch versions.
* Query Elasticsearch APIs other than the search API. For example, you might want
to load data from the {ref}/cluster-nodes-stats.html[Nodes Stats],
{ref}/cluster-health.html[Cluster Health] or {ref}/cluster-state.html[Cluster
State] APIs.
to load data from the <<cluster-nodes-stats,nodes stats>>,
<<cluster-health,cluster health>> or <<cluster-state,cluster state>> APIs.
* Query external web services. The `http` input enables you to load data from
any service that exposes an HTTP endpoint. This provides a bridge
between Elasticsearch clusters and other systems.
==== Querying External Elasticsearch Clusters
==== Querying external Elasticsearch clusters
To query an external Elasticsearch cluster, you specify the cluster's
`host` and `port` attributes and the index's search endpoint as the `path`.
@ -43,7 +42,7 @@ index:
--------------------------------------------------
// NOTCONSOLE
You can use the full Elasticsearch {ref}/query-dsl.html[Query DSL] to perform
You can use the full Elasticsearch <<query-dsl,query DSL>> to perform
more sophisticated searches. For example, the following `http` input retrieves
all documents that contain `event` in the `category` field:
@ -67,8 +66,7 @@ all documents that contain `event` in the `category` field:
To load the data from other Elasticsearch APIs, specify the API
endpoint as the `path` attribute. Use the `params` attribute to specify
query string parameters. For example, the following `http` input
calls the {ref}/cluster-stats.html[Cluster
Stats] API and enables the `human` attribute:
calls the <<cluster-stats,cluster stats>> API and enables the `human` attribute:
[source,js]
--------------------------------------------------
@ -90,7 +88,7 @@ Stats] API and enables the `human` attribute:
readable format.
[[input-http-auth-basic-example]]
==== Calling External Web Services
==== Calling external web services
You can use `http` input to get data from any external web service. The `http`
input supports basic authentication. For example, the following input provides
@ -138,9 +136,9 @@ http://openweathermap.org/appid[OpenWeatherMap] service:
--------------------------------------------------
// NOTCONSOLE
==== Using Templates
==== Using templates
The `http` input supports templating. You can use <<templates, templates>> when
The `http` input supports templating. You can use <<templates,templates>> when
specifying the `path`, `body`, header values, and parameter values.
For example, the following snippet uses templates to specify what index to query
@ -161,7 +159,7 @@ and restrict the results to documents added within the last five minutes:
--------------------------------------------------
// NOTCONSOLE
==== Accessing the HTTP Response
==== Accessing the HTTP response
If the response body is formatted in JSON or YAML, it is parsed and loaded into
the execution context. If the response body is not formatted in JSON or YAML, it
@ -177,7 +175,7 @@ In addition all the headers from the response can be accessed using the
[[http-input-attributes]]
==== HTTP Input Attributes
==== HTTP input attributes
[cols=",^,^,", options="header"]
|======
@ -190,17 +188,17 @@ In addition all the headers from the response can be accessed using the
| `request.port` | yes | - | The port the http service is listening on.
| `request.path` | no | - | The URL path. The path can be static text or contain `mustache`
<<templates, templates>>. URL query string parameters must be
<<templates,templates>>. URL query string parameters must be
specified via the `request.params` attribute.
| `request.method` | no | get | The HTTP method. Supported values are: `head`, `get`, `post`,
`put` and `delete`.
| `request.headers` | no | - | The HTTP request headers. The header values can be static text
or include `mustache` <<templates, templates>>.
or include `mustache` <<templates,templates>>.
| `request.params` | no | - | The URL query string parameters. The parameter values can be
static text or contain `mustache` <<templates, templates>>.
static text or contain `mustache` <<templates,templates>>.
| `request.url` | no | - | Allows you to set `request.scheme`, `request.host`, `request.port`
and `request.params` add once by specifying a real URL, like
@ -225,7 +223,7 @@ In addition all the headers from the response can be accessed using the
| `request.body` | no | - | The HTTP request body. The body can be static text or include
`mustache` <<templates, templates>>.
`mustache` <<templates,templates>>.
| `extract` | no | - | A array of JSON keys to extract from the input response and
use as payload. In cases when an input generates a large

35
x-pack/docs/en/watcher/input/search.asciidoc
View File

@ -1,16 +1,15 @@
[role="xpack"]
[[input-search]]
=== Search Input
=== Search input
Use the `search` input to load the results of an Elasticsearch search request
into the execution context when the watch is triggered. See
<<search-input-attributes, Search Input Attributes>> for all of the
supported attributes.
<<search-input-attributes>> for all of the supported attributes.
In the search input's `request` object, you specify:
* The indices you want to search
* The {ref}/search-request-body.html#request-body-search-search-type[search type]
* The <<request-body-search-search-type,search type>>
* The search request body
The search request body supports the full Elasticsearch Query DSL--it's the
@ -60,7 +59,7 @@ the following input loads the latest VIXZ quote from today's daily quotes index:
--------------------------------------------------
// NOTCONSOLE
==== Extracting Specific Fields
==== Extracting specific fields
You can specify which fields in the search response you want to load into the
watch payload with the `extract` attribute. This is useful when a search
@ -84,7 +83,7 @@ watch payload:
==== Using Templates
The `search` input supports {ref}/search-template.html[search templates]. For
The `search` input supports <<search-template,search templates>>. For
example, the following snippet references the indexed template called
`my_template` and passes a value of 23 to fill in the template's `value`
parameter:
@ -110,11 +109,11 @@ parameter:
--------------------------------------------------
// NOTCONSOLE
==== Applying Conditions
==== Applying conditions
The `search` input is often used in conjunction with the <<condition-script,
`script`>> condition. For example, the following snippet adds a condition to
check if the search returned more than five hits:
The `search` input is often used in conjunction with the
<<condition-script,`script`>> condition. For example, the following snippet adds
a condition to check if the search returned more than five hits:
[source,js]
--------------------------------------------------
@ -137,7 +136,7 @@ check if the search returned more than five hits:
--------------------------------------------------
// NOTCONSOLE
==== Accessing the Search Results
==== Accessing the search results
Conditions, transforms, and actions can access the search results through the
watch execution context. For example:
@ -164,7 +163,7 @@ accurately.
|======
| Name |Required | Default | Description
| `request.search_type` | no | `query_then_fetch` | The {ref}/search-request-search-type.html#search-request-search-type[type]
| `request.search_type` | no | `query_then_fetch` | The <<search-request-search-type,type>>
of search request to perform. Valid values are: `dfs_query_and_fetch`,
`dfs_query_then_fetch`, `query_and_fetch`, and `query_then_fetch`. The
Elasticsearch default is `query_then_fetch`.
@ -172,21 +171,21 @@ accurately.
| `request.indices` | no | - | The indices to search. If omitted, all indices are searched, which is the
default behaviour in Elasticsearch.
| `request.body` | no | - | The body of the request. The {ref}/search-request-body.html[request body]
| `request.body` | no | - | The body of the request. The <<search-request-body,request body>>
follows the same structure you normally send in the body of a REST `_search`
request. The body can be static text or include `mustache` <<templates, templates>>.
request. The body can be static text or include `mustache` <<templates,templates>>.
| `request.template` | no | - | The body of the search template. See <<templates, configure templates>>
| `request.template` | no | - | The body of the search template. See <<templates,configure templates>>
for more information.
| `request.indices_options.expand_wildcards` | no | `open` | How to expand wildcards. Valid values are: `all`, `open`, `closed`, and `none`
See {ref}/multi-index.html#multi-index[`expand_wildcards`] for more information.
See <<multi-index,`expand_wildcards`>> for more information.
| `request.indices_options.ignore_unavailable` | no | `true` | Whether the search should ignore unavailable indices. See
{ref}/multi-index.html#multi-index[`ignore_unavailable`] for more information.
<<multi-index,`ignore_unavailable`>> for more information.
| `request.indices_options.allow_no_indices` | no | `true` | Whether to allow a search where a wildcard indices expression results in no
concrete indices. See {ref}/multi-index.html#multi-index[allow_no_indices]
concrete indices. See <<multi-index,allow_no_indices>>
for more information.
| `extract` | no | - | A array of JSON keys to extract from the search response and load as the payload.

2
x-pack/docs/en/watcher/input/simple.asciidoc
View File

@ -1,6 +1,6 @@
[role="xpack"]
[[input-simple]]
=== Simple Input
=== Simple input
Use the `simple` input to load static data into the execution
context when the watch is triggered. This enables you to store the data

6
x-pack/docs/en/watcher/java/ack-watch.asciidoc
View File

@ -1,13 +1,13 @@
[float]
[[api-java-ack-watch]]
=== Ack Watch API
=== Ack watch API
<<actions-ack-throttle, Acknowledging>> a watch enables you to manually throttle
<<actions-ack-throttle,Acknowledging>> a watch enables you to manually throttle
execution of the watch actions. The action's _acknowledgement state_ is stored in
the `status.actions.<id>.ack.state` structure.
The current status of the watch and the state of its actions are returned as part
of the <<api-java-get-watch, Get Watch API>> response:
of the <<api-java-get-watch,get watch API>> response:
[source,java]
--------------------------------------------------

6
x-pack/docs/en/watcher/java/activate-watch.asciidoc
View File

@ -1,12 +1,12 @@
[float]
[[api-java-activate-watch]]
=== Activate Watch API
=== Activate watch API
A watch can be either <<watch-active-state, active or inactive>>. This API
A watch can be either <<watch-active-state,active or inactive>>. This API
enables you to activate a currently inactive watch.
The status of an inactive watch is returned with the watch definition
when you call the <<api-java-get-watch, Get Watch API>>:
when you call the <<api-java-get-watch,get watch API>>:
[source,java]
--------------------------------------------------

6
x-pack/docs/en/watcher/java/deactivate-watch.asciidoc
View File

@ -1,12 +1,12 @@
[float]
[[api-java-deactivate-watch]]
=== Deactivate Watch API
=== Deactivate watch API
A watch can be either <<watch-active-state, active or inactive>>. This API
A watch can be either <<watch-active-state,active or inactive>>. This API
enables you to deactivate a currently active watch.
The status of an active watch is returned with the watch definition
when you call the <<api-java-get-watch, Get Watch API>>:
when you call the <<api-java-get-watch,get watch API>>:
[source,java]
--------------------------------------------------

4
x-pack/docs/en/watcher/java/delete-watch.asciidoc
View File

@ -1,8 +1,8 @@
[float]
[[api-java-delete-watch]]
=== Delete Watch API
=== Delete watch API
The DELETE watch API removes a watch (identified by its `id`) from {watcher}.
The delete watch API removes a watch (identified by its `id`) from {watcher}.
Once removed, the document representing the watch in the `.watches` index is
gone and it will never be executed again.

2
x-pack/docs/en/watcher/java/execute-watch.asciidoc
View File

@ -1,6 +1,6 @@
[float]
[[api-java-execute-watch]]
=== Execute Watch API
=== Execute watch API
This API enables on-demand execution of a watch stored in the `.watches` index.
It can be used to test a watch without executing all its actions or by ignoring

2
x-pack/docs/en/watcher/java/get-watch.asciidoc
View File

@ -1,6 +1,6 @@
[float]
[[api-java-get-watch]]
=== Get Watch API
=== Get watch API
This API retrieves a watch by its id.

4
x-pack/docs/en/watcher/java/put-watch.asciidoc
View File

@ -1,8 +1,8 @@
[float]
[[api-java-put-watch]]
=== PUT Watch API
=== Put watch API
The PUT watch API either registers a new watch in {watcher} or update an
The put watch API either registers a new watch in {watcher} or update an
existing one. Once registered, a new document will be added to the `.watches`
index, representing the watch, and the watch trigger will immediately be
registered with the relevant trigger engine (typically the scheduler, for the

16
x-pack/docs/en/watcher/managing-watches.asciidoc
View File

@ -1,19 +1,19 @@
[role="xpack"]
[[managing-watches]]
== Managing Watches
== Managing watches
{watcher} provides as set of APIs you can use to manage your watches:
* Use the {ref}/watcher-api-put-watch.html[Put Watch API] to add or update watches
* Use the {ref}/watcher-api-get-watch.html[Get Watch API] to retrieve watches
* Use the {ref}/watcher-api-delete-watch.html[Delete Watch API] to delete watches
* Use the {ref}/watcher-api-activate-watch.html[Activate Watch API] to activate watches
* Use the {ref}/watcher-api-deactivate-watch.html[Deactivate Watch API] to deactivate watches
* Use the {ref}/watcher-api-ack-watch.html[Ack Watch API] to acknowledge watches
* Use the <<watcher-api-put-watch,put watch API>> to add or update watches
* Use the <<watcher-api-get-watch,get watch API>> to retrieve watches
* Use the <<watcher-api-delete-watch,delete watch API>> to delete watches
* Use the <<watcher-api-activate-watch,activate watch API>> to activate watches
* Use the <<watcher-api-deactivate-watch,deactivate watch API>> to deactivate watches
* Use the <<watcher-api-ack-watch,ack watch API>> to acknowledge watches
[float]
[[listing-watches]]
=== Listing Watches
=== Listing watches
Currently there is not dedicated API for listing the stored watches. However,
since {watcher} stores its watches in the `.watches` index, you can list them

48
x-pack/docs/en/watcher/release-notes.asciidoc
View File

@ -120,8 +120,8 @@ March 30, 2016
{ref}/watcher-api-execute-watch.html[Execute Watch API]
.New Features
* Added <<actions-pagerduty, PagerDuty action>>
* Added support for adding <<configuring-email-attachments, attachments to emails>>
* Added <<actions-pagerduty,PagerDuty action>>
* Added support for adding <<configuring-email-attachments,attachments to emails>>
via HTTP requests and superseding and deprecating the usage of `attach_data`
in order to use this feature
@ -158,7 +158,7 @@ December 17, 2015
November 24, 2015
.New Features
* Adds support for <<input-chain, chaining several inputs>>
* Adds support for <<input-chain,chaining several inputs>>
.Enhancements
* Adds support for Elasticsearch 2.1.0.
@ -205,13 +205,13 @@ October 28, 2015
use the following index name `<logstash-{now/d{YYYY.MM.dd|+01:00}}>`.
.New Features
* Added new <<actions-hipchat, HipChat Action>>
* Added new <<actions-slack, Slack Action>>
* Watches now have an <<watch-active-state, active state>>. In addition, a new
* Added new <<actions-hipchat,HipChat Action>>
* Added new <<actions-slack,Slack Action>>
* Watches now have an <<watch-active-state,active state>>. In addition, a new
API was added to {ref}/watcher-api-activate-watch.html[activate]
/{ref}watcher-api-deactivate-watch.html[deactivate] registered watches.
* Added new <<condition-array-compare, array_compare>>, that can compare an array
of values in the <<watch-execution-context, Watch Execution Context Model>>
* Added new <<condition-array-compare,array_compare>>, that can compare an array
of values in the <<watch-execution-context,Watch execution context model>>
to a given value.
.Enhancements
@ -274,40 +274,40 @@ June 25, 2015
June 19, 2015
.New Features
* Added <<watcher-api-execute-inline-watch, inline watch>> support to the Execute API
* Added <<watcher-api-execute-inline-watch,inline watch>> support to the Execute API
.Enhancements
* Added execution context <<watch-execution-context, variables>> support.
* Email html body sanitization is now <<email-html-sanitization, configurable>>.
* Added execution context <<watch-execution-context,variables>> support.
* Email html body sanitization is now <<email-html-sanitization,configurable>>.
* It is now possible to configure timeouts for http requests in
<<http-input-attributes, HTTP input>> and <<webhook-action-attributes, webhook actions>>.
<<http-input-attributes,HTTP input>> and <<webhook-action-attributes,webhook actions>>.
[float]
==== 1.0.0-Beta2
June 10, 2015
.New Features
* <<actions-ack-throttle, Acking and Throttling>> are now applied at the action
* <<actions-ack-throttle,Acking and throttling>> are now applied at the action
level rather than the watch level.
* Added support for <<anatomy-actions-index-multi-doc-support, multi-doc>>
* Added support for <<anatomy-actions-index-multi-doc-support,multi-doc>>
indexing to the index action.
* Added a queued watches metric that's accessible via the <<watcher-api-stats, Stats API>>.
* Added a queued watches metric that's accessible via the <<watcher-api-stats,stats API>>.
* Added a currently-executing watches metric that's accessible via the
<<watcher-api-stats, Stats API>>.
<<watcher-api-stats,stats API>>.
.Enhancements
* The <<condition-compare, compare condition>> result now includes the value of
* The <<condition-compare,compare condition>> result now includes the value of
each field that was referenced in the comparison.
* The <<watcher-api-execute-watch, Execute API>> now supports a default trigger
* The <<watcher-api-execute-watch,execute API>> now supports a default trigger
event (**breaking change**).
* The `watch_record` document structure in the `.watch_history-*` indices has
changed significantly (**breaking change**).
* A new internal index was introduced - `.triggered_watches`
* Added support for headers in the <<actions-webhook, Webhook Action>> result
and the <<input-http, HTTP Input>> result.
* Add plain text response body support for the <<input-http, HTTP Input>>.
* Added support for headers in the <<actions-webhook,webhook action>> result
and the <<input-http,HTTP input>> result.
* Add plain text response body support for the <<input-http,HTTP input>>.
.Bug Fixes
* Disallow negative time value settings for <<actions-ack-throttle, `throttle_period`>>
* Added support for separate keystore and truststore in <<actions-webhook, Webhook Action>>
and <<input-http, HTTP Input>>.
* Disallow negative time value settings for <<actions-ack-throttle,`throttle_period`>>
* Added support for separate keystore and truststore in <<actions-webhook,webhook action>>
and <<input-http,HTTP input>>.

6
x-pack/docs/en/watcher/transform.asciidoc
View File

@ -2,10 +2,10 @@
[[transform]]
== Transforms
A _Transform_ processes and changes the payload in the watch execution context
A _transform_ processes and changes the payload in the watch execution context
to prepare it for the watch actions. {watcher} supports three types of
transforms: <<transform-search, `search`>>,
<<transform-script, `script`>> and <<transform-chain, `chain`>>.
transforms: <<transform-search,`search`>>,
<<transform-script,`script`>> and <<transform-chain,`chain`>>.
NOTE: Transforms are optional. When none are defined, the actions have access to

8
x-pack/docs/en/watcher/transform/chain.asciidoc
View File

@ -1,16 +1,16 @@
[role="xpack"]
[[transform-chain]]
=== Chain Transform
=== Chain transform
A <<transform, Transform>> that executes an ordered list of configured transforms
A <<transform,transform>> that executes an ordered list of configured transforms
in a chain, where the output of one transform serves as the input of the next
transform in the chain. The payload that is accepted by this transform serves as
the input of the first transform in the chain and the output of the last transform
in the chain is the output of the `chain` transform as a whole.
You can use chain transforms to build more complex transforms out of the other
available transforms. For example, you can combine a <<transform-search, `search`>>
transform and a <<transform-script, `script`>> transform, as shown in the
available transforms. For example, you can combine a <<transform-search,`search`>>
transform and a <<transform-script,`script`>> transform, as shown in the
following snippet:
[source,js]

14
x-pack/docs/en/watcher/transform/script.asciidoc
View File

@ -1,15 +1,15 @@
[role="xpack"]
[[transform-script]]
=== Script Transform
=== Script transform
A <<transform, Transform>> that executes a script on the current payload in the
A <<transform,transform>> that executes a script on the current payload in the
watch execution context and replaces it with a newly generated one. The following
snippet shows how a simple script transform can be defined on the watch level:
TIP: The `script` transform is often useful when used in combination with the
<<transform-search, `search`>> transform, where the script can extract only
<<transform-search,`search`>> transform, where the script can extract only
the significant data from a search result, and by that, keep the payload
minimal. This can be achieved with the <<transform-chain, `chain`>>
minimal. This can be achieved with the <<transform-chain,`chain`>>
transform.
@ -33,13 +33,13 @@ NOTE: The executed script may either return a valid model that is the equivalent
The `script` attribute may hold a string value in which case it will be treated
as an inline script and the default elasticsearch script languages will be assumed
(as described in {ref}/modules-scripting.html#modules-scripting[here]). You can
(as described in <<modules-scripting>>). You can
use the other scripting languages supported by Elasticsearch. For this, you need
to set the `script` field to an object describing the script and its language.
The following table lists the possible settings that can be configured:
[[transform-script-settings]]
.Script Transform Settings
.Script transform settings
[options="header"]
|======
| Name |Required | Default | Description
@ -60,5 +60,5 @@ When using the object notation of the script, one (and only one) of `inline`,
or `id` fields must be defined.
NOTE: In addition to the provided `params`, the scripts also have access to the
<<watch-execution-context, Standard Watch Execution Context Parameters>>.
<<watch-execution-context,standard watch execution context parameters>>.

26
x-pack/docs/en/watcher/transform/search.asciidoc
View File

@ -1,8 +1,8 @@
[role="xpack"]
[[transform-search]]
=== Search Transform
=== Search transform
A <<transform, Transform>> that executes a search on the cluster and replaces
A <<transform,transform>> that executes a search on the cluster and replaces
the current payload in the watch execution context with the returned search
response. The following snippet shows how a simple search transform can be
defined on the watch level:
@ -48,35 +48,35 @@ execute a search over all events indices, matching events with `error` priority:
The following table lists all available settings for the search transform:
[[transform-search-settings]]
.Search Transform Settings
.Search transform settings
[cols=",^,,", options="header"]
|======
| Name |Required | Default | Description
| `request.search_type` | no | query_then_fetch | The search {ref}/search-request-body.html#request-body-search-search-type[type].
| `request.search_type` | no | query_then_fetch | The search <<request-body-search-search-type,type>>.
| `request.indices` | no | all indices | One or more indices to search on.
| `request.body` | no | `match_all` query | The body of the request. The
{ref}/search-request-body.html[request body] follows
<<search-request-body,request body>> follows
the same structure you normally send in the body of
a REST `_search` request. The body can be static text
or include `mustache` <<templates, templates>>.
or include `mustache` <<templates,templates>>.
| `request.indices_options.expand_wildcards` | no | `open` | Determines how to expand indices wildcards. Can be one
of `open`, `closed`, `none` or `all`
(see {ref}/multi-index.html[multi-index support])
(see <<multi-index,multi-index support>>)
| `request.indices_options.ignore_unavailable` | no | `true` | A boolean value that determines whether the search
should leniently ignore unavailable indices
(see {ref}/multi-index.html[multi-index support])
(see <<multi-index,multi-index support>>)
| `request.indices_options.allow_no_indices` | no | `true` | A boolean value that determines whether the search
should leniently return no results when no indices
are resolved (see {ref}/multi-index.html[multi-index support])
are resolved (see <<multi-index,multi-index support>>)
| `request.template` | no | - | The body of the search template. See
<<templates, configure templates>> for more information.
<<templates,configure templates>> for more information.
| `timeout` | no | 30s | The timeout for waiting for the search api call to
return. If no response is returned within this time,
@ -85,11 +85,11 @@ The following table lists all available settings for the search transform:
|======
[[transform-search-template]]
==== Template Support
==== Template support
The search transform support mustache <<templates, templates>>. This can either
be as part of the body definition, or alternatively, point to an existing
template (either defined in a file or {ref}/search-template.html#pre-registered-templates[registered]
template (either defined in a file or <<pre-registered-templates,registered>>
as a script in Elasticsearch).
For example, the following snippet shows a search that refers to the scheduled
@ -130,7 +130,7 @@ time of the watch:
// NOTCONSOLE
The model of the template is a union between the provided `template.params`
settings and the <<watch-execution-context, standard watch execution context model>>.
settings and the <<watch-execution-context,standard watch execution context model>>.
The following is an example of using templates that refer to provided parameters:

2
x-pack/docs/en/watcher/trigger.asciidoc
View File

@ -8,6 +8,6 @@ appropriate _Trigger Engine_. The trigger engine is responsible for evaluating
the trigger and triggering the watch when needed.
{watcher} is designed to support different types of triggers, but only time-based
<<trigger-schedule, `schedule`>> triggers are currently available.
<<trigger-schedule,`schedule`>> triggers are currently available.
include::trigger/schedule.asciidoc[]

6
x-pack/docs/en/watcher/trigger/schedule.asciidoc
View File

@ -1,8 +1,8 @@
[role="xpack"]
[[trigger-schedule]]
=== Schedule Trigger
=== Schedule trigger
Schedule <<trigger, triggers>> define when the watch execution should start based
Schedule <<trigger,triggers>> define when the watch execution should start based
on date and time. All times are specified in UTC time.
{watcher} uses the system clock to determine the current time. To ensure schedules
@ -15,7 +15,7 @@ that's more frequent than the throttle period, the throttle period overrides the
schedule. For example, if you set the throttle period to one minute (60000 ms)
and set the schedule to every 10 seconds, the watch is executed no more than
once per minute. For more information about throttling, see
<<actions-ack-throttle, Acknowledgement and Throttling>>.
<<actions-ack-throttle>>.
{watcher} provides several types of schedule triggers:

26
x-pack/docs/en/watcher/trigger/schedule/cron.asciidoc
View File

@ -2,7 +2,7 @@
[[schedule-cron]]
==== `cron` schedule
A <<trigger-schedule, `schedule`>> trigger that enables you to use a
A <<trigger-schedule,`schedule`>> trigger that enables you to use a
https://en.wikipedia.org/wiki/Cron[cron] style expression to specify when you
want the scheduler to start the watch execution. {watcher} uses the cron parser
from the http://www.quartz-scheduler.org[Quartz Job Scheduler]. For more
@ -13,10 +13,10 @@ WARNING: While `cron` triggers are super powerful, we recommend using one of
the other schedule types if you can, as they are much more
straightforward to configure. If you use `cron`, construct your `cron`
expressions with care to be sure you are actually setting the schedule
you want. You can use the <<croneval, `elasticsearch-croneval`>> tool to validate
you want. You can use the <<croneval,`elasticsearch-croneval`>> tool to validate
your cron expressions and see what the resulting trigger times will be.
===== Cron Expressions
===== Cron expressions
A cron expression is a string of the following form:
@ -29,7 +29,7 @@ All elements are required except for `year`. <<schedule-cron-elements>> shows
the valid values for each element in a cron expression.
[[schedule-cron-elements]]
.Cron Expression Elements
.Cron expression elements
[cols=",^,,", options="header"]
|======
| Name | Required | Valid Values | Valid Special Characters
@ -50,7 +50,7 @@ NOTE: Currently, you must specify `?` for either the `day_of_week` or
`day_of_month`. Explicitly specifying both values is not supported.
[[schedule-cron-special-characters]]
.Cron Special Characters
.Cron special characters
[options="header"]
|======
| Special Character | Description
@ -117,7 +117,7 @@ NOTE: Currently, you must specify `?` for either the `day_of_week` or
|======
.Setting Daily Triggers
.Setting daily triggers
[options="header"]
|======
| Cron Expression | Description
@ -125,7 +125,7 @@ NOTE: Currently, you must specify `?` for either the `day_of_week` or
| `0 5 9 * * ? 2015` | Trigger at 9:05 AM every day during the year 2015.
|======
.Restricting Triggers to a Range of Days or Times
.Restricting triggers to a range of days or times
[options="header"]
|======
| Cron Expression | Description
@ -134,7 +134,7 @@ NOTE: Currently, you must specify `?` for either the `day_of_week` or
at 9:05 AM every day.
|======
.Setting Interval Triggers
.Setting interval triggers
[options="header"]
|======
| Cron Expression | Description
@ -144,7 +144,7 @@ NOTE: Currently, you must specify `?` for either the `day_of_week` or
on the first day of the month.
|======
.Setting Schedules that Trigger on a Particular Day
.Setting schedules that trigger on a particular day
[options="header"]
|======
| Cron Expression | Description
@ -157,7 +157,7 @@ NOTE: Currently, you must specify `?` for either the `day_of_week` or
| `0 5 9 ? * 6#1` | Trigger at 9:05 AM on the first Friday of every month.
|======
.Setting Triggers Using Last
.Setting triggers using last
[options="header"]
|======
| Cron Expression | Description
@ -167,7 +167,7 @@ NOTE: Currently, you must specify `?` for either the `day_of_week` or
|======
===== Configuring a Cron Schedule
===== Configuring a cron schedule
To configure a `cron` schedule, you simply specify the cron expression as a
string value. For example, the following snippet configures a `cron` schedule
@ -187,7 +187,7 @@ that triggers every day at noon:
--------------------------------------------------
// NOTCONSOLE
===== Configuring a Multiple Times Cron Schedule
===== Configuring a multiple times cron schedule
To configure a `cron` schedule that triggers multiple times, you can
specify an array of cron expressions. For example, the following `cron`
@ -215,7 +215,7 @@ minute during the weekend:
===== Verifying cron expressions
The {es} {alert-features} provide a
{ref}/elasticsearch-croneval.html[`elasticsearch-croneval`] command line tool
<<elasticsearch-croneval,`elasticsearch-croneval`>> command line tool
that you can use to verify that your cron expressions are valid and produce the
expected results. This tool is provided in the `$ES_HOME/bin` directory.

12
x-pack/docs/en/watcher/trigger/schedule/daily.asciidoc
View File

@ -1,19 +1,19 @@
[role="xpack"]
[[schedule-daily]]
==== Daily Schedule
==== Daily schedule
A <<trigger-schedule, `schedule`>> that triggers at a particular time
A <<trigger-schedule,`schedule`>> that triggers at a particular time
every day. To use the `daily` schedule, you specify the time of day (or times)
when you want the scheduler to start the watch execution with the `at` attribute.
Times are specified in the form `HH:mm` on a 24-hour clock. You can also use the
reserved values `midnight` and `noon` for `00:00` and `12:00`, and
<<specifying-times-using-objects, specify times using objects>>.
<<specifying-times-using-objects,specify times using objects>>.
NOTE: If you don't specify the `at` attribute for a `daily` schedule, it defaults
to firing once daily at midnight, `00:00`.
===== Configuring a Daily Schedule
===== Configuring a daily schedule
To configure a once a day schedule, you specify a single time with the `at`
attribute. For example, the following `daily` schedule triggers once every
@ -31,7 +31,7 @@ day at 5:00 PM:
--------------------------------------------------
// NOTCONSOLE
===== Configuring a Multiple Times Daily Schedule
===== Configuring a multiple times daily schedule
To configure a `daily` schedule that triggers at multiple times during the day,
you specify an array of times. For example, the following `daily` schedule
@ -50,7 +50,7 @@ triggers at `00:00`, `12:00`, and `17:00` every day.
// NOTCONSOLE
[[specifying-times-using-objects]]
===== Specifying Times Using Objects
===== Specifying times using objects
In addition to using the `HH:mm` string syntax to specify times, you can specify
a time as an object that has `hour` and `minute` attributes.

8
x-pack/docs/en/watcher/trigger/schedule/hourly.asciidoc
View File

@ -1,8 +1,8 @@
[role="xpack"]
[[schedule-hourly]]
==== Hourly Schedule
==== Hourly schedule
A <<trigger-schedule, `schedule`>> that triggers at a particular minute every
A <<trigger-schedule,`schedule`>> that triggers at a particular minute every
hour of the day. To use the `hourly` schedule, you specify the minute (or minutes)
when you want the scheduler to start the watch execution with the `minute`
attribute.
@ -11,7 +11,7 @@ NOTE: If you don't specify the `minute` attribute for an `hourly` schedule, it
defaults to `0` and the schedule triggers on the hour every hour--`12:00`,
`13:00`, `14:00`, and so on.
===== Configuring a Once an Hour Schedule
===== Configuring a once an hour schedule
To configure a once an hour schedule, you specify a single time with the `minute`
attribute.
@ -31,7 +31,7 @@ For example, the following `hourly` schedule triggers at minute 30 every hour--
--------------------------------------------------
// NOTCONSOLE
===== Configuring a Multiple Times Hourly Schedule
===== Configuring a multiple times hourly schedule
To configure an `hourly` schedule that triggers at multiple times during the
hour, you specify an array of minutes. For example, the following schedule

6
x-pack/docs/en/watcher/trigger/schedule/interval.asciidoc
View File

@ -1,8 +1,8 @@
[role="xpack"]
[[schedule-interval]]
==== Interval Schedule
==== Interval schedule
A <<trigger-schedule, `schedule`>> that triggers at a fixed time interval. The
A <<trigger-schedule,`schedule`>> that triggers at a fixed time interval. The
interval can be set in seconds, minutes, hours, days, or weeks:
* `"Xs"` - trigger every `X` seconds. For example, `"30s"` means every 30 seconds.
@ -17,7 +17,7 @@ NOTE: The interval value differs from the standard _time value_ used in
Elasticsearch. You cannot configure intervals in milliseconds or
nanoseconds.
===== Configuring an Interval Schedule
===== Configuring an interval schedule
To configure an `interval` schedule, you specify a string value that represents
the interval. If you omit the unit of time (`s`,`m`, `h`, `d`, or `w`), it

8
x-pack/docs/en/watcher/trigger/schedule/monthly.asciidoc
View File

@ -1,8 +1,8 @@
[role="xpack"]
[[schedule-monthly]]
==== Monthly Schedule
==== Monthly schedule
A <<trigger-schedule, `schedule`>> that triggers at a specific day and time
A <<trigger-schedule,`schedule`>> that triggers at a specific day and time
every month. To use the `monthly` schedule, you specify the day of the month and
time (or days and times) when you want the scheduler to start the watch execution
with the `on` and `at` attributes.
@ -11,7 +11,7 @@ You specify the day of month as a numeric value between `1` and `31` (inclusive)
Times are specified in the form `HH:mm` on a 24-hour clock. You can also use the
reserved values `midnight` and `noon` for `00:00` and `12:00`.
===== Configuring a Monthly Schedule
===== Configuring a monthly schedule
To configure a once a month schedule, you specify a single day and time with the
`on` and `at` attributes. For example, the following `monthly` schedule triggers
@ -32,7 +32,7 @@ on the 10th of each month at noon:
NOTE: You can also specify the day and time with the `day` and `time` attributes,
they are interchangeable with `on` and `at`.
===== Configuring a Multiple Times Monthly Schedule
===== Configuring a multiple times monthly schedule
To configure a `monthly` schedule that triggers multiple times a month, you can
specify an array of day and time values. For example, the following `monthly`

8
x-pack/docs/en/watcher/trigger/schedule/weekly.asciidoc
View File

@ -1,8 +1,8 @@
[role="xpack"]
[[schedule-weekly]]
==== Weekly Schedule
==== Weekly schedule
A <<trigger-schedule, `schedule`>> that triggers at a specific day and time
A <<trigger-schedule,`schedule`>> that triggers at a specific day and time
every week. To use the `weekly` schedule, you specify the day and time (or days
and times) when you want the scheduler to start the watch execution with the `on`
and `at` attributes.
@ -17,7 +17,7 @@ being the first day of the week):
Times are specified in the form `HH:mm` on a 24-hour clock. You can also use the
reserved values `midnight` and `noon` for `00:00` and `12:00`.
===== Configuring a Weekly Schedule
===== Configuring a weekly schedule
To configure a once a week schedule, you specify the day with the `on` attribute
and the time with the `at` attribute. For example, the following `weekly` schedule
@ -38,7 +38,7 @@ triggers once a week on Friday at 5:00 PM:
NOTE: You can also specify the day and time with the `day` and `time` attributes,
they are interchangeable with `on` and `at`.
===== Configuring a Multiple Times Weekly Schedule
===== Configuring a multiple times weekly schedule
To configure a `weekly` schedule that triggers multiple times a week, you can
specify an array of day and time values. For example, the following `weekly`

8
x-pack/docs/en/watcher/trigger/schedule/yearly.asciidoc
View File

@ -1,8 +1,8 @@
[role="xpack"]
[[schedule-yearly]]
==== Yearly Schedule
==== Yearly schedule
A <<trigger-schedule, `schedule`>> that triggers at a specific day and time
A <<trigger-schedule,`schedule`>> that triggers at a specific day and time
every year. To use the `yearly` schedule, you specify the month, day, and time
(or months, days, and times) when you want the scheduler to start the watch
execution with the `in`, `on`, and `at` attributes.
@ -21,7 +21,7 @@ You specify the day of month as a numeric value between `1` and `31` (inclusive)
The Times are specified in the form `HH:mm` on a 24-hour clock. You can also use
the reserved values `midnight` and `noon` for `00:00` and `12:00`.
===== Configuring a Yearly Schedule
===== Configuring a yearly schedule
To configure a once a year schedule, you specify the month with the `in` attribute,
the day with the `on` attribute, and the time with the `at` attribute. For
@ -43,7 +43,7 @@ example, the following `yearly` schedule triggers once a year at noon on January
NOTE: You can also specify the month, day, and time with the `month`, `day`, and
`time` attributes, they are interchangeable with `in`, `on`, and `at`.
===== Configuring a Multiple Times Yearly Schedule
===== Configuring a multiple times yearly schedule
To configure a `yearly` schedule that triggers multiple times a year, you can
specify an array of month, day, and time values. For example, the following