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?
la source
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.Réponses:
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.
la source