Audit shard sizes and shard count (oversharding / oversized shard detection)

Command

# Largest shards (GB):
GET _cat/shards?v&h=index,shard,prirep,state,docs,store,node&s=store:desc&bytes=gb
# Indices by primary size:
GET _cat/indices?v&h=index,pri,rep,docs.count,pri.store.size,store.size&s=pri.store.size:desc&bytes=gb
# Shard count and disk per node:
GET _cat/allocation?v&h=node,shards,disk.indices,disk.percent&s=shards:desc
GET _cluster/stats?filter_path=indices.shards.total,indices.shards.primaries,nodes.count.data
GET _cluster/settings?include_defaults=true&filter_path=*.cluster.max_shards_per_node

What it does

Lists the largest shards, primary sizes of indices, shard count per node, total shard count and the cluster.max_shards_per_node limit.

When to use it

During capacity planning, when recovery times grow or heap pressure rises, and on the error 'this action would add [x] shards, but this cluster currently has [y]/[z] maximum normal shards open'.

Caution

Many very small shards (oversharding) strain the master and heap; very large shards stretch recovery and rebalancing to hours. The primary shard count cannot change after index creation; shrink, split or reindex is needed to fix it. Raising max_shards_per_node removes the limit but does not solve the problem.