Co-Authored-By: James Rodewig <james.rodewig@elastic.co>
This commit is contained in:
parent
8f1a80a43d
commit
0c3ee0b15c
|
@ -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:
|
||||
|
||||
|
|
|
@ -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[]
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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*
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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[]
|
||||
|
|
|
@ -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`::
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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]]
|
||||
|
|
|
@ -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]]
|
||||
|
|
|
@ -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]]
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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]
|
||||
----------------------------------------------------------------------
|
||||
|
|
|
@ -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,10 +274,10 @@ 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
|
||||
|
@ -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]
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
@ -31,7 +31,7 @@ The following snippet shows a simple `index` action definition:
|
|||
|
||||
|
||||
[[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
|
||||
|
|
|
@ -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]
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -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"]
|
||||
|======
|
||||
|
|
|
@ -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]
|
||||
|
|
|
@ -8,7 +8,7 @@ team's channels or users. To send Slack messages, you need to
|
|||
`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]
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -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.
|
||||
|
@ -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"]
|
||||
|======
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[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>>.
|
||||
|
@ -9,7 +9,7 @@ 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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
@ -46,7 +46,7 @@ than or equal to 25:
|
|||
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"]
|
||||
|======
|
||||
|
|
|
@ -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`.
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -1,15 +1,14 @@
|
|||
[role="xpack"]
|
||||
[[condition-script]]
|
||||
=== Script Condition
|
||||
=== Script condition
|
||||
|
||||
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`:
|
||||
|
@ -27,7 +26,7 @@ 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]
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -1,15 +1,16 @@
|
|||
[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
|
||||
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
|
||||
|
@ -21,7 +22,7 @@ be evaluated based on the data in this payload).
|
|||
<<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
|
||||
|
@ -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],
|
||||
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,7 +113,7 @@ 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
|
||||
into a watch payload. The inputs in a chain are processed in order, so the the
|
||||
|
@ -121,7 +122,7 @@ 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.
|
||||
|
@ -133,7 +134,7 @@ determines whether the actions associated with the watch should execute or not.
|
|||
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,7 +184,7 @@ 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.
|
||||
|
@ -197,7 +198,7 @@ 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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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[]
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[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:
|
||||
|
@ -15,7 +15,7 @@ Elasticsearch cluster:
|
|||
|
||||
[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.
|
||||
|
@ -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,7 +124,7 @@ 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
|
||||
determines if any action is required. Since you've defined an input that loads
|
||||
|
@ -174,7 +178,7 @@ 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
|
||||
|
@ -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]
|
||||
-------------------------------------------------------
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[xpack-alerting]]
|
||||
= Alerting on Cluster and Index Events
|
||||
= Alerting on cluster and index events
|
||||
|
||||
[partintro]
|
||||
--
|
||||
|
|
|
@ -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].
|
||||
<<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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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,7 +136,7 @@ http://openweathermap.org/appid[OpenWeatherMap] service:
|
|||
--------------------------------------------------
|
||||
// NOTCONSOLE
|
||||
|
||||
==== Using Templates
|
||||
==== Using templates
|
||||
|
||||
The `http` input supports templating. You can use <<templates,templates>> when
|
||||
specifying the `path`, `body`, header values, and parameter values.
|
||||
|
@ -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"]
|
||||
|======
|
||||
|
|
|
@ -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,7 +171,7 @@ 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>>.
|
||||
|
||||
|
@ -180,13 +179,13 @@ accurately.
|
|||
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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
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]
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -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
|
||||
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]
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -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
|
||||
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]
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[float]
|
||||
[[api-java-get-watch]]
|
||||
=== Get Watch API
|
||||
=== Get watch API
|
||||
|
||||
This API retrieves a watch by its id.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -211,7 +211,7 @@ October 28, 2015
|
|||
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>>
|
||||
of values in the <<watch-execution-context,Watch execution context model>>
|
||||
to a given value.
|
||||
|
||||
.Enhancements
|
||||
|
@ -287,27 +287,27 @@ June 19, 2015
|
|||
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>>
|
||||
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
|
||||
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>>.
|
||||
* Added support for separate keystore and truststore in <<actions-webhook,webhook action>>
|
||||
and <<input-http,HTTP input>>.
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
[[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`>>.
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
[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
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
[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:
|
||||
|
||||
|
@ -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>>.
|
||||
|
||||
|
|
|
@ -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,32 +48,32 @@ 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>>.
|
||||
|
||||
| `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.
|
||||
|
@ -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
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[trigger-schedule]]
|
||||
=== Schedule Trigger
|
||||
=== Schedule trigger
|
||||
|
||||
Schedule <<trigger,triggers>> define when the watch execution should start based
|
||||
on date and time. All times are specified in UTC time.
|
||||
|
@ -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:
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@ WARNING: While `cron` triggers are super powerful, we recommend using one of
|
|||
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.
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[schedule-daily]]
|
||||
==== Daily Schedule
|
||||
==== Daily schedule
|
||||
|
||||
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)
|
||||
|
@ -13,7 +13,7 @@ reserved values `midnight` and `noon` for `00:00` and `12:00`, and
|
|||
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.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[schedule-hourly]]
|
||||
==== Hourly Schedule
|
||||
==== Hourly schedule
|
||||
|
||||
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)
|
||||
|
@ -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
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[schedule-interval]]
|
||||
==== Interval Schedule
|
||||
==== Interval schedule
|
||||
|
||||
A <<trigger-schedule,`schedule`>> that triggers at a fixed time interval. The
|
||||
interval can be set in seconds, minutes, hours, days, or weeks:
|
||||
|
@ -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
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[schedule-monthly]]
|
||||
==== Monthly Schedule
|
||||
==== Monthly schedule
|
||||
|
||||
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
|
||||
|
@ -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`
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[schedule-weekly]]
|
||||
==== Weekly Schedule
|
||||
==== Weekly schedule
|
||||
|
||||
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
|
||||
|
@ -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`
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[schedule-yearly]]
|
||||
==== Yearly Schedule
|
||||
==== Yearly schedule
|
||||
|
||||
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
|
||||
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue