--
--
---
Vous pouvez également poster et consulter les réponses en anglais sur le groupe Elasticsearch https://groups.google.com/group/elasticsearch
Si vous avez également posté votre question sur la mailing list elasti...@googlegroups.com, merci d'indiquer ici le lien vers cette discussion pour faciliter le suivi.
Twitter : @ElasticsearchFR https://twitter.com/#!/ElasticsearchFR
Site web (English) : http://www.elasticsearch.org/
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Elasticsearch FR".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse elasticsearch-...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse elastics...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/elasticsearch-fr.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/elasticsearch-fr/00c02088-7821-4c5f-b3d8-c48899ba2951%40googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/elasticsearch-fr/780593b2-0b67-46ee-806e-cc9397c222e7%40googlegroups.com.
Bonjour,
Pourquoi es-hadoop ? Parce que j'ai cru comprendre que son intérêt était lié à l'archivage à long terme (apparemment Elasticsearch n'est pas la meilleure solution pour le stockage à long terme et même pour le stockage tout court) et que mon entreprise ne veut que des choses "sûres" (cf : http://www.quora.com/Why-should-I-NOT-use-ElasticSearch-as-my-primary-datastore). C'est pour ça que je vous rejoins sur le fait qu'ES a de bonnes performances pour l'analyse certes, mais n'est pas des plus fiables pour le stockage ...
Nous avions prévus de notre côté d'utiliser Logstash avec Elasticsearch (je l'ai déjà testé, il ne me convient pas totalement mais j'ai essayé d'autres shipper (je n'ai pas encore regardé du côté de graylog), et ça ne donnait que de moins bons résultats encore).
Nous avons presque 500/600Go de logs par jour (en sachant qu'un fichier de logs de 3000 lignes ~= 250/300Ko) et on veut au minimum avoir la semaine entière de logs (ce qui est actuellement réalisé en SQL pour le moment). C'est d'ailleurs pour cela que j'avais pensé à injecter les logs dans Elasticsearch et les archiver dans Hadoop dès que la semaine est passée, mais je ne sais pas si c'est une bonne solution.
(Mon responsable m'a fait part justement de problèmes où il voulait remonter sur des logs de 3 semaines et ça n'était pas possible avec leur archi qui ne dure qu'1 semaine)
Donc si vous avez des arguments pour me convaincre de ne pas l'utiliser, faites m'en part !
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/elasticsearch-fr/2b237a16-69e4-46b5-bf18-ee9916e6eedc%40googlegroups.com.
Néanmoins, même si la probabilité reste faible, elle n'est pas encore nulle.Ensuite, c'est une question de use case et d'argent. Si tes logs ne sont pas si critiques que ça et que tu fais une rotation des logs à l'heure, au pire, tu vas perdre une heure de logs.A mettre en face de ça, le coût d'une solution plus coûteuse... Double de stockage. Fois X pour le coût de mise en place puis de supervision et maintenance.Parenthèse commerciale: Des fois, ça te coûtera peut être moins cher de prendre du support d'ailleurs ! Fin de la parenthèse. :)
Tu peux aussi déplacer les index vieux vers des machines moins puissantes puis au bout de quelques temps juste "fermer" l'index.Réouvrir si besoin. Puis définitivement les effacer quand il n'y a plus besoin de les conserver.
Un argument. Si tu veux faire du search absolument temps réel, ne prends pas Elasticsearch et fais comme tu peux avec ta base de données. La latence Elasticsearch est de 1s par défaut.Je suis mal placé évidemment pour te déconseiller. Au contraire, je dirais : essaye et vois ce que cela donne sur une journée de logs...En espérant avoir apporté quelques éclaircissements !
Je suis exactement dans le cas que vous précisez, des logs pas forcément critiques avec une rotation à l'heure ... C'est mon responsable qui s'occupe de la partie commerciale et qui a l'air de vouloir partir sur de l'Hadoop + Elasticsearch. A la base, je voulais l'utiliser directement comme base de données comme vous le proposez, donc si j'ai bien compris, ce serait suffisant pour ce cas ... Pourquoi les gens qui présentent Elasticsearch dans des conférences essayent tant de vendre es-hadoop dans ce cas ? Je ne comprends pas ... Les besoins ne seraient pas les mêmes ? Du coup petite parenthèse mais auriez-vous un exemple de besoin que seul es-hadoop pourrait satisfaire ?
Tu peux aussi déplacer les index vieux vers des machines moins puissantes puis au bout de quelques temps juste "fermer" l'index.Réouvrir si besoin. Puis définitivement les effacer quand il n'y a plus besoin de les conserver.
Excusez moi de vous posez une question de la sorte, mais qu'entendez-vous par "fermer" l'index ?
Pour gérer de la volumétrie avec ES il n'y a pas d'"obligation" à utiliser Hadoop" mais beaucoup de boites ont déjà des clusters hadoop, souvent les logs bruts sont déjà collectés sur hdfs avec flume (ou autre), et es-hadoop est "logique" dans cette archi. Il y a en général déjà plusieurs calculs de kpi / conso / rapports avec mapr, pig, hive etc, parfois déjà rangés dans du hbase, installer "en plus" es-hadoop pour indexer aussi ces fichiers dans un moteur de recherche permet de bénéficier, à moindre coût, d'une ihm sympa pour les interroger en temps réel et faire des jolis dashboard dynamiques avec khibana.
Logstash c'est comme hadoop, rien ne t'oblige à t'en servir non plus :-)
--
--
---
Vous pouvez également poster et consulter les réponses en anglais sur le groupe Elasticsearch https://groups.google.com/group/elasticsearch
Si vous avez également posté votre question sur la mailing list elasti...@googlegroups.com, merci d'indiquer ici le lien vers cette discussion pour faciliter le suivi.
Twitter : @ElasticsearchFR https://twitter.com/#!/ElasticsearchFR
Site web (English) : http://www.elasticsearch.org/
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Elasticsearch FR".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse elasticsearch-...@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse elastics...@googlegroups.com.
Visitez ce groupe à l'adresse http://groups.google.com/group/elasticsearch-fr.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/elasticsearch-fr/c698f890-f570-4524-a881-050a7cba5f2a%40googlegroups.com.