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

Transcript

1. Vladislav Pernin 05/11/2015 @vladislavpernin
   1  
   Centralisation de grands volumes de logs
   Logstash, Apache Kafka, elasticsearch
   

   View Slide

2. Agenda
   •  Contexte
   •  Cas d’utilisations
   •  Architecture
   •  Métriques
   •  Retour d’expérience
   2
   

   View Slide

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
   

   View Slide

4. Cible
   •  Temps réel
   •  Robuste & scalable horizontalement
   •  Sans perte
   •  Recherche facile
   •  Complexité limitée
   4
   

   View Slide

5. Cas d’utilisations : centralisation des logs
   5
   

   View Slide

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
   

   View Slide

7. Architecture
   7
   3 nœuds 3 nœuds
   6 nœuds
   

   View Slide

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
   

   View Slide

9. Retour d’expérience
   9
   •  Logstash
   •  RabbitMQ & Apache Kafka
   •  elasticsearch
   •  IHM
   •  Points d’attention
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

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
    

    View Slide

22. Dashboard simplifié
    22
    

    View Slide

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]))
    

    View Slide

24. Surveillance
    24
    

    View Slide

25. Types, agrégations & détail
    25
    

    View Slide

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)
    

    View Slide

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 ?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

32. 32
    Questions ?
    @vladislavpernin
    

    View Slide