I'm using curator to manage my indices currently. I'm suffering from cron spam due to the following:
/usr/local/lib/curator/venv/lib64/python3.8/site-packages/elasticsearch/connection/base.py:200: ElasticsearchWarning: this request accesses system indices: [.apm-agent-configuration, .apm-custom-link, .async-search, .kibana_1, .kibana_2, .kibana_3, .kibana_4, .kibana_5, .kibana_6, .kibana_7, .kibana_task_manager_1, .kibana_task_manager_2, .kibana_task_manager_3, .kibana_task_manager_4, .kibana_task_manager_5, .reporting-2018.08.26, .security-7, .tasks], but in a future major version, direct access to system indices will be prevented by default
warnings.warn(message, category=ElasticsearchWarning)
I'm not interesting in using curator to manage any system indices, and I would like to tell it not to, so as to avoid the above message.
Note that this message is sent to stdout/stderr, whereas I have curator configured to log to file.
curator, version 5.8.4
Python 3.8.6
From pip:
elasticsearch 7.12.1
elasticsearch-curator 5.8.4
I think this is happening as curator lists initial set of indices to then later filter. My actions.yml are all prefix-based, although do allow_ilm_indices.
This warning is generated by Elasticsearch itself (communicated via the 'Warnings' response header), and emitted using the Python 'warnings' module as used by the 'elasicsearch' Python module. Curator doesn't seem to be doing anything with the 'warnings' module, such as using the 'catch_warnings' context manager.
The code that is likely generating this is in get_indices which uses _all
Guess I'll just use the PYTHONWARNINGS=ignore environment variable in the cron file for now.
Cheers,
Cameron