Auditer la taille et le nombre de shards (détection d'oversharding / de shards surdimensionnés)
ElasticsearchMaintenanceCommande
# 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_nodeCe que fait la commande
Liste les plus gros shards, la taille des primaires des index, le nombre de shards par nœud, le nombre total de shards et la limite cluster.max_shards_per_node.
Quand l'utiliser
Lors de la planification de capacité, quand les durées de recovery s'allongent ou que la pression sur le heap augmente, et sur l'erreur 'this action would add [x] shards, but this cluster currently has [y]/[z] maximum normal shards open'.
Attention
De nombreux très petits shards (oversharding) sollicitent le master et le heap ; de très gros shards étirent la recovery et le rééquilibrage sur des heures. Le nombre de shards primaires ne peut pas changer après la création de l'index ; shrink, split ou reindex est nécessaire pour le corriger. Relever max_shards_per_node supprime la limite mais ne résout pas le problème.