Unbalanced shard counts
Shard counts across data nodes are skewed enough that some nodes carry far fewer shards than peers in the same tier. Uneven placement wastes capacity on light nodes and can overload heavier ones for indexing and search.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Node |
| Domains | performance, shard-allocation |
You can customize these settings to adjust when AutoOps detects this event and presents the insight. Refer to AutoOps event settings for details.
The default customization settings are:
| Setting | Type | Default |
|---|---|---|
| Unbalanced shard percent above the average | Percentage | 50 |
The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.
Affected data tier: hot, warm.
Average number of shards per node: 12
Nodes with the lowest number of shards: - es-data-03: 8
Nodes with the highest number of shards: - es-data-01: 42
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Enable shard rebalance
Condition: Always shown for this insight.
Reset cluster.routing.rebalance.enable so primary and replica shards can rebalance across nodes.
PUT _cluster/settings
{
"transient": {
"cluster.routing.rebalance.enable": null
},
"persistent": {
"cluster.routing.rebalance.enable": null
}
}
Requires the manage cluster privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
Elasticsearch normally spreads shards across active data nodes in a tier through allocation (placing unassigned shards) and rebalancing (moving shards between nodes).
When those processes cannot even out placement, some nodes sit underused while others hold most of the work. Common blockers include turned off rebalancing, allocation filters or awareness settings, disk watermarks, and node attributes that limit where shards can live.
Uneven shard counts often show up as uneven CPU, heap, and disk pressure, which slows indexing and search on the busier nodes.