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

1. Vladislav Pernin 05/11/2015 @vladislavpernin 1   Centralisation de grands volumes de logs Logstash, Apache Kafka, elasticsearch
2. Agenda •  Contexte •  Cas d’utilisations •  Architecture •  Métriques •  Retour d’expérience 2
3. 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
4. Cible •  Temps réel •  Robuste & scalable horizontalement •  Sans perte •  Recherche facile •  Complexité limitée 4
5. Cas d’utilisations : centralisation des logs 5
6. 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
7. Architecture 7 3 nœuds 3 nœuds 6 nœuds
8. 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
9. Retour d’expérience 9 •  Logstash •  RabbitMQ & Apache Kafka •  elasticsearch •  IHM •  Points d’attention
10. Logstash 10 •  Le plus riche fonctionnellement •  Installation facile (tar.gz, deb, RPM, docker) •  Rapide à mettre en œuvre •  Extensible •  Grande communauté •  Support unifié avec elasticsearch
11. 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
12. 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
13. 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)
14. 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
15. 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
16. 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)
17. 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
18. 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
19. 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)
20. 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
21. 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
22. Dashboard simplifié 22
23. 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]))
24. Surveillance 24
25. Types, agrégations & détail 25
26. 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)
27. 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 ?
28. 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
29. 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
30. 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
31. 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
32. 32 Questions ? @vladislavpernin