mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-06 13:08:29 +00:00
This is related to elastic/x-pack-elasticsearch#1217. This PR removes the default password of "changeme" from the reserved users. This PR adds special behavior for authenticating the reserved users. No ReservedRealm user can be authenticated until its password is set. The one exception to this is the elastic user. The elastic user can be authenticated with an empty password if the action is a rest request originating from localhost. In this scenario where an elastic user is authenticated with a default password, it will have metadata indicating that it is in setup mode. An elastic user in setup mode is only authorized to execute a change password request. Original commit: elastic/x-pack-elasticsearch@e1e101a237
287 lines
8.2 KiB
Plaintext
287 lines
8.2 KiB
Plaintext
[[watch-cluster-status]]
|
|
=== Watching the Status of an Elasticsearch Cluster
|
|
|
|
You can easily configure a basic watch to monitor the health of your
|
|
Elasticsearch cluster:
|
|
|
|
* <<health-add-input, Schedule the watch and define an input>> that gets the
|
|
cluster health status.
|
|
|
|
* <<health-add-condition, Add a condition>> that evaluates the health status to
|
|
determine if action is required.
|
|
|
|
* <<health-take-action, Take action>> if the cluster is RED.
|
|
|
|
[float]
|
|
[[health-add-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.
|
|
|
|
The simplest way to define a schedule is to specify an interval. For example,
|
|
the following schedule runs every 10 seconds:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT _xpack/watcher/watch/cluster_health_watch
|
|
{
|
|
"trigger" : {
|
|
"schedule" : { "interval" : "10s" } <1>
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
<1> 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 <<health-delete, delete the watch>>
|
|
when you're done experimenting.
|
|
|
|
To get the status of your cluster, you can call the Elasticsearch
|
|
{ref}//cluster-health.html[cluster health] API:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET _cluster/health?pretty
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[continued]
|
|
|
|
To load the health status into your watch, you simply add an
|
|
<<input-http, HTTP input>> that calls the cluster health API:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT _xpack/watcher/watch/cluster_health_watch
|
|
{
|
|
"trigger" : {
|
|
"schedule" : { "interval" : "10s" }
|
|
},
|
|
"input" : {
|
|
"http" : {
|
|
"request" : {
|
|
"host" : "localhost",
|
|
"port" : 9200,
|
|
"path" : "/_cluster/health"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
If you're using Security, then you'll also need to supply some authentication credentials as part of the watch configuration:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
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"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
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].
|
|
|
|
|
|
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:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET .watcher-history*/_search
|
|
{
|
|
"sort" : [
|
|
{ "result.execution_time" : "desc" }
|
|
]
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[continued]
|
|
|
|
[float]
|
|
[[health-add-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
|
|
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.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT _xpack/watcher/watch/cluster_health_watch
|
|
{
|
|
"trigger" : {
|
|
"schedule" : { "interval" : "10s" } <1>
|
|
},
|
|
"input" : {
|
|
"http" : {
|
|
"request" : {
|
|
"host" : "localhost",
|
|
"port" : 9200,
|
|
"path" : "/_cluster/health"
|
|
}
|
|
}
|
|
},
|
|
"condition" : {
|
|
"compare" : {
|
|
"ctx.payload.status" : { "eq" : "red" }
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
<1> 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.
|
|
|
|
[source,js]
|
|
------------------------------------------------------
|
|
GET .watcher-history*/_search?pretty
|
|
{
|
|
"query" : {
|
|
"match" : { "result.condition.met" : true }
|
|
}
|
|
}
|
|
------------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[continued]
|
|
|
|
[float]
|
|
[[health-take-action]]
|
|
==== Take Action
|
|
|
|
Recording `watch_records` in the watch history is nice, but the real power of
|
|
{watcher} is being able to do something in response to an alert. A watch's
|
|
<<actions, actions>> define what to do when the watch condition is true--you
|
|
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.
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
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"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
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`:
|
|
|
|
[source,yaml]
|
|
----------------------------------------------------------
|
|
xpack.notification.email.account:
|
|
work:
|
|
profile: gmail
|
|
email_defaults:
|
|
from: <email> <1>
|
|
smtp:
|
|
auth: true
|
|
starttls.enable: true
|
|
host: smtp.gmail.com
|
|
port: 587
|
|
user: <username> <2>
|
|
password: <password> <3>
|
|
----------------------------------------------------------
|
|
<1> Replace `<email>` with the email address from which you want to send
|
|
notifications.
|
|
<2> Replace `<username>` with your Gmail user name (typically your Gmail address).
|
|
<3> Replace `<password>` with your Gmail password.
|
|
|
|
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>>.
|
|
|
|
You can check the watch history or the `status_index` to see that the action was
|
|
performed.
|
|
|
|
[source,js]
|
|
-------------------------------------------------------
|
|
GET .watcher-history*/_search?pretty
|
|
{
|
|
"query" : {
|
|
"match" : { "result.condition.met" : true }
|
|
}
|
|
}
|
|
-------------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[continued]
|
|
|
|
[float]
|
|
[[health-delete]]
|
|
==== 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]:
|
|
|
|
[source,js]
|
|
-------------------------------------------------------
|
|
DELETE _xpack/watcher/watch/cluster_health_watch
|
|
-------------------------------------------------------
|
|
// CONSOLE
|
|
// TEST[continued]
|