Save 37% off PRO during our Black Friday Sale! »

Elastic On Tour Paris - Centralisation de grands volumes de logs

Elastic On Tour Paris - Centralisation de grands volumes de logs

Edc84722f6c279f6a3ef1584fc03acff?s=128

Vladislav Pernin

November 05, 2015
Tweet

Transcript

  1. Vladislav Pernin 05/11/2015 @vladislavpernin 0 Centralisation de grands volumes de

    logs Logstash, Apache Kafka, elasticsearch
  2. Agenda • Contexte • Cas d’utilisations • Architecture • Métriques

    • Retour d’expérience 1
  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
  4. Cible • Temps réel • Robuste & scalable horizontalement •

    Sans perte • Recherche facile • Complexité limitée 3
  5. Source d’informations 4

  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
  7. Architecture 6 3 nœuds 3 nœuds 6 nœuds

  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
  9. Retour d’expérience 8 • Logstash • RabbitMQ & Apache Kafka

    • elasticsearch • IHM • Points d’attention
  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
  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
  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
  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)
  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
  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é
  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)
  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
  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
  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)
  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
  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
  22. Dashboard simplifié 21

  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]))
  24. Recherche & détail 23

  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
  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 ?
  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
  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
  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
  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
  31. 30 Questions ? @vladislavpernin