Elasticsearch meurt lorsque Logstash tente d'écrire des données


9

J'ai une configuration Raspberry Pi 2 (dernière Raspbian en avril 2015) qui exécutait la semaine dernière ElasticSearch et Logstash sur un réseau de test (pas une configuration simple, mais elle était stable pendant plus d'une semaine!). J'ai redémarré ma machine aujourd'hui et j'ai eu beaucoup de mal à remettre les choses en marche; ES et LS fonctionneront tous deux indépendamment, mais lorsque j'essaie de pousser la sortie LS dans ES, l'instance ES meurt sans explication. Mon objectif est d'obtenir à la fois des données de fonctionnement et de pompage LS dans ES via le plug-in de sortie standard.

ElasticSearch [v1.5.0]

Je pense que c'est là que réside le problème principal. ES peut démarrer via service elasticsearch startet continue de fonctionner, est accessible via des requêtes HTTP au port 9200 et tous les signes de vie semblent sains. Dès que quelque chose (quoi que ce soit, pour autant que je sache) essaie d' écrire des données dans un index, le processus meurt et les journaux de débogage @ / var / log / elasticsearch / * ne contiennent rien lié à l'échec du service. J'ai essayé d'insérer via logstash (voir ci-dessous) ainsi qu'avec curl, tous deux mettant fin au processus ES. La commande curl que j'exécute est curl -XPOST "http://localhost:9200/logstash-2015.04.05/records/" -d "{ \"type\" : \"specialRecord\" }".

Logstash [v1.4.2]

Je suis actuellement en cours d'exécution avec cette configuration simple:

input {
    stdin { }
}

output {
        stdout { codec => rubydebug }
        elasticsearch {
                host => '127.0.0.1'
                cluster => 'elasticsearch'
        }
}

Autres notes

Certaines choses que j'ai essayées:

  • J'ai essayé de monter les niveaux de journalisation pour ElasticSearch vers DEBUG / TRACE et la sortie est remarquablement sans intérêt. Heureux de fournir des journaux si cela peut être utile.

  • J'ai essayé de donner à ES 256 Mo et 512 Mo d'espace de stockage, ce qui ne semble rien affecter. J'ai également observé l'utilisation de la mémoire pendant tout cela et le manque de mémoire ne semble pas être un problème.

  • J'ai essayé de désactiver la multidiffusion pour éliminer un tas de variables de réseau, mais cela ne semble pas faire de différence.

  • J'ai veillé à ce que le répertoire de données pour ES a beaucoup d'espace, les permissions d'écriture, etc. ES crée des sous - répertoires dans le path.datarépertoire quand il est chargé , mais je ne crois pas que quoi que ce soit est ajouté depuis quand je redémarre le processus ES les statistiques de l' indice suggèrent que le nombre total de documents est nul.

Je suis assez perplexe maintenant et déçu que rien dont j'ai besoin (ou du moins je puisse trouver) ne soit enregistré. Des idées sur ce qui pourrait se passer ici?


Si vous n'obtenez rien d'utile à partir des journaux, la seule option (autre que la compilation à partir de la source et l'ajout d'instructions de débogage) semble utiliser strace pour surveiller les appels système. Cela pourrait vous donner une idée de la raison pour laquelle elasticsearch est en train de mourir. Pour réduire le volume, démarrez normalement, puis accélérez le processus en cours juste avant de lancer l'écriture.
Paul Haldane

Un crash sans aucun journal me rappelle des problèmes JNI, n'y a-t-il pas de vidage de processus JVM ( hs_err_PID.log)? ES 1.5 utilise une bibliothèque native appelée Sigar pour la surveillance, il peut y avoir un problème avec l'ARM de Raspberry. Pourriez-vous essayer de lancer Sigar seul? J'essaierais de passer à ES 1.5.2 ou ES 2.0 qui n'utilise plus Sigar.
G Quintana

Avez-vous désactivé le swap?
Rumbles

Elasticsearch recommande pour commencer la RAM 8G. Une fois, je l'ai exécuté sur un Raspberry Pi 3. Cela fonctionne, mais vous devez être un peu prudent avec la vitesse à laquelle vous envoyez des données et les requêtes peuvent également prendre un certain temps.
webwurst

Réponses:


1

Vous avez besoin de plus de matériel

Votre raspi peut être (considérablement) sous-alimenté pour votre charge de travail.

Je ne suis en aucun cas un expert d'Elasticstack, mais je l'ai configuré dans plusieurs scénarios de test et pour une utilisation en production limitée / légère. D'après mon expérience, alors que la configuration initiale nécessite relativement peu de ressources, à mesure que le nombre d'index augmente, le système génère beaucoup plus d'E / S de disque et de charge CPU.

Cela est particulièrement apparent après un redémarrage pendant que le système récupère les fragments. Si vos index ne sont pas trop grands, vous pouvez envisager des compartiments mensuels au lieu des compartiments quotidiens par défaut, ce qui semble aider à cet égard.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.