An agency running daily indices for several years had accumulated tens of thousands of small shards. Adding hardware had stopped helping, and master elections were taking long enough to interrupt indexing. AceMQ assessed the cluster to determine whether the problem was capacity or design.
Every daily index carried the default shard count regardless of whether it held a few megabytes or hundreds of gigabytes. The resulting cluster state was large enough that publishing an update to all nodes took seconds, pending tasks backed up behind it, and any master failover turned into a multi-minute outage. Nobody could safely change the index template because it was unclear which downstream searches depended on the existing index naming.
On-premises Elasticsearch cluster, daily time-based indices with multi-year retention, mixed log and document search workloads.
The assessment inventories shard count and size distribution per index pattern, measures cluster-state size and publication latency, and maps which indices actually receive queries. We separate indices that need to be reshaped from ones that simply need to be rolled up or deleted, and deliver a sequenced plan the customer can execute during normal maintenance.
Shard count fell dramatically once daily indices were consolidated and old data was rolled up, cutting cluster-state publication time to a fraction of what it was. Master failover became a non-event, and the planned hardware expansion was deferred.
Consulting engagement to design index lifecycle management, data tiering, and snapshot policy for a regulated Elasticsearch estate.
Emergency remediation of an Elasticsearch cluster that would not return to green after a data node failure, with replicas blocked by disk watermarks.
Whether you need architecture advisory, 24/7 support, or full managed services, AceMQ has the expertise to help.