List/backup/restore watchers

Elastic Stack Elasticsearch
1

I created several Watches via Kibana and after looking over at Watcher APIs | Elasticsearch Reference [6.2] | Elastic

I have following questions:

  1. Is there a way to get list all watchers?
  2. Is there a way to GET watcher (for backup purpose)?
  3. Is there a way to PUT watcher (restore from backup)?
2

Sorry for the delay in response.

  1. do a search against the .watches index
  2. https://www.elastic.co/guide/en/elasticsearch/reference/current/watcher-api-get-watch.html
  3. https://www.elastic.co/guide/en/elasticsearch/reference/current/watcher-api-put-watch.html
3

as the watches are just stored in an index. you can treat them as such.

You can run a snapshot operation against this index as well as a restore operation. You should however ensure that watcher is stopped when restoring and make sure the index does not exist, as the restore would fail otherwise. If you use monitoring, you might also disable monitoring for that time as it tries to store watches in the .watches index.

Hope that helps.

--Alex

4

@spinscale How do I stop Watcher/Monitoring?

5

Is there a way to stop or disable default watchers ?
The GUI doesn't allow to do this.

6

you can disable monitoring in the YAML configuration xpack.monitoring.enabled: false

After disabling you could either just delete these watches or deactivate them

7

@spinscale

I assume xpack.monitoring.enabled is part of elasticsearch.yml and therefor has to be propagated to all nodes in cluster, and after restore of .watches index, I'd toggle it back followed by another restart of all nodes, correct?

8

@alexus I think my previous tip was wrong. It should be sufficient to stop watcher via the stop watch API and that's it.

9

Per your latest suggestion, I tried to use Stop API | Elasticsearch Reference [6.2] | Elastic followed by restoring .watches index from snapshot, yet gotten error:

# curl --silent --request POST --header 'Content-Type: application/json' "$ELASTICSEARCH_URI/_snapshot/repository-gcs/2018-04-10-all/_restore?wait_for_completion=true&pretty" --data '{"indices": ".watches"}'
{
  "error" : {
    "root_cause" : [
      {
        "type" : "snapshot_restore_exception",
        "reason" : "[repository-gcs:2018-04-10-all/KD9EAEDDT-a-NXvpefpYHQ] cannot restore index [.watches] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name"
      }
    ],
    "type" : "snapshot_restore_exception",
    "reason" : "[repository-gcs:2018-04-10-all/KD9EAEDDT-a-NXvpefpYHQ] cannot restore index [.watches] because an open index with same name already exists in the cluster. Either close or delete the existing index or restore the index under a different name by providing a rename pattern and replacement name"
  },
  "status" : 500
}
#
10

I should not write messages at 11pm. What I meant is no need to fiddle with the monitoring configuration.

A restore operation still requires you to delete the existing index.

11

11pm is "almost" the most productive time of the day)

# curl --silent --request DELETE $ELASTICSEARCH_URI/.watches?pretty
{
  "error" : "This endpoint is not supported for DELETE on .watches index.",
  "status" : 400
}
#
12

you can do a workaround here and specify .watche*, which will delete the watches index (but also all others matching that wildcard).

--Alex

13

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.