Elastic On Tour Paris - Centralisation de grands volumes de logs

Transcript

1. Vladislav Pernin 05/11/2015 @vladislavpernin
   0
   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
   1
   

   View Slide

3. Contexte
   • Beaucoup de serveurs
   • Accès limité
   • Architecture distribuée & asynchrone
   • Stop aux commandes : tail sed awk grep
   • Réduction du temps de détection & analyse
   • Vision sur le SI & sa performance
   2
   

   View Slide

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

   View Slide

5. Source d’informations
   4
   

   View Slide

6. Cas d’utilisations
   5
   • Surveillance temps réel (dev -> prod)
   • Aide aux équipes
   • Recherche de bugs & reproductibilité
   • Audit proactif
   • Chemin utilisateur & supervision flux
   • Statistiques fonctionnelles & expérience utilisateur
   • Compteurs communicants
   

   View Slide

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

   View Slide

8. Métriques
   • En production depuis 4 ans
   • 8 projets, 50 environnements, 900 serveurs
   • 65 types de logs
   • 1,1 Md docs & 290 Go (primary store)
   • 250 logs/s minimum & 8000 en pic
   • 240 utilisateurs & 10 000 requêtes/j
   7
   

   View Slide

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

   View Slide

10. Logstash
    9
    • Le plus riche fonctionnellement
    • Tail « intelligent »
    • Installation facile (tar.gz, deb, RPM, docker)
    • Rapide à mettre en œuvre
    • Extensible
    • Grande communauté
    • Support unifié avec elasticsearch
    

    View Slide

11. Logstash
    10
    • Structurer ses logs (extraction champs)
    Découpage via Grok
    o Puissant
    o Debug difficile
    o Tests unitaires & performances indispensables
    o Multiplier les nœuds (scalabilité horizontale)
    Directement au format JSON
    

    View Slide

12. Logstash
    11
    • Encore jeune et mouvant
    • Problèmes de jeunesse
    Rétro compatibilité
    40s de démarrage
    Perte possible (queue persistante roadmap)
    Crash : désactivation invokedynamic JRuby
    Ligne log partielle : inodes recyclés, job nettoyage sincedb
    

    View Slide

13. Logstash
    12
    • Efficience : rapport fonctionnalité / charge CPU
    Ok : petite volumétrie
    Ko : 1500 lignes/s
    Beaucoup mieux versions récentes
    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
    13
    • RabbitMQ
    Sécurité
    Ok jusqu’à 5000/s
    Empreinte CPU importante, scalabilité difficile
    • Apache Kafka
    Throughput important (200 000/s sans tuning)
    Nativement persistant, scalable, léger
    Quelques défauts de jeunesse (API, ops, sécurité) … surmontables
    Robuste & sûr
    

    View Slide

15. elasticsearch
    14
    • Outil mature
    • Grande communauté
    • Documentation de bonne qualité
    • Installation facile (tar.gz, deb, RPM, docker)
    • Release fréquente & upgrade aisé
    • Haute disponibilité & scalabilité
    

    View Slide

16. elasticsearch
    15
    • 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
    16
    • Quelques problèmes
    Sur versions anciennes
    o Tri, CorruptedIndex
    o OutOfMemory sur agrégation
    Recovery très long
    • River RabbitMQ
    Pratique (non interruption, queuing et reprise)
    Problèmes de robustesse, scale pas
    River déprécié, Logstash en push direct
    

    View Slide

18. elasticsearch
    17
    • API query
    Puissante mais compliquée
    Agrégation / sous agrégation / pipeline
    Join impossible
    • Mapping
    Connaître structure et types de recherche
    Montée en compétence indispensable
    Template par défaut de Logstash pour commencer
    

    View Slide

19. elasticsearch
    18
    • Partitioning via nommage des index (un par semaine)
    • Volumétrie fluctuante mais sharding fixe
    • Nouveau mapping : attendre rotation ou réindexer
    • Sécurité : aucune en natif, Shield (commerciale)
    • Outillage limité : plugins, Curator, Marvel (commerciale en 1.x)
    

    View Slide

20. elasticsearch
    19
    • Performance : OK sur SAN et VMs
    • Recherche : 100M en qq ms
    • Compression : 70 % de gain
    • Jamais le goulot d'étranglement
    • Paramétrage minimal à effectuer
    • Valeurs par défaut efficaces
    

    View Slide

21. elasticsearch
    20
    • IHM
    En production depuis 2011
    IHM de Logstash KO, Kibana (PHP, Ruby puis AngularJS)
    Spécifique : intégration fine dans le SI
    • Kibana : rapport fonctionnalité / coût favorable
    

    View Slide

22. Dashboard simplifié
    21
    

    View Slide

23. elasticsearch
    22
    • Cas d’utilisation : surveillance d’environnement (extrait)
    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 1000]))
    

    View Slide

24. Recherche & détail
    23
    

    View Slide

25. Remarques diverses
    24
    • Transparence sur la qualité des applications
    • … et des logs eux-mêmes
    • Travail important sur la qualité des logs
    Uniformisation structure
    Enrichissement : env, projet et application
    Audit : identifiant de corrélation
    

    View Slide

26. Remarques diverses
    25
    • Tout centraliser et partout
    • Déploiement automatique
    • Questions
    Où groker : côté agent ou serveur ?
    Log brut sur fichier puis Logstash ou streaming JSON direct au broker ?
    Quid de la supervision et des logs de la stack ?
    

    View Slide

27. Pour finir
    26
    • Nouvelles technologies
    Apprentissage, jeunesse, intégration, lobbying
    • Déploiement : absorption différents env.
    • Volumétrie
    Ne pas sous estimer son augmentation
    RabbitMQ à remplacer
    Instances de Logstash à multiplier
    • Overhead : limité, rapport gain / perte OK
    

    View Slide

28. Pour finir
    27
    • En plein mouvement
    • Stack technique adaptée et scalable
    Logstash ou appender
    Apache Kafka
    elasticsearch
    • Mise en place initiale rapide
    Ne pas sous estimer le temps d’industrialisation
    

    View Slide

29. Pour finir
    28
    • Visibilité & autonomie de toutes les équipes
    • Temps de diagnostic réduit
    • Corrélation entre applications et SI
    • Indicateurs divers
    • A venir
    Volumétrie x100 : pic à 50 000 logs/s & 100 Md
    Déploiement continu automatique
    

    View Slide

30. En synthèse
    29
    • Un système d’information sous surveillance
    • Proactivité
    • Complexité limitée
    • Favorise implication et communication
    • Devenu un des outils le plus utilisé @ ERDF
    

    View Slide

31. 30
    Questions ?
    @vladislavpernin
    

    View Slide