Curator issue - No actionable item


(xt) #1

Hi All,

I am running ES 5.x.x and I am having the following action file

actions:
1:
action: snapshot
description: >-
Snapshot logstash- prefixed indices older than 100 day (based on index
creation_date) with the default snapshot name pattern of
'curator-%Y%m%d%H%M%S'. Wait for the snapshot to complete. Do not skip
the repository filesystem access check. Use the other options to create
the snapshot.
options:
repository: databackuptest1
name:
ignore_unavailable: False
include_global_state: True
partial: False
wait_for_completion: True
skip_repo_fs_check: False
disable_action: false
filters:
- filtertype: pattern
kind: prefix
value: logstash-test-
- filtertype: age
source: creation_date
direction: older
timestring: '%Y-%m-%d'
unit: days
unit_count: 100

When I run

./curator --config curator.yml action.yaml

I see curator going over the indices and everything looks 'okish' however at the end it quits with..

Unable to complete action "snapshot". No actionable items in list: <class 'curator.exceptions.NoIndices'>

Snippet from the DEBUG below:

2017-08-11 13:51:10,727 DEBUG curator.indexlist filter_by_regex:384 Filter by regex: Index: logstash-test-2017.04.05
2017-08-11 13:51:10,727 DEBUG curator.indexlist __actionable:35 Index logstash-test-2017.04.05 is actionable and remains in the list.
2017-08-11 13:51:10,727 DEBUG curator.indexlist filter_by_regex:384 Filter by regex: Index: logstash-test-2017.01.24
2017-08-11 13:51:10,727 DEBUG curator.indexlist __actionable:35 Index logstash-test-2017.01.24 is actionable and remains in the list.
2017-08-11 13:51:10,727 DEBUG curator.indexlist filter_by_regex:384 Filter by regex: Index: logstash-number1-2017.06.07
2017-08-11 13:51:10,727 DEBUG curator.indexlist __not_actionable:39 Index logstash-number1-2017.06.07 is not actionable, removing from list.
2017-08-11 13:51:10,727 DEBUG curator.indexlist filter_by_regex:384 Filter by regex: Index: logstash-number1-2017.01.07
2017-08-11 13:51:10,727 DEBUG curator.indexlist __not_actionable:39 Index logstash-number1-2017.01.07 is not actionable, removing from list.

My goal is to backup my indices and then delete them. Any help would be much appreciated!


(Aaron Mildenstein) #2

You're only providing the debug snippet from the pattern filter output. Clearly there are actionable indices there.

If I had to guess, though, I'd say that what's happening is that you have indices with index name dates over 100 days in the past, but they were created less than 100 days ago, so the creation_date condition is not being met, which results in the NoIndices exception.

Since you already have a timestring in there, change source: creation_date to source: name and see if you get the same output.


(xt) #3

Thanks for your answer @theuntergeek I tried that and didnt change anything - exactly the same result.

Also to your point it shouldnt be the case - there should be indices there of more than 100 days but werent re-indexed or something like that. THese were always there...


(Aaron Mildenstein) #4

To know any more, then, I'll need the full debug log. You probably can't attach it here, so you should put it here as a link to a zip file or something.


(Aaron Mildenstein) #5

Even a gist of the last few hundred lines before it exits will be helpful.


(xt) #6

It turned out to be a repository issue - I had to create it. However now I am getting the following error message...

2017-08-12 12:53:34,269 ERROR curator.cli cli:193 Failed to complete action: snapshot. <class 'curator.exceptions.ActionError'>: Failed to verify all nodes have repository access: --- Got a 500 response from Elasticsearch. Error message: repository_verification_exception


(Aaron Mildenstein) #7

That error suggests that not all of your data and master nodes can both read and write to the shared filesystem. For a repository to work, each master and data node has to be able to read and write to that shared filesystem. For an NFS mount (fs type repository), that requires that each master and data node have that filesystem mounted in the exact same path, with read/write permissions, and also that path.repo has been added to the elasticsearch.yml file with that path.


(xt) #8

Thanks that was indeed the case :slight_smile: All sorted now!


(system) #9

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