Le server ElasticSearch s'arrête randomment en mode travail

J'ai 2 servers ES qui sont alimentés par 1 server logstash et visualisation des journaux dans Kibana. Il s'agit d'un POC pour résoudre les problèmes avant d'entrer en production. Le système a fonctionné pour ~ 1 mois et tous les quelques jours, Kibana cessera de montrer des journaux à un moment random au milieu de la nuit. La nuit dernière, la dernière input de journal que j'ai reçue à Kibana était vers 18h30. Lorsque j'ai vérifié les servers ES, il a montré que le fonctionnement du maître et le secondaire ne fonctionnaient pas (du statut de search élastique / sbin / service), mais j'ai pu faire une boucle sur l'hôte local et il a renvoyé des informations. Je ne suis donc pas sûr de savoir quoi de neuf. Quoi qu'il en soit, quand je fais un statut sur le nœud maître, je comprends ceci:

curl -XGET 'http://localhost:9200/_cluster/health?pretty=true' { "cluster_name" : "gis-elasticsearch", "status" : "red", "timed_out" : false, "number_of_nodes" : 6, "number_of_data_nodes" : 2, "active_primary_shards" : 186, "active_shards" : 194, "relocating_shards" : 0, "initializing_shards" : 7, "unassigned_shards" : 249 } 

Lorsque je visualise les index, via "ls … nodes / 0 / indeces /", tous les index sont modifiés aujourd'hui pour une raison quelconque et il existe un nouveau file pour la date d'aujourd'hui. Donc, je pense que je commence à me rétablir après J'ai redémarré les deux servers mais je ne sais pas pourquoi il a échoué en premier lieu. Quand je regarde les journaux sur le maître, je vois seulement 4 erreurs d'avertissement à 18:57 et ensuite le 2ème départ du cluster. Je ne vois aucun journal sur le secondaire (pistolet) sur pourquoi il a cessé de fonctionner ou ce qui s'est réellement passé.

 [2014-03-06 18:57:04,121][WARN ][transport ] [ElasticSearch Server1] Transport response handler not found of id [64147630] [2014-03-06 18:57:04,124][WARN ][transport ] [ElasticSearch Server1] Transport response handler not found of id [64147717] [2014-03-06 18:57:04,124][WARN ][transport ] [ElasticSearch Server1] Transport response handler not found of id [64147718] [2014-03-06 18:57:04,124][WARN ][transport ] [ElasticSearch Server1] Transport response handler not found of id [64147721] 

[2014-03-06 19: 56: 08,467] [INFO] [cluster.service] [ElasticSearch Server1] supprimé {[Pistolet] [sIAMHNj6TMCmrMJGW7u97A] [inet [/10.1.1.10:9301]] {client = true, data = false},}, raison: zen-disco-node_failed ([Pistolet] [sIAMHNj6TMCmrMJGW7u97A] [inet [/10.13.3.46:9301]] {client = true, data = false}), motif échoué au ping, essayé [3] les time, chacun avec le maximum [30s] timeout [2014-03-06 19: 56: 12,304] [INFO] [cluster.service] [ElasticSearch Server1] a ajouté {[Pistol] [sIAMHNj6TMCmrMJGW7u97A] [inet [/10.1.1.10:9301 ]] {client = true, data = false},}, raison: zen-disco-receive (join du nœud [[Pistol] [sIAMHNj6TMCmrMJGW7u97A] [inet [/10.13.3.46:9301]] {client = true, data = faux}])

Une idée de l'logging ou du dépannage supplémentaire que je peux activer pour éviter que cela ne se produise à l'avenir? Étant donné que les fragments ne sont pas pris en charge, en ce moment, je viens de voir beaucoup de messages de debugging sur l'échec de l'parsing. Je suppose que cela sera corrigé une fois que nous nous mettrons au courant.

[2014-03-07 10: 06: 52,235] [DEBUG] [action.search.type] [ElasticSearch Server1] Tous les fragments ont échoué pour la phase: [query] [2014-03-07 10: 06: 52,223] [DEBUG] [action.search.type] [ElasticSearch Server1] [windows-2014.03.07] [3], node [W6aEFbimR5G712ddG_G5yQ], [P], s [STARTED]: Impossible d'exécuter [org.elasticsearch.action.search.SearchRequest @ 74ecbbc6] lastShard [true] org.elasticsearch.search.SearchParseException: [windows-2014.03.07] [3]: à partir de [-1], taille [-1]: Parse Failure [Impossible d'parsingr la source [{"facets": {"0": {"date_histogram": {"champ": "@ timestamp", "interval": "10m"}, "global": true, "facet_filter": {"fquery": {"query": { "filtré": {"query": {"query_ssortingng": {"query": "(ASA AND Deny)"}}, "filter": {"bool": {"must": [{"range": { "@timestamp": {"from": 1394118412373, "to": "now"}}}]}}}}}}}}}}}, "taille": 0}]]

Les suspects habituels pour ES avec Kibana sont:

  • * Trop peu de memory disponible pour ES ** (que vous pouvez searchr avec n'importe quel système de sonde tel que Marvel, ou quelque chose qui vous enverra des données JVM en dehors de VM pour la surveillance)
  • Longue durée de GC (activer la journalisation GC et voir si elles ne se produisent pas lorsque l'ES cesse de répondre)

De plus, la configuration "habituelle" pour ES est de 3 servers pour permettre une meilleure redondance lorsqu'un server est en panne. Mais YMMV.

Vous pouvez également essayer le nouveau collecteur de déchets G1 , ce qui a (dans mon cas) un comportement beaucoup mieux que le CMS dans mon Kibana ES.

Le problème de durée du GC est habituellement celui qui se produit lorsque vous searchz un autre endroit et entraînera généralement une perte de données car ES cesse de répondre.

Bonne chance avec ces 🙂