Curator not can find indecies

Elastic Stack Elasticsearch
1

I have an issue with deleting indexes!
this is my Action file:

actions:
  1:
    action: delete_indices
    description: >-
      Delete indices. Find which to delete by first limiting the list to
      logstash- prefixed indices. Then further filter those to prevent deletion
      of anything less than the number of days specified by unit_count.
      Ignore the error if the filter does not result in an actionable list of
      indices (ignore_empty_list) and exit cleanly.
    options:
      ignore_empty_list: True
      allow_ilm_indices: False
      disable_action: False
    filters:
    - filtertype: pattern
      kind: regex
      value: ^\..+
      exclude: true
    - filtertype: age
      source: creation_date
      direction: older
      unit: days
      unit_count: 3
    - filtertype: pattern
      kind: prefix
      value: stage

It was working fine, now all I get back is :
curator --dry-run --config ./curator.yml ./stage_30_days.yml

/home/administrator/.local/lib/python3.8/site-packages/curator/helpers/getters.py:149: ElasticsearchWarning: this request accesses system indices: [.apm-agent-configuration, .apm-custom-link, .async-search, .kibana_7.12.0_001, .kibana_7.17.2_001, .kibana_task_manager_7.12.0_001, .kibana_task_manager_7.17.2_001, .reporting-2021-10-17, .reporting-2021-10-31, .reporting-2021-11-07, .reporting-2021-11-14, .reporting-2021-11-21, .reporting-2021-11-28, .reporting-2021-12-05, .reporting-2021-12-12, .reporting-2021-12-19, .reporting-2021-12-26, .reporting-2022-01-02, .reporting-2022-01-09, .reporting-2022-01-16, .reporting-2022-01-23, .reporting-2022-03-06, .reporting-2022-03-13, .security-7, .tasks, .transform-internal-006, .transform-internal-007], but in a future major version, direct access to system indices will be prevented by default
  indices = list(client.indices.get_settings(index='*', expand_wildcards='open,closed'))```
2

This is my config file:

elasticsearch:
  client:
    hosts:
      - http://127.0.0.1:9200
    cloud_id:
    ca_certs:
    client_cert:
    client_key:
    verify_certs:
    request_timeout: 30
  other_settings:
    master_only: False
    username: xxx
    password: xxx
    api_key:
      id:
      api_key:
logging:
  loglevel: INFO
  logfile: '/home/administrator/curator.log'
  logformat: default
  blacklist: ['elastic_transport', 'urllib3']
3

I checked if it had to do with ILM and I get the same response.
Even when I set the Action file to delete any index which is a day old it comes back with nothing.

When I slim down the action file:

actions:
  1:
    action: delete_indices
    description: >-
      Delete indices. Find which to delete by first limiting the list to
      logstash- prefixed indices. Then further filter those to prevent deletion
      of anything less than the number of days specified by unit_count.
      Ignore the error if the filter does not result in an actionable list of
      indices (ignore_empty_list) and exit cleanly.
    options:
      ignore_empty_list: True
      disable_action: False
    filters:
    - filtertype: age
      source: creation_date
      direction: older
      unit: days
      unit_count: 1

I get this response:

  indices = list(client.indices.get_settings(index='*', expand_wildcards='open,closed'))
/home/administrator/.local/lib/python3.8/site-packages/curator/indexlist.py:985: ElasticsearchWarning: this request accesses system indices: [.apm-agent-configuration, .apm-custom-link, .async-search, .kibana_7.17.2_001, .kibana_task_manager_7.12.0_001, .kibana_task_manager_7.17.2_001, .reporting-2021-10-17, .reporting-2021-10-31, .reporting-2021-11-07, .reporting-2021-11-14, .reporting-2021-11-21, .reporting-2021-11-28, .reporting-2021-12-12, .reporting-2021-12-19, .reporting-2021-12-26, .reporting-2022-01-02, .reporting-2022-01-16, .reporting-2022-01-23, .reporting-2022-03-06, .security-7, .tasks, .transform-internal-007], but in a future major version, direct access to system indices will be prevented by default
  working_list = self.client.indices.get_settings(index=to_csv(lst))
/home/administrator/.local/lib/python3.8/site-packages/curator/indexlist.py:985: ElasticsearchWarning: this request accesses system indices: [.kibana_7.12.0_001, .reporting-2021-12-05, .reporting-2022-01-09, .reporting-2022-03-13, .transform-internal-006], but in a future major version, direct access to system indices will be prevented by default
  working_list = self.client.indices.get_settings(index=to_csv(lst))```
4

So, did you recently upgrade Elasticsearch? The warning message (and it is labeled ElasticsearchWarning) is a deprecation message, and not actually indicating the indices specified will be deleted. It was recently added. Even though your filter block excludes indices starting with a ., there is a hidden process internal to Curator which still gets all indices before it applies the filters you provide. From what I can tell, the message you are seeing is merely warning that direct access to system indices (i.e., those starting with a .) will be disallowed. That message itself will not prevent index access to the other indices.

There may be another log message somewhere that indicates why deletion is not happening. The one you shared is not the one that is preventing index deletion, but merely a deprecation warning, as indicated.

5

Thank you for your replay,
I understand now its just a deprecation message.
I get no response from curator, no log other then what I added.
I tired to make the credential fail and got Unable to establish client connection to Elasticsearch!
I tried to go to the bear minimum to get a response:

actions:
  1:
    action: delete_indices
    description: >-
      Delete indices. Find which to delete by first limiting the list to
      logstash- prefixed indices. Then further filter those to prevent deletion
      of anything less than the number of days specified by unit_count.
      Ignore the error if the filter does not result in an actionable list of
      indices (ignore_empty_list) and exit cleanly.
    filters:
    - filtertype: age
      source: creation_date
      direction: older
      unit: days
      unit_count: 1
~                                      ```
6

Please enable DEBUG level logging. It will show much more detail.

7

Thank you,
Sorry for the trouble,
I found the problem:
a log path was configured and only deprecation messages where printed to console. That is what throw me off. I would except all logs to go to log path, or it would be nice in future version that console prints log path.
Second, Action files moved to a different path....my bad
Thanks for the help !

8

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