* [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:
parent
fb65fd8723
commit
55a9977d30
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[actions]]
|
[[actions]]
|
||||||
== Actions
|
== {watcher} actions
|
||||||
|
++++
|
||||||
|
<titleabbrev>Actions</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
When a watch's condition is met, its actions are executed unless it is being
|
When a watch's condition is met, its actions are executed unless it is being
|
||||||
<<actions-ack-throttle,throttled>>. A watch can perform multiple actions.
|
<<actions-ack-throttle,throttled>>. A watch can perform multiple actions.
|
||||||
|
@ -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
|
support their execution in any way they need. For example, the payload might
|
||||||
serve as a model for a templated email body.
|
serve as a model for a templated email body.
|
||||||
|
|
||||||
{watcher} supports the following types of actions:
|
{watcher} supports the following actions:
|
||||||
<<actions-email,`email`>>, <<actions-webhook,`webhook`>>, <<actions-index,`index`>>,
|
|
||||||
<<actions-logging,`logging`>>, <<actions-slack,`slack`>>,
|
* <<actions-email,`email`>>
|
||||||
and <<actions-pagerduty,`pagerduty`>>.
|
* <<actions-webhook,`webhook`>>
|
||||||
|
* <<actions-index,`index`>>
|
||||||
|
* <<actions-logging,`logging`>>
|
||||||
|
* <<actions-slack,`slack`>>
|
||||||
|
* <<actions-pagerduty,`pagerduty`>>
|
||||||
|
|
||||||
[discrete]
|
[discrete]
|
||||||
[[actions-ack-throttle]]
|
[[actions-ack-throttle]]
|
||||||
|
@ -189,6 +196,21 @@ of a watch during its execution:
|
||||||
|
|
||||||
image::images/action-throttling.jpg[align="center"]
|
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"]
|
[role="xpack"]
|
||||||
[[action-foreach]]
|
[[action-foreach]]
|
||||||
=== Running an action for each element in an array
|
=== Running an action for each element in an array
|
||||||
|
@ -237,7 +259,10 @@ PUT _watcher/watch/log_event_watch
|
||||||
|
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[action-conditions]]
|
[[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
|
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
|
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
|
<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).
|
restricts its execution to when the condition succeeds (at least 5 hits in this case).
|
||||||
|
|
||||||
|
|
||||||
include::actions/email.asciidoc[]
|
include::actions/email.asciidoc[]
|
||||||
|
|
||||||
include::actions/webhook.asciidoc[]
|
include::actions/webhook.asciidoc[]
|
||||||
|
@ -316,16 +342,3 @@ include::actions/pagerduty.asciidoc[]
|
||||||
|
|
||||||
include::actions/jira.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"]
|
[role="xpack"]
|
||||||
[[actions-email]]
|
[[actions-email]]
|
||||||
=== Email action
|
=== Watcher email action
|
||||||
|
++++
|
||||||
|
<titleabbrev>Email action</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `email` action to send email notifications. To send email, you must
|
Use the `email` action to send email notifications. To send email, you must
|
||||||
<<configuring-email, configure at least one email account>> in
|
<<configuring-email, configure at least one email account>> in
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[actions-index]]
|
[[actions-index]]
|
||||||
=== Index action
|
=== {watcher} index action
|
||||||
|
++++
|
||||||
|
<titleabbrev>Index action</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `index` action to index data into Elasticsearch.
|
Use the `index` action to index data into Elasticsearch.
|
||||||
See <<index-action-attributes>> for the supported attributes.
|
See <<index-action-attributes>> for the supported attributes.
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[actions-jira]]
|
[[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].
|
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`.
|
To create issues you need to <<configuring-jira, configure at least one Jira account>> in `elasticsearch.yml`.
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[actions-logging]]
|
[[actions-logging]]
|
||||||
=== Logging Action
|
=== {watcher} logging Action
|
||||||
|
++++
|
||||||
|
<titleabbrev>Logging action</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `logging` action to log text to the standard Elasticsearch
|
Use the `logging` action to log text to the standard Elasticsearch
|
||||||
logs. See <<logging-action-attributes>> for the supported attributes.
|
logs. See <<logging-action-attributes>> for the supported attributes.
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[actions-pagerduty]]
|
[[actions-pagerduty]]
|
||||||
=== PagerDuty action
|
=== {watcher} PagerDuty action
|
||||||
|
++++
|
||||||
|
<titleabbrev>PagerDuty action</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the PagerDuty action to create events in https://pagerduty.com/[
|
Use the PagerDuty action to create events in https://pagerduty.com/[
|
||||||
PagerDuty]. To create PagerDuty events, you must <<configuring-pagerduty,
|
PagerDuty]. To create PagerDuty events, you must <<configuring-pagerduty,
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[actions-slack]]
|
[[actions-slack]]
|
||||||
=== Slack Action
|
=== {watcher} Slack Action
|
||||||
|
++++
|
||||||
|
<titleabbrev>Slack action</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `slack` action to send messages to a https://slack.com/[Slack]
|
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
|
team's channels or users. To send Slack messages, you need to
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[actions-webhook]]
|
[[actions-webhook]]
|
||||||
=== Webhook action
|
=== {watcher} webhook action
|
||||||
|
++++
|
||||||
|
<titleabbrev>Webhook action</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `webhook` action to send a request to any web service. The
|
Use the `webhook` action to send a request to any web service. The
|
||||||
webhook action supports both HTTP and HTTPS connections. See
|
webhook action supports both HTTP and HTTPS connections. See
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[condition]]
|
[[condition]]
|
||||||
== Conditions
|
== {watcher} conditions
|
||||||
|
++++
|
||||||
|
<titleabbrev>Conditions</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
When a watch is triggered, its condition determines whether or not to execute
|
When a watch is triggered, its condition determines whether or not to execute
|
||||||
the watch actions. {watcher} supports the following condition types:
|
the watch actions. {watcher} supports the following condition types:
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[condition-always]]
|
[[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
|
Use the `always` condition to set the condition to `true`. This forces the watch
|
||||||
actions to be executed unless they are <<actions-ack-throttle,throttled>>.
|
actions to be executed unless they are <<actions-ack-throttle,throttled>>.
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[condition-array-compare]]
|
[[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
|
Use `array_compare` to compare an array of values in the execution context to a
|
||||||
given value. See <<condition-compare-operators>>
|
given value. See <<condition-compare-operators>>
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[condition-compare]]
|
[[condition-compare]]
|
||||||
=== Compare condition
|
=== {watcher} compare condition
|
||||||
|
++++
|
||||||
|
<titleabbrev>Compare condition</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `compare` condition to perform a simple comparison against a value in
|
Use the `compare` condition to perform a simple comparison against a value in
|
||||||
the watch payload. You can use the `compare` condition without enabling
|
the watch payload. You can use the `compare` condition without enabling
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[condition-never]]
|
[[condition-never]]
|
||||||
=== Never condition
|
=== {watcher} never condition
|
||||||
|
++++
|
||||||
|
<titleabbrev>Never condition</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `never` condition to set the condition to `false`. This means the
|
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
|
watch actions are never executed when the watch is triggered. The watch input is
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[condition-script]]
|
[[condition-script]]
|
||||||
=== Script condition
|
=== {watcher} script condition
|
||||||
|
++++
|
||||||
|
<titleabbrev>Script condition</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
A watch <<condition,condition>> that evaluates a script. The default scripting
|
A watch <<condition,condition>> that evaluates a script. The default scripting
|
||||||
language is `painless`. You can use any of the scripting languages supported by
|
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"]
|
[role="xpack"]
|
||||||
[[xpack-alerting]]
|
[[xpack-alerting]]
|
||||||
= Alerting on cluster and index events
|
= Watch for cluster and index events
|
||||||
|
|
||||||
[partintro]
|
[partintro]
|
||||||
--
|
--
|
||||||
The {alert-features} enable you to watch
|
TIP: {kib} Alerting provides a set of built-in actions and alerts
|
||||||
for changes or anomalies in your data and perform the necessary actions in
|
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:
|
response. For example, you might want to:
|
||||||
|
|
||||||
* Monitor social media as another way to detect failures in user-facing
|
* Monitor social media as another way to detect failures in user-facing
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[input]]
|
[[input]]
|
||||||
== Inputs
|
== {watcher} inputs
|
||||||
|
++++
|
||||||
|
<titleabbrev>Inputs</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
When a watch is triggered, its _input_ loads data into the execution
|
When a watch is triggered, its _input_ loads data into the execution
|
||||||
context. This payload is accessible during the subsequent watch execution
|
context. This payload is accessible during the subsequent watch execution
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[input-chain]]
|
[[input-chain]]
|
||||||
=== Chain input
|
=== {watcher} chain input
|
||||||
|
++++
|
||||||
|
<titleabbrev>Chain input</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `chain` input to load data from multiple sources into the watch
|
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
|
execution context when the watch is triggered. The inputs in a chain
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[input-http]]
|
[[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
|
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
|
response into the watch execution context when the watch is triggered. See
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[input-search]]
|
[[input-search]]
|
||||||
=== Search input
|
=== {watcher} search input
|
||||||
|
++++
|
||||||
|
<titleabbrev>Search input</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `search` input to load the results of an Elasticsearch search request
|
Use the `search` input to load the results of an Elasticsearch search request
|
||||||
into the execution context when the watch is triggered. See
|
into the execution context when the watch is triggered. See
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[input-simple]]
|
[[input-simple]]
|
||||||
=== Simple input
|
=== {watcher} simple input
|
||||||
|
++++
|
||||||
|
<titleabbrev>Simple input</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Use the `simple` input to load static data into the execution
|
Use the `simple` input to load static data into the execution
|
||||||
context when the watch is triggered. This enables you to store the data
|
context when the watch is triggered. This enables you to store the data
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
[discrete]
|
[discrete]
|
||||||
[[api-java-service]]
|
[[api-java-service]]
|
||||||
=== Service API
|
=== {watcher} service API
|
||||||
|
|
||||||
The {watcher} `service` API allows the control the lifecycle of the {watcher}
|
The {watcher} `service` API allows the control the lifecycle of the {watcher}
|
||||||
service. The following example starts the watcher service:
|
service. The following example starts the watcher service:
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
[discrete]
|
[discrete]
|
||||||
[[api-java-stats]]
|
[[api-java-stats]]
|
||||||
=== Stats API
|
=== {watcher} stats API
|
||||||
|
|
||||||
The `stats` API returns the current {watcher} metrics. You can control what
|
The `stats` API returns the current {watcher} metrics. You can control what
|
||||||
metrics this API returns using the `metric` parameter.
|
metrics this API returns using the `metric` parameter.
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[watcher-limitations]]
|
[[watcher-limitations]]
|
||||||
== Watcher limitations
|
== {watcher} limitations
|
||||||
[subs="attributes"]
|
[subs="attributes"]
|
||||||
++++
|
++++
|
||||||
<titleabbrev>Limitations</titleabbrev>
|
<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"]
|
[role="xpack"]
|
||||||
[[transform]]
|
[[transform]]
|
||||||
== {watcher-transforms-cap}
|
== {watcher-transforms-cap}
|
||||||
|
++++
|
||||||
|
<titleabbrev>Transforms</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
A _{watcher-transform}_ processes and changes the payload in the watch execution
|
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
|
context to prepare it for the watch actions. {watcher} supports three types of
|
||||||
{watcher-transforms}: <<transform-search,`search`>>,
|
{watcher-transforms}:
|
||||||
<<transform-script,`script`>> and <<transform-chain,`chain`>>.
|
|
||||||
|
* <<transform-search,`search`>>
|
||||||
|
* <<transform-script,`script`>>
|
||||||
|
* <<transform-chain,`chain`>>
|
||||||
|
|
||||||
|
|
||||||
NOTE: {watcher-transforms-cap} are optional. When none are defined, the actions
|
NOTE: {watcher-transforms-cap} are optional. When none are defined, the actions
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[transform-chain]]
|
[[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
|
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
|
{watcher-transforms} in a chain, where the output of one transform serves as the
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[transform-script]]
|
[[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
|
A <<transform,{watcher-transform}>> that executes a script on the current
|
||||||
payload in the watch execution context and replaces it with a newly generated
|
payload in the watch execution context and replaces it with a newly generated
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[transform-search]]
|
[[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
|
A <<transform,{watcher-transform}>> that executes a search on the cluster and
|
||||||
replaces the current payload in the watch execution context with the returned
|
replaces the current payload in the watch execution context with the returned
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[trigger]]
|
[[trigger]]
|
||||||
== Triggers
|
== {watcher} triggers
|
||||||
|
++++
|
||||||
|
<titleabbrev>Triggers</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Every watch must have a `trigger` that defines when the watch execution process
|
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
|
should start. When you create a watch, its trigger is registered with the
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[trigger-schedule]]
|
[[trigger-schedule]]
|
||||||
=== Schedule trigger
|
=== {watcher} schedule trigger
|
||||||
|
++++
|
||||||
|
<titleabbrev>Schedule trigger</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Schedule <<trigger,triggers>> define when the watch execution should start based
|
Schedule <<trigger,triggers>> define when the watch execution should start based
|
||||||
on date and time. All times are specified in UTC time.
|
on date and time. All times are specified in UTC time.
|
||||||
|
|
|
@ -1,5 +1,8 @@
|
||||||
[[schedule-cron]]
|
[[schedule-cron]]
|
||||||
==== Cron schedule
|
==== {watcher} cron schedule
|
||||||
|
++++
|
||||||
|
<titleabbrev>Cron schedule</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
Defines a <<trigger-schedule, `schedule`>> using a <<cron-expressions, cron expression>>
|
Defines a <<trigger-schedule, `schedule`>> using a <<cron-expressions, cron expression>>
|
||||||
that specifiues when to execute a watch.
|
that specifiues when to execute a watch.
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[schedule-daily]]
|
[[schedule-daily]]
|
||||||
==== Daily schedule
|
==== {watcher} Daily schedule
|
||||||
|
++++
|
||||||
|
<titleabbrev>Daily schedule</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
A <<trigger-schedule,`schedule`>> that triggers at a particular time
|
A <<trigger-schedule,`schedule`>> that triggers at a particular time
|
||||||
every day. To use the `daily` schedule, you specify the time of day (or times)
|
every day. To use the `daily` schedule, you specify the time of day (or times)
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[schedule-hourly]]
|
[[schedule-hourly]]
|
||||||
==== Hourly schedule
|
==== {watcher} hourly schedule
|
||||||
|
++++
|
||||||
|
<titleabbrev>Hourly schedule</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
A <<trigger-schedule,`schedule`>> that triggers at a particular minute every
|
A <<trigger-schedule,`schedule`>> that triggers at a particular minute every
|
||||||
hour of the day. To use the `hourly` schedule, you specify the minute (or minutes)
|
hour of the day. To use the `hourly` schedule, you specify the minute (or minutes)
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[schedule-interval]]
|
[[schedule-interval]]
|
||||||
==== Interval schedule
|
==== {watcher} interval schedule
|
||||||
|
++++
|
||||||
|
<titleabbrev>Interval schedule</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
A <<trigger-schedule,`schedule`>> that triggers at a fixed time interval. The
|
A <<trigger-schedule,`schedule`>> that triggers at a fixed time interval. The
|
||||||
interval can be set in seconds, minutes, hours, days, or weeks:
|
interval can be set in seconds, minutes, hours, days, or weeks:
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[schedule-monthly]]
|
[[schedule-monthly]]
|
||||||
==== Monthly schedule
|
==== {watcher} monthly schedule
|
||||||
|
++++
|
||||||
|
<titleabbrev>Monthly schedule</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
A <<trigger-schedule,`schedule`>> that triggers at a specific day and time
|
A <<trigger-schedule,`schedule`>> that triggers at a specific day and time
|
||||||
every month. To use the `monthly` schedule, you specify the day of the month and
|
every month. To use the `monthly` schedule, you specify the day of the month and
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[schedule-weekly]]
|
[[schedule-weekly]]
|
||||||
==== Weekly schedule
|
==== {watcher} weekly schedule
|
||||||
|
++++
|
||||||
|
<titleabbrev>Weekly schedule</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
A <<trigger-schedule,`schedule`>> that triggers at a specific day and time
|
A <<trigger-schedule,`schedule`>> that triggers at a specific day and time
|
||||||
every week. To use the `weekly` schedule, you specify the day and time (or days
|
every week. To use the `weekly` schedule, you specify the day and time (or days
|
||||||
|
|
|
@ -1,6 +1,9 @@
|
||||||
[role="xpack"]
|
[role="xpack"]
|
||||||
[[schedule-yearly]]
|
[[schedule-yearly]]
|
||||||
==== Yearly schedule
|
==== {watcher} yearly schedule
|
||||||
|
++++
|
||||||
|
<titleabbrev>Yearly schedule</titleabbrev>
|
||||||
|
++++
|
||||||
|
|
||||||
A <<trigger-schedule,`schedule`>> that triggers at a specific day and time
|
A <<trigger-schedule,`schedule`>> that triggers at a specific day and time
|
||||||
every year. To use the `yearly` schedule, you specify the month, day, and time
|
every year. To use the `yearly` schedule, you specify the month, day, and time
|
||||||
|
|
Loading…
Reference in New Issue