es-hadoop : Préparer un cluster en vue d'une utilisation d'es-hadoop
98 views
Skip to first unread message
Jérémy Meyer
Mar 25, 2015, 5:05:31 AM3/25/15
to elastics...@googlegroups.com
Bonjour,
Mon problème est le suivant, n'ayant jamais utilisé es-hadoop, et vu qu'il n'y a que très peu d'informations à ce sujet sur le site d'Elastic, je me demandais :
Cordialement, Jérémy MEYER.
je suis un nouveau parmi cette communauté florissante qu'est Elasticsearch, et je me posais quelques questions. On m'a renvoyé vers ce groupe pour pouvoir y avoir des réponses, en espérant que ce ne soit pas déjà des sujets posés.
Donc voilà, je suis apprenti au sein d'une entreprise qui gère une grande quantité de logs de manière journalière, sans trop de détail je préciserai juste que j'ai déjà un peu utilisé Elasticsearch sur mon PC local, et maintenant nous aimerions le tester sur des serveurs plus puissants.Mon problème est le suivant, n'ayant jamais utilisé es-hadoop, et vu qu'il n'y a que très peu d'informations à ce sujet sur le site d'Elastic, je me demandais :
- Quel type d'architecture serait le mieux pour pouvoir tester es-hadoop ?
- Comment puis-je réaliser une configuration significative de test d'es-hadoop avec 3 serveurs ?
- Est-ce qu'utiliser des VM est une bonne solution ? Car je me voyais mal configurer un serveur en hadoop et deux autres en Elasticsearch ...
- A moins que j'ai mal compris le principe et que les deux doivent être installés sur chaque nœud ?
- Ou bien dois-je demander d'autres serveurs pour des tests plus significatifs ? (je sais que 2 nœuds Elasticsearch posent problème avec le split brain, c'est également pour cela que je pose la question).
Cordialement, Jérémy MEYER.
Aurélien Dehay
Mar 25, 2015, 6:56:43 AM3/25/15
to elasticsearch-fr
Bonjour.
Nous avons actuellement en test une architecture similaire sur des petits PC, mais basée sur du Spark, pas sur de l'hadoop. Voilà notre architecture:
- 2 petits serveurs (8Go mémoire, 8 cores)
- 2 VMs par serveur (2 VMs de 4Go et 4 cores)
Donc 4 VMs:
1ère VM:
- master mesos / marathon (pour le lancement d'elasticsearch sur les noeuds mesos) / spark (où on fait le spark-submit)
- un zookeeper (pour mesos)
- un namenode hdfs
- divers trucs pour les tests spark (metastore mysql)
3 noeuds mesos
- client mesos
- datanode hdfs
Marathon via Mesos lance un noeud de cluster elasticsearch sur chaque VM
Spark est configuré pour utiliser mesos pour distibuer les taches en mode fine grain.
Spark lance les tâches suivantes, grosso modo:
- lecture d'un flux en entrée (ce ne sont pas des logs) ou un fichier sur disque/hdfs
- génère des statistiques
- écrit les données brutes et les stats dans elasticsearch via elasticsearch-spark (composant du elasticsearch-hadoop)
Selon moi, que tu utilises hadoop ou spark, c'est pas très différent, il faut mettre les ES là où tu lances tes jobs pour profiter de la data localisation, ça évite des lourds transferts réseau.
3 serveurs pour faire du hadoop, ça va pas faire beaucoup. Une solution est de faire de la VM pour avoir plus de serveurs disponibles, ne pas oublier les masters (namenode, resourcemanager, etc).
Ne pas faire d'overprovisionning (mettre plus de vCPU qu'il n'y a de core sur le serveur) permet d'avoir des perfs assez aléatoires. Ne pas faire de l'image VM, mais, si c'est possible, "lier" le(s) disque(s) directement à une VM en passthrough
Après, ça dépend des tests et de la volumétrie, mais 3 serveurs et de la VM ça pourrait être suffisant.
A.
--
--
---
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.
Jérémy Meyer
Mar 26, 2015, 8:27:02 AM3/26/15
to elastics...@googlegroups.com
Bonjour Aurélien, et merci pour votre réponse si rapide !
Mes serveurs ne sont pas encore kités (quelques problèmes apparemment) mais ça ne saurait tarder, j'essayerai de voir du côté de Spark peut-être alors (j'ai surtout entendu du bien de Spark vis-à-vis d'Hadoop, niveau temps réel etc ...)
Donc si j'ai bien compris une chose, en général on stocke dans hadoop/spark (en HDFS), et après on alimente Elasticsearch grâce à Hadoop/spark ... Il y a une chose qui me fait peur, j'ai essayé Hadoop avec Cassandra, et les performances ne m'ont vraiment pas impressionné du tout ... (j'ai utilisé Hive) Même si l'insertion est rapide, vous parliez de faire des traitements et les insérer, mais ces traitements ne seront-ils pas lents ? A moins que je devrais insérer dans Elasticsearch les données pour lesquels je veux du temps réel et utiliser Hive -> Elasticsearch seulement pour le batch processing ?
Pour ce qui suit par contre, n'ayant aucune connaissance dans la VM, je n'ai pas totalement compris, mais je vais me renseigner !
Je vous remercie grandement pour cette réponse en tout cas :)
A bientôt !
Mes serveurs ne sont pas encore kités (quelques problèmes apparemment) mais ça ne saurait tarder, j'essayerai de voir du côté de Spark peut-être alors (j'ai surtout entendu du bien de Spark vis-à-vis d'Hadoop, niveau temps réel etc ...)
Donc si j'ai bien compris une chose, en général on stocke dans hadoop/spark (en HDFS), et après on alimente Elasticsearch grâce à Hadoop/spark ... Il y a une chose qui me fait peur, j'ai essayé Hadoop avec Cassandra, et les performances ne m'ont vraiment pas impressionné du tout ... (j'ai utilisé Hive) Même si l'insertion est rapide, vous parliez de faire des traitements et les insérer, mais ces traitements ne seront-ils pas lents ? A moins que je devrais insérer dans Elasticsearch les données pour lesquels je veux du temps réel et utiliser Hive -> Elasticsearch seulement pour le batch processing ?
Pour ce qui suit par contre, n'ayant aucune connaissance dans la VM, je n'ai pas totalement compris, mais je vais me renseigner !
Je vous remercie grandement pour cette réponse en tout cas :)
A bientôt !
Aurélien Dehay
Mar 27, 2015, 6:18:10 AM3/27/15
to elasticsearch-fr
Bonjour.
J'avais commencé un mail, mais finalement j'ai relu ton mail d'origine.
Pourquoi es-hadoop? Des gros volumes de logs, on en traite directement dans elasticsearch. Chez nous, nous utilisons graylog (donc du elasticsearch en stockage) pour ingérer quelques dizaines de milliers de log à la seconde, ça marche bien sans hadoop ou spark.
Les capacités d'analyse d'ES sont souvent suffisantes, avec kibana ou en faisant directement les requêtes sur le cluster.
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.
Jérémy Meyer
Mar 27, 2015, 8:12:41 AM3/27/15
to elastics...@googlegroups.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 !
Cordialement, Jérémy MEYER.
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 !
Cordialement, Jérémy MEYER.
David Pilato
Mar 27, 2015, 1:43:57 PM3/27/15
to elastics...@googlegroups.com
Quelques commentaires...
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 ...
Mouais. Entre dire qu'en tant qu'éditeur nous sommes prudents et nous ne conseillons pas pour des données critiques d'utiliser Elasticsearch comme seul datastore et dire que Elasticsearch n'est pas fiable, il y a une grosse marge.
Certes Lucene n'a que 15 ans d'existence si on compare avec les SGBDs qui ont plus de 30/40 ans...
Il y a dans Elasticsearch beaucoup de protections maintenant pour minimiser le risque. Sachant que tu répètes la même opération d'indexation sur une autre machine, la probabilité que les deux soient corrompues reste faible.
En plus, il y a du backup et du restore vers FS, S3, Azure et HDFS.
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. :)
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.
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.
(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)
Il y a des clusters Elasticsearch en prod avec des milliards de logs (en France aussi :) ) donc je dirais comme ça que ça doit bien être faisable...
Donc si vous avez des arguments pour me convaincre de ne pas l'utiliser, faites m'en part !
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 !
David
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.
Jérémy Meyer
Apr 1, 2015, 8:13:20 AM4/1/15
to elastics...@googlegroups.com
Bonjour David,
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. :)
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 ?
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 vous remercie pour votre réponse, je vais l'essayer sur les serveurs qui viennent d'être kités.
Cordialement, Jérémy MEYER.
David Pilato
Apr 1, 2015, 12:25:36 PM4/1/15
to elastics...@googlegroups.com
Hello
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 ?
Aucune idée. La seule qui me vient est que souvent les « décideurs » dès qu’ils ont un projet nommé « BIG DATA » commencent par dire: Ah ? il faut que je mette Hadoop… Puis après, il essaye d’en faire quelque chose.
En tout cas, je ne pense pas avoir moi-même beaucoup parlé de Hadoop sauf lorsqu’on m’a posé la question...
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 ?
Pascal P.
Apr 1, 2015, 7:16:33 PM4/1/15
to elastics...@googlegroups.com
Hello,
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.
D'ailleurs on voit aussi des usages d'ES sur cassandra, couchbase, etc, sans hadoop...
En faisant abstraction de hadoop et ES, si votre boite génère vraiment beaucoup de logs, ces logs ont de la valeur, pas forcément visible aujourd'hui, mais moins on les touche, plus on a la capacité "un jour" d'appliquer des nouveaux traitements dessus. Il est sage, dans la mesure du possible, de toujours les conserver les logs au format brut original pour être capable, au besoin, de les réinjecter dans un système quelconque.
Si demain un super outil de data mining sort il sera plus facile de l'alimenter depuis des fichiers bruts qu'extraire les logs depuis ES vous avez pas fini de scroller les pages, de recharger les indexes éteints, etc. Je passe tous les problèmes de mapping, de réindexation, de choix cornéliens sur le format json à adopter etc.
De plus pouvoir injecter depuis les logs bruts ça apporte une certaine souplesse dans la façon de gérer le cluster ES, ça diminue le risque et la gravité des boulettes.
Perso je vois la stack ELK comme un "outil" supplémentaire et non comme "la" solution de gestion des logs, parce que même si c'est séduisant, on ne peut pas tout faire avec, certains kpi / conso / dashboard sont trop compliqués / voir impossibles à faire avec des requêtes es parce que ça nécessite des calculs trop sophistiqués et des pré-consos, et il est plus simple de le coder directement sur hadoop avec mapr/pig, hive ou je ne sais quoi pas forcément sur hadoop d'ailleurs, en partant des logs bruts originaux, quitte ensuite à cracher ces résultats dans ES pour ensuite faire des jolis camembert avec khibana.
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.
D'ailleurs on voit aussi des usages d'ES sur cassandra, couchbase, etc, sans hadoop...
En faisant abstraction de hadoop et ES, si votre boite génère vraiment beaucoup de logs, ces logs ont de la valeur, pas forcément visible aujourd'hui, mais moins on les touche, plus on a la capacité "un jour" d'appliquer des nouveaux traitements dessus. Il est sage, dans la mesure du possible, de toujours les conserver les logs au format brut original pour être capable, au besoin, de les réinjecter dans un système quelconque.
Si demain un super outil de data mining sort il sera plus facile de l'alimenter depuis des fichiers bruts qu'extraire les logs depuis ES vous avez pas fini de scroller les pages, de recharger les indexes éteints, etc. Je passe tous les problèmes de mapping, de réindexation, de choix cornéliens sur le format json à adopter etc.
De plus pouvoir injecter depuis les logs bruts ça apporte une certaine souplesse dans la façon de gérer le cluster ES, ça diminue le risque et la gravité des boulettes.
Perso je vois la stack ELK comme un "outil" supplémentaire et non comme "la" solution de gestion des logs, parce que même si c'est séduisant, on ne peut pas tout faire avec, certains kpi / conso / dashboard sont trop compliqués / voir impossibles à faire avec des requêtes es parce que ça nécessite des calculs trop sophistiqués et des pré-consos, et il est plus simple de le coder directement sur hadoop avec mapr/pig, hive ou je ne sais quoi pas forcément sur hadoop d'ailleurs, en partant des logs bruts originaux, quitte ensuite à cracher ces résultats dans ES pour ensuite faire des jolis camembert avec khibana.
Pascal
Jérémy Meyer
Apr 2, 2015, 3:46:53 AM4/2/15
to elastics...@googlegroups.com
C'est bien ce qui me semblait ... Je verrai au pire en essayant les deux, un grand merci en tout cas, et merci pour le lien, j'ai dû rater ce chapitre lorsque j'avais lu la doc !
Cordialement, Jérémy MEYER.
Cordialement, Jérémy MEYER.
Jérémy Meyer
Apr 2, 2015, 4:04:35 AM4/2/15
to elastics...@googlegroups.com
Bonjour,
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.
L'entreprise dans laquelle je suis, utilise SQL Server pour le moment, donc ce serait pour remplacer totalement autant la partie récupération de logs que la partie stockage/traitement.
Donc Hadoop aurait son intérêt si les consos que l'on doit faire sont trop compliquées pour les réaliser en ES, dans ce cas va falloir que j'approfondisse un peu plus les consos existantes que je dois réaliser. Quant à ELK, la partie qui me pose personnellement problème est Logstash, que je trouve déjà peu adapté à Windows (fonctionne avec un système d'i-node alors que Windows n'en a pas), et parfois je ne sais pas pourquoi il n'insère pas toutes les données ... Hummm peut-être que je fais des erreurs dans la configuration je ne sais pas, mais je ne pense pas me tromper pour le dossier des logs à insérer en mettant un wildcard après le chemin du dossier, après c'était peut-être un bug qui a été corrigé, je ne l'ai pas réutilisé depuis quelques mois. Quoiqu'il en soit j'ai encore beaucoup à apprendre !
Cordialement, Jérémy MEYER.
Donc Hadoop aurait son intérêt si les consos que l'on doit faire sont trop compliquées pour les réaliser en ES, dans ce cas va falloir que j'approfondisse un peu plus les consos existantes que je dois réaliser. Quant à ELK, la partie qui me pose personnellement problème est Logstash, que je trouve déjà peu adapté à Windows (fonctionne avec un système d'i-node alors que Windows n'en a pas), et parfois je ne sais pas pourquoi il n'insère pas toutes les données ... Hummm peut-être que je fais des erreurs dans la configuration je ne sais pas, mais je ne pense pas me tromper pour le dossier des logs à insérer en mettant un wildcard après le chemin du dossier, après c'était peut-être un bug qui a été corrigé, je ne l'ai pas réutilisé depuis quelques mois. Quoiqu'il en soit j'ai encore beaucoup à apprendre !
Cordialement, Jérémy MEYER.
Pascal P.
Apr 3, 2015, 1:53:43 AM4/3/15
to elastics...@googlegroups.com
Logstash c'est comme hadoop, rien ne t'oblige à t'en servir non plus :-)
David Pilato
Apr 3, 2015, 2:09:38 AM4/3/15
to elastics...@googlegroups.com
Exact.
David
David
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.
Reply all
Reply to author
Forward
0 new messages