conductor-oss/conductor

es7-persistance creates unlimited amount of indices

astelmashenko opened this issue · 1 comments

Describe the bug
After certain amount of time shards problem raised. We checked ES and found out around 2300 shards, names like conductor_task_log_20221004.

Investigating code I see

// class ElasticSearchRestDAOV7
    private void createIndexesTemplates() {
        try {
            initIndexesTemplates();
            updateIndexesNames();
            Executors.newScheduledThreadPool(1).scheduleAtFixedRate(this::updateIndexesNames, 0, 1, TimeUnit.HOURS);
        } catch (Exception e) {
            logger.error("Error creating index templates!", e);
        }
    }
//...
    private void updateIndexesNames() {
        logIndexName = updateIndexName(LOG_DOC_TYPE);
        eventIndexName = updateIndexName(EVENT_DOC_TYPE);
        messageIndexName = updateIndexName(MSG_DOC_TYPE);
    }

    private String updateIndexName(String type) {
        String indexName =
                this.indexPrefix + "_" + type + "_" + SIMPLE_DATE_FORMAT.format(new Date());
        try {
            addIndex(indexName);
            return indexName;
        } catch (IOException e) {
            logger.error("Failed to update log index name: {}", indexName, e);
            throw new NonTransientException(e.getMessage(), e);
        }
    }

Where updateIndexesNames creates new index every week.
Can someone explain why does it change names for indices?

*_conductor_task_log*
*_conductor_message*
*_conductor_event*

I'd like to change this behavior, because we reaching limits on shards.

I also checked below methods are not used anywhere:

IndexDAO.getEventExecutions
IndexDAO.getMessages

so it is probably safe to stop indexing them:

conductor.app.eventMessageIndexingEnabled=false
conductor.app.eventExecutionIndexingEnabled=false

However to stop creating new indices we need to change this config:

conductor.elasticsearch.autoIndexManagementEnabled=false

And provision indices for conductor manually.

Details
Conductor version: 3.18.0+
Persistence implementation: Postgres
Queue implementation: Postgres
Lock: Redis

To Reproduce
Steps to reproduce the behavior:
Just use elastic for a while

Expected behavior
Data is cleaned up periodically.

I'm also studying house keeping mechanism now
I think it's a good idea to have elasticsearch ILM set on index patterns, though it's not implemented yet in conductor so you have to manually configure it on elasticsearch