- X-Pack Reference for 6.0-6.2 and 5.x:
- Introduction
- Setting Up X-Pack
- Breaking Changes
- X-Pack APIs
- Graphing Connections in Your Data
- Profiling your Queries and Aggregations
- Reporting from Kibana
- Securing the Elastic Stack
- Getting Started with Security
- How Security Works
- Setting Up User Authentication
- Configuring SAML Single-Sign-On on the Elastic Stack
- Configuring Role-based Access Control
- Auditing Security Events
- Encrypting Communications
- Restricting Connections with IP Filtering
- Cross Cluster Search, Tribe, Clients and Integrations
- Reference
- Monitoring the Elastic Stack
- Alerting on Cluster and Index Events
- Machine Learning in the Elastic Stack
- Troubleshooting
- Getting Help
- X-Pack security
- Can’t log in after upgrading to 6.2.4
- Some settings are not returned via the nodes settings API
- Authorization exceptions
- Users command fails due to extra arguments
- Users are frequently locked out of Active Directory
- Certificate verification fails for curl on Mac
- SSLHandshakeException causes connections to fail
- Common SSL/TLS exceptions
- Internal Server Error in Kibana
- Setup-passwords command fails due to connection failure
- X-Pack Watcher
- X-Pack monitoring
- X-Pack machine learning
- Limitations
- License Management
- Release Notes
WARNING: Version 6.2 of the Elastic Stack has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Watching the Status of an Elasticsearch Cluster
editWatching the Status of an Elasticsearch Cluster
editYou can easily configure a basic watch to monitor the health of your Elasticsearch cluster:
- Schedule the watch and define an input that gets the cluster health status.
- Add a condition that evaluates the health status to determine if action is required.
- Take action if the cluster is RED.
Schedule the Watch and Add an Input
editA watch schedule controls how often a watch is triggered. The watch input gets the data that you want to evaluate.
The simplest way to define a schedule is to specify an interval. For example, the following schedule runs every 10 seconds:
PUT _xpack/watcher/watch/cluster_health_watch { "trigger" : { "schedule" : { "interval" : "10s" } } }
Schedules are typically configured to run less frequently. This example sets the interval to 10 seconds to you can easily see the watches being triggered. Since this watch runs so frequently, don’t forget to delete the watch when you’re done experimenting. |
To get the status of your cluster, you can call the Elasticsearch cluster health API:
GET _cluster/health?pretty
To load the health status into your watch, you simply add an HTTP input that calls the cluster health API:
PUT _xpack/watcher/watch/cluster_health_watch { "trigger" : { "schedule" : { "interval" : "10s" } }, "input" : { "http" : { "request" : { "host" : "localhost", "port" : 9200, "path" : "/_cluster/health" } } } }
If you’re using Security, then you’ll also need to supply some authentication credentials as part of the watch configuration:
PUT _xpack/watcher/watch/cluster_health_watch { "trigger" : { "schedule" : { "interval" : "10s" } }, "input" : { "http" : { "request" : { "host" : "localhost", "port" : 9200, "path" : "/_cluster/health", "auth": { "basic": { "username": "elastic", "password": "x-pack-test-password" } } } } } }
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 Notification Settings.
If you check the watch history, you’ll see that the cluster status is recorded
as part of the watch_record
each time the watch executes.
For example, the following request retrieves the last ten watch records from the watch history:
GET .watcher-history*/_search { "sort" : [ { "result.execution_time" : "desc" } ] }
Add a Condition
editA condition evaluates the data you’ve loaded into the watch and determines if any action is required. Since you’ve defined an input that loads the cluster status into the watch, you can define a condition that checks that status.
For example, you could add a condition to check to see if the status is RED.
PUT _xpack/watcher/watch/cluster_health_watch { "trigger" : { "schedule" : { "interval" : "10s" } }, "input" : { "http" : { "request" : { "host" : "localhost", "port" : 9200, "path" : "/_cluster/health" } } }, "condition" : { "compare" : { "ctx.payload.status" : { "eq" : "red" } } } }
Schedules are typically configured to run less frequently. This example sets the interval to 10 seconds to you can easily see the watches being triggered. |
If you check the watch history, you’ll see that the condition result is recorded
as part of the watch_record
each time the watch executes.
To check to see if the condition was met, you can run the following query.
GET .watcher-history*/_search?pretty { "query" : { "match" : { "result.condition.met" : true } } }
Take Action
editRecording watch_records
in the watch history is nice, but the real power of
Watcher is being able to do something in response to an alert. A watch’s
actions define what to do when the watch condition is true—you
can send emails, call third-party webhooks, or write documents to an
Elasticsearch index or log when the watch condition is met.
For example, you could add an action to index the cluster status information when the status is RED.
PUT _xpack/watcher/watch/cluster_health_watch { "trigger" : { "schedule" : { "interval" : "10s" } }, "input" : { "http" : { "request" : { "host" : "localhost", "port" : 9200, "path" : "/_cluster/health" } } }, "condition" : { "compare" : { "ctx.payload.status" : { "eq" : "red" } } }, "actions" : { "send_email" : { "email" : { "to" : "<username>@<domainname>", "subject" : "Cluster Status Warning", "body" : "Cluster status is RED" } } } }
For Watcher to send email, you must configure an email account in your
elasticsearch.yml
configuration file and restart Elasticsearch. To add an email
account, set the xpack.notification.email.account
property.
For example, the following snippet configures a single Gmail account named work
:
xpack.notification.email.account: work: profile: gmail email_defaults: from: <email> smtp: auth: true starttls.enable: true host: smtp.gmail.com port: 587 user: <username> password: <password>
Replace |
|
Replace |
|
Replace |
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 Working with Various Email Services.
You can check the watch history or the status_index
to see that the action was
performed.
GET .watcher-history*/_search?pretty { "query" : { "match" : { "result.condition.met" : true } } }
Delete the Watch
editSince 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 DELETE watch API:
DELETE _xpack/watcher/watch/cluster_health_watch