Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Centralizing high volumes of logs with Elastics...

Avatar for Elastic Co Elastic Co
November 05, 2015

Centralizing high volumes of logs with Elasticsearch : a vision on the information system of the smart meters

Avant 2011, ERDF disposait de nombreux serveurs qui généraient de grands volumes de logs corrélés entre eux mais non centralisés. Après estimation des solutions disponibles, ERDF a finalement construit une architecture combinant Logstash et Elasticsearch afin de centraliser et surveiller ses logs. La présenation offre également un retour d'expérience sur les différentes solutions de l'architecture d'ERDF.

Vladislav Pernin | Elastic{ON} Tour | Paris, France

Avatar for Elastic Co

Elastic Co

November 05, 2015
Tweet

More Decks by Elastic Co

Other Decks in Technology

Transcript

  1. Contexte •  Beaucoup de serveurs •  Accès limité •  Architecture

    distribuée (Hadoop, Storm, Kafka, elasticsearch, …) •  Architecture asynchrone •  Stop aux commandes : tail sed awk cat grep •  Réduction du temps de détection & analyse •  Vision sur le SI & sa performance 3
  2. Cible •  Temps réel •  Robuste & scalable horizontalement • 

    Sans perte •  Recherche facile •  Complexité limitée 4
  3. Cas d’utilisations 6 •  Surveillance temps réel (dev -> prod)

    •  Aide : développeur, recetteur, expertise, production •  Recherche de bugs et de reproductibilité •  Audit proactif •  Chemin fonctionnel d’un utilisateur •  Statistiques fonctionnalités métiers •  Compteurs communicants : vision fine & analyse logs
  4. Métriques •  En production depuis 4 ans •  8 projets,

    50 environnements, 600 serveurs •  25 types de logs •  1 milliard de documents, 280 Go (primary store) •  250 logs/s en moyenne & 8000 logs/s en pic •  IHM : 250 comptes & 10 000 requêtes/j 8
  5. Retour d’expérience 9 •  Logstash •  RabbitMQ & Apache Kafka

    •  elasticsearch •  IHM •  Points d’attention
  6. Logstash 10 •  Le plus riche fonctionnellement •  Installation facile

    (tar.gz, deb, RPM, docker) •  Rapide à mettre en œuvre •  Extensible •  Grande communauté •  Support unifié avec elasticsearch
  7. Logstash 11 •  Tail « intelligent » •  Input syslog

    / exec : appliance / statistiques SQL Oracle •  Structurer ses logs (extraction champs date, level, user, message, …) §  Découpage via Grok o Puissant mais debug difficile o Tests unitaires & performances indispensables o + de Logstash (scalabilité horizontale) §  Directement au format JSON
  8. Logstash 12 •  Encore jeune et mouvant •  Problèmes de

    jeunesse •  Rétro compatibilité (config, plugin externalisé) •  40s de démarrage •  Perte possible (queue persistante en roadmap) •  Crash : désactivation invokedynamic JRuby •  Recyclage inodes : job nettoyage fichiers sincedb
  9. Logstash 13 •  Efficience : rapport fonctionnalité / charge CPU

    §  OK : petite volumétrie §  KO : 1500 lignes/s §  Amélioration récente §  Streaming direct vers broker •  Shipper plus léger, plus performant, moins de fonctionnalités (Logstash forwarder / Filebeat)
  10. Transport via broker de messages 14 •  RabbitMQ §  Sécurité

    §  Ok jusqu’à 5000/s §  Empreinte CPU importante, scalabilité difficile •  Apache Kafka §  Throughput important (200 000/s sans tuning) §  Nativement persistant, scalable horizontalement, léger §  Quelques défauts de jeunesse (API, ops, sécurité) … surmontables §  Robuste
  11. elasticsearch 15 •  Outil mature •  Grande communauté •  Documentation

    désormais de bonne qualité •  Installation facile (tar.gz, deb, RPM, docker) •  Release très fréquente & upgrade aisée •  Haute disponibilité & scalabilité horizontale
  12. elasticsearch 16 •  Pas un use case natif en 2011

    •  Comparaison de nombreux outils (open source et propriétaire) •  Très puissant : stocker et chercher des logs en temps réel •  Alerting : percolation, voir désormais Watcher •  D’autres uses cases @ ERDF (recherche clients & matériels, statistiques)
  13. elasticsearch 17 •  Quelques problèmes §  Sur versions anciennes o Tri,

    CorruptedIndex o OutOfMemory sur agrégation / circuit breaker (limitation scope) §  Recovery très long •  River RabbitMQ §  Pratique (queuing et reprise) §  Problèmes de robustesse, scale pas §  River déprécié, Logstash en push direct
  14. elasticsearch 18 •  API query § Puissante mais compliquée § Agrégation /

    sous agrégation / pipeline § Join impossible •  Structure logs & type de recherches => quels mappings •  Montée en compétence indispensable •  Template par défaut de Logstash suffisant pour commencer
  15. elasticsearch 19 •  Partitioning aisé via nommage des index (un

    par semaine) •  Volumétrie fluctuante mais sharding fixe •  Nouveau mapping : attendre rotation index ou réindexer avec alias •  Sécurité §  Aucune nativement, iptables, proxy §  Shield (commerciale), simple à mettre en place •  Outillage limité : divers plugins, curator, Marvel (commerciale)
  16. elasticsearch 20 •  Performance : OK sur SAN et VMs

    •  Recherche : 100M en qq ms •  Compression efficace : 70 % de gain •  Jamais le goulot d'étranglement •  Paramétrage minimal à effectuer •  Valeurs par défaut efficaces
  17. elasticsearch 21 •  IHM §  En production depuis 2011 § 

    IHM de Logstash KO, Kibana (Ruby puis AngularJS) §  Développement spécifique : intégration fine dans le SI •  Kibana : rapport fonctionnalité/coût favorable
  18. elasticsearch 23 •  Cas d’utilisation : surveillance d’environnement (extrait) • 

    Création d’anomalies JIRA automatique level:(warn OR error OR fatal) AND !(iduser* "ISPN000042: Did not find queried attribute with name") AND !((application:kafka AND "Connection reset by peer") "No data found" "caught end of stream" "from old client" ("in zookeeper" AND "doesn't exist yet") ((troncon OR branchement) AND "ne sera pas") (environment:rec AND NullPointerException AND MaterielServiceImpl:12) (environment:perf AND durationmillisec:[0 TO 2000]))
  19. Remarques diverses 26 •  Transparence sur la qualité des applications

    •  … et des logs eux-mêmes •  Travail important sur la qualité des logs §  Uniformisation structure §  Enrichissement : environnement, projet et application §  Identifiant de corrélation : suivi à travers toute l’architecture (js, API, java, service, webservice, broker, backend)
  20. Remarques diverses 27 •  Tout centraliser et partout •  Questions

    §  Où groker : côté agent ou serveur ? §  Log brut sur fichier, tail Logstash ou streaming JSON direct au broker ? §  Superviser la stack / quid des logs de Logstash et elasticsearch ?
  21. Pour finir 28 •  Nouvelles technologies (apprentissage, intégration, lobbying, jeunesse)

    •  Déploiement automatique : absorption différents env/projet/topologie •  Volumétrie §  Ne pas sous estimer son augmentation §  RabbitMQ à remplacer §  Instances de Logstash à multiplier •  Overhead : limité, rapport gain/perte OK
  22. Pour finir 29 •  En plein mouvement •  Stack technique

    adaptée et scalable §  Logstash ou appender §  Apache Kafka §  Elasticsearch •  Mise en place initiale très rapide §  Ne pas sous estimer le temps d’industrialisation
  23. Pour finir 30 •  Visibilité & autonomie de toutes les

    équipes •  Temps de diagnostic réduit •  Corrélation entre applications et SI •  Indicateurs divers & proactivité •  A venir : volumétrie x100 §  Pics à plus de 50 000 logs/s §  Plus de 100 milliards de documents
  24. En synthèse 31 •  Un système d’information sous surveillance • 

    Complexité limitée •  Favorise implication et communication •  Devenu un des outils le plus utilisé @ ERDF