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

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

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

Elastic Co

November 05, 2015
Tweet

More Decks by Elastic Co

Other Decks in Technology

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