* [DOCS] Qualified Watcher topics to distinguish from Kib Alerting * Reverted actions anchor due to client links. * Updated redirects. * Fixed links. * Roll back anchor changes * Apply suggestions from code review Co-authored-by: James Rodewig <40268737+jrodewig@users.noreply.github.com> * Incorporated review comments.
This commit is contained in:
debadair
GitHub
parent
fb65fd8723
commit
55a9977d30
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[actions]]
|
||||
== Actions
|
||||
== {watcher} actions
|
||||
++++
|
||||
<titleabbrev>Actions</titleabbrev>
|
||||
++++
|
||||
|
||||
When a watch's condition is met, its actions are executed unless it is being
|
||||
<<actions-ack-throttle,throttled>>. A watch can perform multiple actions.
|
||||
|
|
@ -15,10 +18,14 @@ Actions have access to the payload in the execution context. They can use it to
|
|||
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`>>.
|
||||
{watcher} supports the following actions:
|
||||
|
||||
* <<actions-email,`email`>>
|
||||
* <<actions-webhook,`webhook`>>
|
||||
* <<actions-index,`index`>>
|
||||
* <<actions-logging,`logging`>>
|
||||
* <<actions-slack,`slack`>>
|
||||
* <<actions-pagerduty,`pagerduty`>>
|
||||
|
||||
[discrete]
|
||||
[[actions-ack-throttle]]
|
||||
|
|
@ -189,6 +196,21 @@ of a watch during its execution:
|
|||
|
||||
image::images/action-throttling.jpg[align="center"]
|
||||
|
||||
[discrete]
|
||||
[[actions-ssl-openjdk]]
|
||||
=== Using SSL/TLS with OpenJDK
|
||||
|
||||
As each distributor is free to choose how to package OpenJDK, it may happen,
|
||||
that even despite the exact same version, an OpenJDK distribution contains
|
||||
different parts under different Linux distributions.
|
||||
|
||||
This can lead to issues with any action or input that uses TLS, like the `jira`,
|
||||
`pagerduty`, `slack`, or `webhook` one, because of missing CA certs.
|
||||
If you encounter TLS errors, when writing watches that connect to TLS endpoints,
|
||||
you should try to upgrade to the latest available OpenJDK distribution for your
|
||||
platform and if that does not help, try to upgrade to Oracle JDK.
|
||||
|
||||
|
||||
[role="xpack"]
|
||||
[[action-foreach]]
|
||||
=== Running an action for each element in an array
|
||||
|
|
@ -237,7 +259,10 @@ PUT _watcher/watch/log_event_watch
|
|||
|
||||
[role="xpack"]
|
||||
[[action-conditions]]
|
||||
=== Adding conditions to actions
|
||||
=== Adding conditions to {watcher} actions
|
||||
++++
|
||||
<titleabbrev>Adding conditions to actions</titleabbrev>
|
||||
++++
|
||||
|
||||
When a watch is triggered, its condition determines whether or not to execute the
|
||||
watch actions. Within each action, you can also add a condition per action. These
|
||||
|
|
@ -302,6 +327,7 @@ PUT _watcher/watch/log_event_watch
|
|||
<1> A `condition` that only applies to the `notify_pager` action, which
|
||||
restricts its execution to when the condition succeeds (at least 5 hits in this case).
|
||||
|
||||
|
||||
include::actions/email.asciidoc[]
|
||||
|
||||
include::actions/webhook.asciidoc[]
|
||||
|
|
@ -316,16 +342,3 @@ include::actions/pagerduty.asciidoc[]
|
|||
|
||||
include::actions/jira.asciidoc[]
|
||||
|
||||
[discrete]
|
||||
[[actions-ssl-openjdk]]
|
||||
=== Using SSL/TLS with OpenJDK
|
||||
|
||||
As each distributor is free to choose how to package OpenJDK, it may happen,
|
||||
that even despite the exact same version, an OpenJDK distribution contains
|
||||
different parts under different Linux distributions.
|
||||
|
||||
This can lead to issues with any action or input that uses TLS, like the `jira`,
|
||||
`pagerduty`, `slack`, or `webhook` one, because of missing CA certs.
|
||||
If you encounter TLS errors, when writing watches that connect to TLS endpoints,
|
||||
you should try to upgrade to the latest available OpenJDK distribution for your
|
||||
platform and if that does not help, try to upgrade to Oracle JDK.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[actions-email]]
|
||||
=== Email action
|
||||
=== Watcher email action
|
||||
++++
|
||||
<titleabbrev>Email action</titleabbrev>
|
||||
++++
|
||||
|
||||
Use the `email` action to send email notifications. To send email, you must
|
||||
<<configuring-email, configure at least one email account>> in
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[actions-index]]
|
||||
=== Index action
|
||||
=== {watcher} index action
|
||||
++++
|
||||
<titleabbrev>Index action</titleabbrev>
|
||||
++++
|
||||
|
||||
Use the `index` action to index data into Elasticsearch.
|
||||
See <<index-action-attributes>> for the supported attributes.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[actions-jira]]
|
||||
=== Jira action
|
||||
=== {watcher} Jira action
|
||||
++++
|
||||
<titleabbrev>Jira action</titleabbrev>
|
||||
++++
|
||||
|
||||
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`.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[actions-logging]]
|
||||
=== Logging Action
|
||||
=== {watcher} logging Action
|
||||
++++
|
||||
<titleabbrev>Logging action</titleabbrev>
|
||||
++++
|
||||
|
||||
Use the `logging` action to log text to the standard Elasticsearch
|
||||
logs. See <<logging-action-attributes>> for the supported attributes.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[actions-pagerduty]]
|
||||
=== PagerDuty action
|
||||
=== {watcher} PagerDuty action
|
||||
++++
|
||||
<titleabbrev>PagerDuty action</titleabbrev>
|
||||
++++
|
||||
|
||||
Use the PagerDuty action to create events in https://pagerduty.com/[
|
||||
PagerDuty]. To create PagerDuty events, you must <<configuring-pagerduty,
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[actions-slack]]
|
||||
=== Slack Action
|
||||
=== {watcher} Slack Action
|
||||
++++
|
||||
<titleabbrev>Slack action</titleabbrev>
|
||||
++++
|
||||
|
||||
Use the `slack` action to send messages to a https://slack.com/[Slack]
|
||||
team's channels or users. To send Slack messages, you need to
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[actions-webhook]]
|
||||
=== Webhook action
|
||||
=== {watcher} webhook action
|
||||
++++
|
||||
<titleabbrev>Webhook action</titleabbrev>
|
||||
++++
|
||||
|
||||
Use the `webhook` action to send a request to any web service. The
|
||||
webhook action supports both HTTP and HTTPS connections. See
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[condition]]
|
||||
== Conditions
|
||||
== {watcher} conditions
|
||||
++++
|
||||
<titleabbrev>Conditions</titleabbrev>
|
||||
++++
|
||||
|
||||
When a watch is triggered, its condition determines whether or not to execute
|
||||
the watch actions. {watcher} supports the following condition types:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[condition-always]]
|
||||
=== Always condition
|
||||
=== {watcher} always condition
|
||||
++++
|
||||
<titleabbrev>Always condition</titleabbrev>
|
||||
++++
|
||||
|
||||
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>>.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[condition-array-compare]]
|
||||
=== Array compare condition
|
||||
=== {watcher} array compare condition
|
||||
++++
|
||||
<titleabbrev>Array compare condition</titleabbrev>
|
||||
++++
|
||||
|
||||
Use `array_compare` to compare an array of values in the execution context to a
|
||||
given value. See <<condition-compare-operators>>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[condition-compare]]
|
||||
=== Compare condition
|
||||
=== {watcher} compare condition
|
||||
++++
|
||||
<titleabbrev>Compare condition</titleabbrev>
|
||||
++++
|
||||
|
||||
Use the `compare` condition to perform a simple comparison against a value in
|
||||
the watch payload. You can use the `compare` condition without enabling
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[condition-never]]
|
||||
=== Never condition
|
||||
=== {watcher} never condition
|
||||
++++
|
||||
<titleabbrev>Never condition</titleabbrev>
|
||||
++++
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[condition-script]]
|
||||
=== Script condition
|
||||
=== {watcher} script condition
|
||||
++++
|
||||
<titleabbrev>Script condition</titleabbrev>
|
||||
++++
|
||||
|
||||
A watch <<condition,condition>> that evaluates a script. The default scripting
|
||||
language is `painless`. You can use any of the scripting languages supported by
|
||||
|
|
|
|||
|
|
@ -1,68 +0,0 @@
|
|||
[role="xpack"]
|
||||
[[xpack-alerting]]
|
||||
= Alerting on cluster and index events
|
||||
|
||||
[partintro]
|
||||
--
|
||||
You can watch for changes or anomalies in your data and perform the necessary
|
||||
actions in response. For example, you might want to:
|
||||
|
||||
* Monitor social media as another way to detect failures in user-facing
|
||||
automated systems like ATMs or ticketing systems. When the number of tweets
|
||||
and posts in an area exceeds a threshold of significance, notify a service
|
||||
technician.
|
||||
|
||||
* Monitor your infrastructure, tracking disk usage over time. Open a helpdesk
|
||||
ticket when any servers are likely to run out of free space in the next few
|
||||
days.
|
||||
|
||||
* Track network activity to detect malicious activity, and proactively change
|
||||
firewall configuration to reject the malicious user.
|
||||
|
||||
* Monitor Elasticsearch, and send immediate notification to the system
|
||||
administrator if nodes leave the cluster or query throughput exceeds an
|
||||
expected range.
|
||||
|
||||
* Track application response times and if page-load time exceeds SLAs for more
|
||||
than 5 minutes, open a helpdesk ticket. If SLAs are exceeded for an hour,
|
||||
page the administrator on duty.
|
||||
|
||||
All of these use-cases share a few key properties:
|
||||
|
||||
* The relevant data or changes in data can be identified with a periodic
|
||||
Elasticsearch query.
|
||||
|
||||
* The results of the query can be checked against a condition.
|
||||
|
||||
* One or more actions are taken if the condition is true -- an email is sent, a
|
||||
3rd party system is notified, or the query results are stored.
|
||||
|
||||
[discrete]
|
||||
=== How watches work
|
||||
|
||||
The {alert-features} provide an API for creating, managing and testing _watches_.
|
||||
A watch describes a single alert and can contain multiple notification actions.
|
||||
|
||||
A watch is constructed from four simple building blocks:
|
||||
|
||||
Schedule:: A schedule for running a query and checking the condition.
|
||||
|
||||
Query:: The query to run as input to the condition. Watches
|
||||
support the full Elasticsearch query language, including
|
||||
aggregations.
|
||||
|
||||
Condition:: A condition that determines whether or not to execute the actions.
|
||||
You can use simple conditions (always true), or use scripting for
|
||||
more sophisticated scenarios.
|
||||
|
||||
Actions:: One or more actions, such as sending email, pushing data to
|
||||
3rd party systems through a webhook, or indexing the results of
|
||||
the query.
|
||||
|
||||
A full history of all watches is maintained in an Elasticsearch index. This
|
||||
history keeps track of each time a watch is triggered and records the results
|
||||
from the query, whether the condition was met, and what actions were taken.
|
||||
|
||||
--
|
||||
|
||||
include::getting-started.asciidoc[]
|
||||
|
|
@ -1,11 +1,16 @@
|
|||
[role="xpack"]
|
||||
[[xpack-alerting]]
|
||||
= Alerting on cluster and index events
|
||||
= Watch for cluster and index events
|
||||
|
||||
[partintro]
|
||||
--
|
||||
The {alert-features} enable you to watch
|
||||
for changes or anomalies in your data and perform the necessary actions in
|
||||
TIP: {kib} Alerting provides a set of built-in actions and alerts
|
||||
that are integrated with applications such as APM, Metrics, Security, and Uptime.
|
||||
You can use {kib} Alerting to detect complex conditions within different {kib} apps
|
||||
and trigger actions when those conditions are met.
|
||||
For more information, see {kibana-ref}/alerting-getting-started.html[Alerting and actions].
|
||||
|
||||
You can watch for changes or anomalies in your data and perform the necessary actions in
|
||||
response. For example, you might want to:
|
||||
|
||||
* Monitor social media as another way to detect failures in user-facing
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[input]]
|
||||
== Inputs
|
||||
== {watcher} inputs
|
||||
++++
|
||||
<titleabbrev>Inputs</titleabbrev>
|
||||
++++
|
||||
|
||||
When a watch is triggered, its _input_ loads data into the execution
|
||||
context. This payload is accessible during the subsequent watch execution
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[input-chain]]
|
||||
=== Chain input
|
||||
=== {watcher} chain input
|
||||
++++
|
||||
<titleabbrev>Chain input</titleabbrev>
|
||||
++++
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[input-http]]
|
||||
=== HTTP input
|
||||
=== {watcher} HTTP input
|
||||
++++
|
||||
<titleabbrev>HTTP input</titleabbrev>
|
||||
++++
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[input-search]]
|
||||
=== Search input
|
||||
=== {watcher} search input
|
||||
++++
|
||||
<titleabbrev>Search input</titleabbrev>
|
||||
++++
|
||||
|
||||
Use the `search` input to load the results of an Elasticsearch search request
|
||||
into the execution context when the watch is triggered. See
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[input-simple]]
|
||||
=== Simple input
|
||||
=== {watcher} simple input
|
||||
++++
|
||||
<titleabbrev>Simple input</titleabbrev>
|
||||
++++
|
||||
|
||||
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,6 +1,6 @@
|
|||
[discrete]
|
||||
[[api-java-service]]
|
||||
=== Service API
|
||||
=== {watcher} service API
|
||||
|
||||
The {watcher} `service` API allows the control the lifecycle of the {watcher}
|
||||
service. The following example starts the watcher service:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
[discrete]
|
||||
[[api-java-stats]]
|
||||
=== Stats API
|
||||
=== {watcher} stats API
|
||||
|
||||
The `stats` API returns the current {watcher} metrics. You can control what
|
||||
metrics this API returns using the `metric` parameter.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
[role="xpack"]
|
||||
[[watcher-limitations]]
|
||||
== Watcher limitations
|
||||
== {watcher} limitations
|
||||
[subs="attributes"]
|
||||
++++
|
||||
<titleabbrev>Limitations</titleabbrev>
|
||||
|
|
|
|||
|
|
@ -1,313 +0,0 @@
|
|||
[role="xpack"]
|
||||
[[watcher-release-notes]]
|
||||
== Watcher Release Notes (Pre-5.0)
|
||||
|
||||
[discrete]
|
||||
[[watcher-change-list]]
|
||||
=== Change List
|
||||
|
||||
[discrete]
|
||||
==== 2.4.2
|
||||
November 22, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* Deleting a watch now is independent from its current execution state in
|
||||
order to prevent failed deletions with watches having small intervals
|
||||
* Chain input: Parsing now throws an exception if a data structure is added, that cannot keep its order
|
||||
|
||||
[discrete]
|
||||
==== 2.4.1
|
||||
September 28, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* Fixed a serialization error that resulted in the watch history not being
|
||||
written when a proxy is specified in a watch.
|
||||
* Triggered watches are now correctly deleted from the `.triggered-watches`
|
||||
index if they are rejected due to a full thread pool.
|
||||
* Deleting or closing the `.watches` index now correctly cleans up the
|
||||
in-memory watch store so the watches are no longer executed.
|
||||
* If the HTTP request for an attachment fails, the error message is included
|
||||
in the watch history.
|
||||
* Fixed a possible exception when chained inputs don't execute successfully.
|
||||
|
||||
.Enhancements
|
||||
* Hostname verification can be disabled for Watcher
|
||||
HTTP actions.
|
||||
* Running watches can be updated and deleted.
|
||||
|
||||
[discrete]
|
||||
==== 2.4.0
|
||||
August 31, 2016
|
||||
|
||||
.Enhancements
|
||||
* The HTTP headers of a response are now part of the payload and can be accessed via `ctx.payload._headers`
|
||||
|
||||
|
||||
[discrete]
|
||||
==== 2.3.5
|
||||
August 3, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* The watch history was not written, if one of the chained inputs resulted in a failure as well as an input containing a field name with dots
|
||||
* Status of an acked watch, whose condition evaluates to false again is now properly persisted and not lost in case of a master node switch
|
||||
* Fixed the watch history template so payloads and request bodies are handled
|
||||
correctly. To update an existing installation, delete the existing watch history
|
||||
template by running `DELETE /_template/watch_history` and the correct template
|
||||
will be autocreated. To verify the template is recreated, call `GET
|
||||
/_template/watch_history`. Note that this just updates the template, so you
|
||||
need to wait one day for this update to take effect when a new history index is
|
||||
created.
|
||||
* The `watcher.http.proxy.port` setting for global proxy configuration was not applied correctly.
|
||||
|
||||
[discrete]
|
||||
==== 2.3.4
|
||||
July 7, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* Putting a new watch with state `active=false` now stores that state correctly
|
||||
on a multi node cluster.
|
||||
* Fixed the watch history template so nested request bodies are handled
|
||||
correctly. To update an existing installation, delete the existing watch history
|
||||
template by running `DELETE /_template/watch_history` and the correct template
|
||||
will be autocreated. To verify the template is recreated, call `GET
|
||||
/_template/watch_history`. Note that this just updates the template, so you
|
||||
need to wait one day for this update to take effect when a new history index is
|
||||
created.
|
||||
* The HTML sanitizer now supports border and cellpadding attributes on table
|
||||
elements and the colspan and rowspan attributes on <td> and <tr> elements.
|
||||
* Fixed the Watcher/Marvel examples in the documentation.
|
||||
|
||||
[discrete]
|
||||
==== 2.3.3
|
||||
May 18, 2016
|
||||
|
||||
.Enhancements
|
||||
* Adds support for Elasticsearch 2.3.3
|
||||
|
||||
[discrete]
|
||||
==== 2.3.2
|
||||
April 26, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* All SMTP connection timeouts are now set to two minutes by default to prevent
|
||||
a watch from getting stuck.
|
||||
* HTTP headers from responses that contained dots led to exceptions when the
|
||||
HTTP response was stored in the watch history. All dots in any header names
|
||||
are now replaced with underscores. For example, a header called `foo.bar`
|
||||
becomes `foo_bar`
|
||||
* Hipchat action: Fall back to the default Hipchat color and format if they
|
||||
are not specified at the account level or within the action itself, instead
|
||||
of failing.
|
||||
|
||||
[discrete]
|
||||
==== 2.3.1
|
||||
April 4, 2016
|
||||
|
||||
.Enhancements
|
||||
* Adds support for Elasticsearch 2.3.1
|
||||
|
||||
[discrete]
|
||||
==== 2.3.0
|
||||
March 30, 2016
|
||||
|
||||
.Bug fixes
|
||||
* The http client does not do any URL escaping by itself anymore, preventing
|
||||
potential wrong double escapes.
|
||||
|
||||
.Enhancement
|
||||
* Support `url` in http requests as a shortcut for `path`, `scheme`, `port`, `params`
|
||||
* Support `ignore_condition` and `record_execution` as parameters in the
|
||||
{ref}/watcher-api-execute-watch.html[Execute Watch API]
|
||||
|
||||
.New Features
|
||||
* Added <<actions-pagerduty,PagerDuty action>>
|
||||
* Added support for adding <<configuring-email-attachments,attachments to emails>>
|
||||
via HTTP requests and superseding and deprecating the usage of `attach_data`
|
||||
in order to use this feature
|
||||
|
||||
[discrete]
|
||||
==== 2.2.1
|
||||
March 10, 2016
|
||||
|
||||
.Bug Fixes
|
||||
* The `croneval` CLI tool sets the correct environment to run
|
||||
|
||||
[discrete]
|
||||
==== 2.2.0
|
||||
February 2, 2016
|
||||
|
||||
.Enhancements
|
||||
* Adds support for Elasticsearch 2.2.0.
|
||||
|
||||
[discrete]
|
||||
==== 2.1.2
|
||||
February 2, 2016
|
||||
|
||||
.Enhancements
|
||||
* Adds support for Elasticsearch 2.1.2
|
||||
|
||||
[discrete]
|
||||
==== 2.1.1
|
||||
December 17, 2015
|
||||
|
||||
.Bug Fixes
|
||||
* Fixed an issue that prevented sending of emails
|
||||
|
||||
[discrete]
|
||||
==== 2.1.0
|
||||
November 24, 2015
|
||||
|
||||
.New Features
|
||||
* Adds support for <<input-chain,chaining several inputs>>
|
||||
|
||||
.Enhancements
|
||||
* Adds support for Elasticsearch 2.1.0.
|
||||
* Adds support for configuring a proxy in the webhook action, http input and
|
||||
configuring a default proxy (which is also used by the slack action), using the
|
||||
`watcher.http.proxy.host` and `watcher.http.proxy.port` settings.
|
||||
|
||||
.Bug Fixes
|
||||
* Fixed an issue where the scheduler may get stuck during Watcher startup. This
|
||||
caused no watches to ever fire.
|
||||
* Fixed an issue where under specific conditions Watcher would not start if there
|
||||
are not finished watch executions from the previous time that watcher was
|
||||
running and those watch execution are unable the execute during the current
|
||||
start process.
|
||||
|
||||
[discrete]
|
||||
==== 2.0.1
|
||||
November 24, 2015
|
||||
|
||||
.Enhancement
|
||||
* Adds support for Elasticsearch 2.0.1.
|
||||
|
||||
.Bug fixes
|
||||
* Fixed an issue where under specific conditions Watcher would not start if
|
||||
there are not finished watch executions from the previous time that watcher
|
||||
was running and those watch execution are unable the execute during the current
|
||||
start process.
|
||||
|
||||
[discrete]
|
||||
==== 2.0.0
|
||||
October 28, 2015
|
||||
|
||||
.Breaking Changes
|
||||
* The dynamic index names support has been removed and Elasticsearch's date math
|
||||
index names support should be used instead. The only difference between Watcher's
|
||||
dynamic index names support and Elasticsearch's date math index names support is
|
||||
how timezones are expressed. In Watcher this is done via node settings, in
|
||||
Elasticsearch the timezone is part of the date math index names support. Only
|
||||
if you're using dynamic index names with timezones in Watcher then you need to
|
||||
upgrade your watches after the upgrade, otherwise your watches will work as
|
||||
they did before the upgrade. For example if `watcher.dynamic_indices.time_zone`
|
||||
setting was set to `+01:00` and a watch has the following index name
|
||||
`<logstash-{now/d}>` then after the upgrade you need to update this watch to
|
||||
use the following index name `<logstash-{now/d{YYYY.MM.dd|+01:00}}>`.
|
||||
|
||||
.New Features
|
||||
* Added new <<actions-hipchat,HipChat Action>>
|
||||
* Added new <<actions-slack,Slack Action>>
|
||||
* Watches now have an <<watch-active-state,active state>>. In addition, a new
|
||||
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>>
|
||||
to a given value.
|
||||
|
||||
.Enhancements
|
||||
* Watcher continuously checks if the index templates for `.watches`,
|
||||
`.triggered_watches` and `.watch_history-*` exist. Whereas before the existence
|
||||
of these index templates was only checked at Watcher startup time. The absence
|
||||
of these index templates leads to watcher data being indexed incorrectly, which
|
||||
then can cause Watcher to behave incorrectly.
|
||||
* If Watcher was stopped via the stop Watcher api and after that a master
|
||||
election took place then Watcher would then unexpectedly start.
|
||||
* During Watcher start up only wait for the shards of the `.watches` and
|
||||
`.triggered_watches` indices to be available. Before Watcher also waited for
|
||||
the shards of the `.watch_history-*` indices, which wasn't needed. This
|
||||
improved time it takes for Watcher to startup.
|
||||
* If `action.auto_create_index` setting has been configured then Watcher will
|
||||
check if the setting is too restrictive. If the `action.auto_create_index` is
|
||||
too restrictive then Watcher will fail during startup with a descriptive error
|
||||
message.
|
||||
|
||||
.Bug Fixes
|
||||
* If Watcher was installed with Security then the Watcher index templates couldn't
|
||||
be stored and could lead to Watcher behaving incorrectly. This was caused by
|
||||
Watcher not detecting correctly if Security was installed.
|
||||
* Update `croneval` command line utility to properly handle whitespaces in the
|
||||
elasticsearch home path.
|
||||
* Fixed an issue where the scheduler may get stuck during Watcher startup. This
|
||||
caused no watches to ever fire.
|
||||
* Fixed url encoding issue in http input and webhook output. The url params were
|
||||
url encoded twice.
|
||||
|
||||
[discrete]
|
||||
==== 1.0.1
|
||||
July 29, 2015
|
||||
|
||||
.Enhancements
|
||||
* Dynamic index names now support specifying a time zone to be used when
|
||||
computing the names of the indices. The default is UTC. Previously, the
|
||||
computation was fixed to always use UTC when computing the names of the
|
||||
indices.
|
||||
|
||||
.Bug Fixes
|
||||
* Fixed a compatibility issue with Elasticsearch 1.6.1 and 1.7.2, which were
|
||||
released earlier today.
|
||||
|
||||
[discrete]
|
||||
==== 1.0.0
|
||||
June 25, 2015
|
||||
|
||||
.Enhancements
|
||||
* Added execution time aware dynamic index names support to `index`
|
||||
action, `search` input, and `search` transform.
|
||||
* You must now explicitly specify the unit when configuring any time value.
|
||||
(Numeric-only values are no longer supported.)
|
||||
* Cleaned up the {ref}/watcher-api-get-watch.html[Get Watch API] response.
|
||||
* Cleaned up the <<watcher-api-stats, Stats API>> response.
|
||||
|
||||
|
||||
[discrete]
|
||||
==== 1.0.0-rc1
|
||||
June 19, 2015
|
||||
|
||||
.New Features
|
||||
* Added <<watcher-api-execute-inline-watch,inline watch>> support to the Execute API
|
||||
|
||||
.Enhancements
|
||||
* Added execution context <<watch-execution-context,variables>> support.
|
||||
* Email html body sanitization is now <<email-html-sanitization,configurable>>.
|
||||
* It is now possible to configure timeouts for http requests in
|
||||
<<http-input-attributes,HTTP input>> and <<webhook-action-attributes,webhook actions>>.
|
||||
|
||||
[discrete]
|
||||
==== 1.0.0-Beta2
|
||||
June 10, 2015
|
||||
|
||||
.New Features
|
||||
* <<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 currently-executing watches metric that's accessible via the
|
||||
<<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
|
||||
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>>.
|
||||
|
||||
.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>>.
|
||||
|
|
@ -1,11 +1,17 @@
|
|||
[role="xpack"]
|
||||
[[transform]]
|
||||
== {watcher-transforms-cap}
|
||||
++++
|
||||
<titleabbrev>Transforms</titleabbrev>
|
||||
++++
|
||||
|
||||
A _{watcher-transform}_ processes and changes the payload in the watch execution
|
||||
context to prepare it for the watch actions. {watcher} supports three types of
|
||||
{watcher-transforms}: <<transform-search,`search`>>,
|
||||
<<transform-script,`script`>> and <<transform-chain,`chain`>>.
|
||||
{watcher-transforms}:
|
||||
|
||||
* <<transform-search,`search`>>
|
||||
* <<transform-script,`script`>>
|
||||
* <<transform-chain,`chain`>>
|
||||
|
||||
|
||||
NOTE: {watcher-transforms-cap} are optional. When none are defined, the actions
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[transform-chain]]
|
||||
=== Chain {watcher-transform}
|
||||
=== {watcher} chain {watcher-transform}
|
||||
++++
|
||||
<titleabbrev>Chain {watcher-transform}</titleabbrev>
|
||||
++++
|
||||
|
||||
A <<transform,{watcher-transform}>> that executes an ordered list of configured
|
||||
{watcher-transforms} in a chain, where the output of one transform serves as the
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[transform-script]]
|
||||
=== Script {watcher-transform}
|
||||
=== {watcher} script {watcher-transform}
|
||||
++++
|
||||
<titleabbrev>Script {watcher-transform}</titleabbrev>
|
||||
++++
|
||||
|
||||
A <<transform,{watcher-transform}>> that executes a script on the current
|
||||
payload in the watch execution context and replaces it with a newly generated
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[transform-search]]
|
||||
=== Search {watcher-transform}
|
||||
=== {watcher} search {watcher-transform}
|
||||
++++
|
||||
<titleabbrev>Search {watcher-transform}</titleabbrev>
|
||||
++++
|
||||
|
||||
A <<transform,{watcher-transform}>> that executes a search on the cluster and
|
||||
replaces the current payload in the watch execution context with the returned
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[trigger]]
|
||||
== Triggers
|
||||
== {watcher} triggers
|
||||
++++
|
||||
<titleabbrev>Triggers</titleabbrev>
|
||||
++++
|
||||
|
||||
Every watch must have a `trigger` that defines when the watch execution process
|
||||
should start. When you create a watch, its trigger is registered with the
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[trigger-schedule]]
|
||||
=== Schedule trigger
|
||||
=== {watcher} schedule trigger
|
||||
++++
|
||||
<titleabbrev>Schedule trigger</titleabbrev>
|
||||
++++
|
||||
|
||||
Schedule <<trigger,triggers>> define when the watch execution should start based
|
||||
on date and time. All times are specified in UTC time.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
[[schedule-cron]]
|
||||
==== Cron schedule
|
||||
==== {watcher} cron schedule
|
||||
++++
|
||||
<titleabbrev>Cron schedule</titleabbrev>
|
||||
++++
|
||||
|
||||
Defines a <<trigger-schedule, `schedule`>> using a <<cron-expressions, cron expression>>
|
||||
that specifiues when to execute a watch.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[schedule-daily]]
|
||||
==== Daily schedule
|
||||
==== {watcher} Daily schedule
|
||||
++++
|
||||
<titleabbrev>Daily schedule</titleabbrev>
|
||||
++++
|
||||
|
||||
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)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[schedule-hourly]]
|
||||
==== Hourly schedule
|
||||
==== {watcher} hourly schedule
|
||||
++++
|
||||
<titleabbrev>Hourly schedule</titleabbrev>
|
||||
++++
|
||||
|
||||
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)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[schedule-interval]]
|
||||
==== Interval schedule
|
||||
==== {watcher} interval schedule
|
||||
++++
|
||||
<titleabbrev>Interval schedule</titleabbrev>
|
||||
++++
|
||||
|
||||
A <<trigger-schedule,`schedule`>> that triggers at a fixed time interval. The
|
||||
interval can be set in seconds, minutes, hours, days, or weeks:
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[schedule-monthly]]
|
||||
==== Monthly schedule
|
||||
==== {watcher} monthly schedule
|
||||
++++
|
||||
<titleabbrev>Monthly schedule</titleabbrev>
|
||||
++++
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[schedule-weekly]]
|
||||
==== Weekly schedule
|
||||
==== {watcher} weekly schedule
|
||||
++++
|
||||
<titleabbrev>Weekly schedule</titleabbrev>
|
||||
++++
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
[role="xpack"]
|
||||
[[schedule-yearly]]
|
||||
==== Yearly schedule
|
||||
==== {watcher} yearly schedule
|
||||
++++
|
||||
<titleabbrev>Yearly schedule</titleabbrev>
|
||||
++++
|
||||
|
||||
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
|
||||
|
|
|
|||
Loading…
Reference in New Issue