Elasticsearch
Grappe
Recherche…
Remarques
L'intégrité du cluster fournit de nombreuses informations sur le cluster, telles que le nombre de fragments alloués ("actifs") ainsi que le nombre de partitions non attribuées et déplacées. De plus, il fournit le nombre actuel de noeuds et de noeuds de données dans le cluster, ce qui peut vous permettre de rechercher des noeuds manquants (par exemple, si vous prévoyez qu'il y en a 15 , mais qu'il n'en affiche que 14 , il vous manque un noeud) .
Pour ceux qui connaissent Elasticsearch, les fragments "assignés" et "non attribués" peuvent les aider à détecter des problèmes.
Le champ le plus fréquemment vérifié à partir de Cluster Health est le status , qui peut être l'un des trois états suivants:
- rouge
- jaune
- vert
Les couleurs signifient chacune une et une seule chose très simple:
- Le rouge indique qu'il vous manque au moins un fragment primaire.
- Un fragment primaire manquant signifie qu'un index ne peut pas être utilisé pour écrire (indexer) de nouvelles données dans la plupart des cas.
- Techniquement, vous pouvez toujours indexer tous les fragments primaires disponibles dans cet index, mais en pratique, cela signifie que vous ne pouvez pas le faire car vous ne contrôlez généralement pas quel fragment reçoit un document donné.
- La recherche est toujours possible sur un cluster rouge, mais cela signifie que vous obtiendrez des résultats partiels si des index sont manquants dans les index.
- Dans des circonstances normales, cela signifie simplement que le fragment primaire est alloué (
initializing_shards). - Si un nœud vient de quitter le cluster (par exemple, parce que la machine qui l'exécute a perdu de la puissance), il est logique que vous manquiez temporairement certains fragments primaires.
- Tout fragment de réplique pour ce fragment primaire sera promu comme fragment primaire dans ce scénario.
- Un fragment primaire manquant signifie qu'un index ne peut pas être utilisé pour écrire (indexer) de nouvelles données dans la plupart des cas.
- Jaune indique que tous les fragments primaires sont actifs, mais qu'au moins un fragment de réplique est manquant.
- Une réplique manquante n'affecte que l'indexation si les paramètres de cohérence nécessitent une incidence sur l'indexation.
- Par défaut, il n'y a qu'une seule réplique pour un serveur principal et l'indexation peut se produire avec un seul réplica manquant.
- Dans des circonstances normales, cela signifie simplement que le fragment de réplique est alloué (
initializing_shards). - Un cluster à un seul nœud avec les répliques activées sera toujours jaune au mieux . Il peut être rouge si un fragment primaire n’a pas encore été attribué.
- Si vous ne disposez que d'un seul nœud, désactivez les réplicas car vous n'en attendez aucun. Ensuite, il peut être vert.
- Une réplique manquante n'affecte que l'indexation si les paramètres de cohérence nécessitent une incidence sur l'indexation.
- Le vert indique que tous les fragments sont actifs.
- La seule activité de fragment autorisée pour un cluster vert est la
relocating_shards. - Les nouveaux index, et par conséquent les nouveaux fragments, feront passer le cluster du rouge au jaune et au vert, au fur et à mesure que chaque partition est allouée (primaire en premier, le rendant jaune, puis répliques si possible, le rendant vert).
- Dans Elasticsearch 5.x et les versions ultérieures, les nouveaux index ne rendront pas votre cluster rouge à moins qu’il ne soit trop long à allouer.
- La seule activité de fragment autorisée pour un cluster vert est la
Cluster Health sous forme de tableau, lisible par l'homme, avec en-têtes
L'exemple utilise la syntaxe HTTP de base. Tout <#> dans l'exemple doit être supprimé lors de sa copie.
Vous pouvez utiliser les API _cat pour obtenir une sortie tabulaire lisible par l'homme pour diverses raisons.
GET /_cat/health?v <1>
- Le
?vest facultatif, mais cela implique que vous voulez une sortie "verbeuse".
_cat/health existe depuis Elasticsearch 1.x, mais voici un exemple de sortie d'Elasticsearch 5.x:
Avec sortie verbeuse:
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1469302011 15:26:51 elasticsearch yellow 1 1 45 45 0 0 44 0 - 50.6%
Cluster Health, sous forme de tableau, lisible par l'homme, sans en-têtes
L'exemple utilise la syntaxe HTTP de base. Tout <#> dans l'exemple doit être supprimé lors de sa copie.
Vous pouvez utiliser les API _cat pour obtenir une sortie tabulaire lisible par l'homme pour diverses raisons.
GET /_cat/health <1>
_cat/health existe depuis Elasticsearch 1.x, mais voici un exemple de sortie d'Elasticsearch 5.x:
Sans sortie verbeuse:
1469302245 15:30:45 elasticsearch yellow 1 1 45 45 0 0 44 0 - 50.6%
Cluster Health sous forme de tableau, lisible par l'homme, avec en-têtes sélectionnés
L'exemple utilise la syntaxe HTTP de base. Tout <#> dans l'exemple doit être supprimé lors de sa copie.
Comme la plupart des API _cat dans Elasticsearch, l'API répond de manière sélective par un ensemble de champs par défaut. Cependant, d'autres champs existent de l'API si vous le souhaitez:
GET /_cat/health?help <1>
-
?helppermet à l'API de renvoyer les champs (et noms abrégés) ainsi qu'une brève description.
_cat/health existe depuis Elasticsearch 1.x, mais voici un exemple de sortie d'Elasticsearch 5.x:
Champs disponibles à la date de création de cet exemple:
epoch | t,time | seconds since 1970-01-01 00:00:00
timestamp | ts,hms,hhmmss | time in HH:MM:SS
cluster | cl | cluster name
status | st | health status
node.total | nt,nodeTotal | total number of nodes
node.data | nd,nodeData | number of nodes that can store data
shards | t,sh,shards.total,shardsTotal | total number of shards
pri | p,shards.primary,shardsPrimary | number of primary shards
relo | r,shards.relocating,shardsRelocating | number of relocating nodes
init | i,shards.initializing,shardsInitializing | number of initializing nodes
unassign | u,shards.unassigned,shardsUnassigned | number of unassigned shards
pending_tasks | pt,pendingTasks | number of pending tasks
max_task_wait_time | mtwt,maxTaskWaitTime | wait time of longest task pending
active_shards_percent | asp,activeShardsPercent | active number of shards in percent
Vous pouvez ensuite l'utiliser pour imprimer uniquement ces champs:
GET /_cat/health?h=timestamp,cl,status&v <1>
-
h=...définit la liste des champs à renvoyer. -
v(verbose) définit que vous souhaitez imprimer les en-têtes.
La sortie d'une instance d'Elasticsearch 5.x:
timestamp cl status
15:38:00 elasticsearch yellow
Santé des clusters basée sur JSON
L'exemple utilise la syntaxe HTTP de base. Tout <#> dans l'exemple doit être supprimé lors de sa copie.
Les API _cat sont souvent pratiques pour les humains pour obtenir des informations détaillées sur le cluster. Cependant, vous souhaitez souvent utiliser des résultats systématiquement analysables avec les logiciels. En général, les API JSON sont conçues à cet effet.
GET /_cluster/health
_cluster/health existe depuis Elasticsearch 1.x, mais voici un exemple de sortie d'Elasticsearch 5.x:
{
"cluster_name": "elasticsearch",
"status": "yellow",
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 45,
"active_shards": 45,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 44,
"delayed_unassigned_shards": 0,
"number_of_pending_tasks": 0,
"number_of_in_flight_fetch": 0,
"task_max_waiting_in_queue_millis": 0,
"active_shards_percent_as_number": 50.56179775280899
}