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

LyonJug : centralisation des logs 2014/01

Vladislav Pernin
January 19, 2014
1.2k

LyonJug : centralisation des logs 2014/01

Live coding : mise en place d'une chaîne complète, robuste, performante et scalable avec Logstash, Spring AMQP, RabbitMQ, elasticsearch et Kibana.
Retour d'expérience sur un projet de centralisation des logs en production depuis 2012 chez un grand compte.
Indexation de milliers de logs par seconde, chercher instantanément dans des centaines de Go de logs et dashboards de l'activité d'un environnement en quelques clics.

Vladislav Pernin

January 19, 2014
Tweet

Transcript

  1. Devinette Que peut-on faire avec : • un morceau de

    bois • un lapin • un bonsai • une cahute
  2. Vladislav Pernin @vladislavpernin Centraliser des logs 21/01/2014

  3. Agenda • Pourquoi • Live coding • Supervision @ERDF •

    Retour d'expérience
  4. Pourquoi • Beaucoup de serveurs • Accès aux machines limité

    ou impossible • Ninja du | sed awk tail cat grep • Simplifier l'accès • Diagnostic • Statistiques / performance
  5. Cible • Système temps réel (1s) • Robuste • Scalable

    • Sans perte • Recherche facile • Complexité limitée
  6. Source Logstash Book Architecture globale

  7. Live coding

  8. Centralisation des logs & supervision @ERDF

  9. Architecture - Supervision

  10. None
  11. Supervision @ERDF

  12. Supervision @ERDF

  13. Supervision @ERDF

  14. Supervision @ERDF

  15. Supervision @ERDF

  16. Supervision @ERDF

  17. Supervision @ERDF

  18. Retour expérience

  19. Logstash Le plus riche fonctionnellement

  20. None
  21. Packaging one jar

  22. Packages officiels deb et RPM depuis fin 2013 fournis par

    elasticsearch
  23. Rapide à mettre en œuvre

  24. Bonne communauté

  25. Encore jeune et mouvant Format des events va/a évolué Fait

    désormais partie d'elasticsearch
  26. Migration vers 1.2.x lourde à effectuer Codec Nouveau schéma JSON

    @fields.maprop -> maprop sélection par type -> conditional
  27. Problème de jeunesse désormais résolu tel que 40s de temps

    de démarrage
  28. Tail intelligent : rotation multi-ligne avec regexp sur début &

    fin détection nouveaux fichiers wildcard et récursif exclusion start_position
  29. Syslog Pratique pour les logs d'appliance

  30. Découpage via grok Pattern custom WEBLOGIC_SERVER ####<%{WLSDATE:date}> <%{WORD:level}> <% {DATA:appender}>

    <%{DATA:hostname}> <%{DATA:servername}> <% {DATA:threadname}> <?(?:<)?%{DATA:subsystem}?(?:>)?> <% {DATA:new_data_1}> <> <%{DATA:datenouse}> <%{DATA:beacode}> <% {WLS_MESSAGE:wlsmessage}>
  31. Très puissant mais pas facilement dégogable regex à optimiser pour

    la performance voir grokdebug.cloudfoundry.com
  32. Tests unitaires/performances sur Grok indispensables

  33. input exec sur des scripts SQL ex : statistiques détaillées

    sur les requêtes SQL Oracle capturées par le Grid
  34. Très extensible (ex : attente correction bug, PR, customisation)

  35. Exemple de customisation : Retry sur la création de la

    river ES Gestion d'une liste de brokers
  36. Option -w nombre de threads des filtres, axe de tuning

    intéressant
  37. if watchdog_timeout then; echo Probleme, sans doute sur les regex

    de Grok fi Process watcher (cron/supervisord) et redémarrage
  38. Le watchdog_timeout peut arriver sur le parsing d'une énorme log

    Exemple : avec un AOPLogger sur les arguments sans limite !
  39. Assez performant mais empreinte CPU importante en charge Rapport gain

    / coût : Ok pour 50-100 lignes/s < 1-5% CPU 2000 lignes/s 150% CPU
  40. Amélioration des performances notable depuis la version 1.2.x

  41. Shipper light, feature -, perf +, jeune, à surveiller Exemple

    : logstash-forwarder (anciennement Lumberjack)
  42. RabbitMQ pas conseillé par le fondateur car « complexité, standard

    mouvant et performance en mode persistant » Conseille redis ou zeromq … persistence, sécurité, installation ... Mon avis : marche très bien avec le lapin dans mon cas
  43. Ok sur Windows

  44. Ko AIX/Solaris Ok avec prochaine version JRuby

  45. Sortie statsd / Graphite Retour arrière chez ERDF car trop

    de complexité, produit hors souche, pas automatisable facilement, api bizarre, besoin/périmètre ?
  46. Un fichier sincedb par type de logs Un filesystem dédié

    … sinon si le FS hôte est plein, Logstash, selon la configuration va relire l'input complet à chaque itération
  47. Job de nettoyage des sincedb car inode recyclés très vite

  48. Appender Spring AMQP Rapide à mettre en œuvre

  49. Mais pas thread safe (correction apportée et remontée)

  50. Nommage des threads à faire Gestion du cycle de vie

    des thread, timer $^*% !
  51. Écriture d'un listener configurable enrichissant une liste d'appender avec des

    appenders AMQP
  52. Queue avec limite de taille / retry avec un offer

    timeout une fois plein … mais pas avec 200 ms d'attente
  53. Overhead négligeable au profiler en sampling en tout cas, pas

    plus que le framework de log
  54. Utilisation d'une surcouche à log4j « maison » hérité d'un

    autre projet du client, une sorte de MDC un peu évolué fait bien le travail … mais sur log4j A minima utilisation de la façade slf4j
  55. A partir de 8 000 messages/s, on tombe sur un

    vieux problème de contention très connu dans log4j ! On ne rencontre pas forcément ce débit là tous les jours
  56. Existe des équivalents Logback mais ne semblent pas packagé et

    plutôt spécifique Simple à faire à la main
  57. RabbitMQ Bel outil

  58. Erlang à compiler sur RHEL car pas de RPM nox

    récent
  59. Bonne documentation

  60. Pas si évident à mettre en œuvre et à paramétrer

    pour un bon fonctionnement en production frame_max,hearbeat,tcp_listen_options inet_dist_listen... disk_free_limit,vm_memory_high_watermark cluster_partition_handling
  61. … comme tout logiciel

  62. Cron forçant la fermeture des connexions si des queues ont

    des messages en attente et pas de consumer
  63. Script de démarrage (/etc/init.d) robuste à écrire pour couvrir tous

    les cas ex : attente du timeout tcp de fin
  64. Cluster et queues distribuées

  65. Intégration aux normes de sécurité de l'entreprise impeccable avec la

    federation pour transport des logs d'une zone réseau à une autre en respectant le sens des flux
  66. Sécurisation user/password et SSL

  67. Dossier d'exploitation à faire Documenter les différents cas d'exploitation connus

  68. Upgrade 2.x → 3.x difficile

  69. Attention à la problématique des nœuds non synchronisés, perte de

    messages possibles, ordre de redémarrage des nœuds et partitions failures Résolu en version 3.1
  70. Performances limitées en mode persistant … 10 000 messages /

    s … suffisant pour mon cas d'usage
  71. Scale moyennement Plus de nœuds == HA Multiplier les queues

    Récentes federated queues … au détriment de la complexité
  72. Empreinte CPU en charge importante

  73. Loadbalancer nécessaire pour une federation vers un cluster

  74. elasticsearch Bel outil

  75. Grande communauté

  76. Documentation … à chercher :)

  77. Reste encore un jeune produit

  78. Log faisant parfois peur (Corrupted...) Tri curieux

  79. Assez performant (5000 stacktraces/s sans tuning) sur un SAN Recherche

    parmi 30 millions lignes de logs en quelques millisecondes
  80. N'a jamais été le goulot d'étranglement en ingestion des logs

  81. Hyper puissant pour stocker, chercher dans les logs en temps

    réel (1s)
  82. Packages officiels deb et RPM depuis fin 2013 fournis par

    elasticsearch
  83. River RabbitMQ très pratique Petit bug de robustesse en cours

    de merge (05/2013) … mais deprecated en 1.0 pas très compliqué à reproduire sous un autre forme
  84. Il faut structurer ses logs pour bénéficier complètement du moteur

  85. Nécessite de savoir comment on va chercher pour savoir comment

    indexer et avec quel mapping
  86. Mapping à mettre au point (montée en compétence indispensable) De

    moins en moins de travail à faire avec les releases récentes à la fois de Logstash et d'elasticsearch
  87. Mapping custom : Compression (par défaut désormais) Élimination de la

    duplication Analyseur custom Élision Type précis Indexation multi field
  88. En cas de nouveau mapping : attendre prochaine rotation d'index

    (jour/semaine) réindexer, possible sans interruption avec des alias
  89. Percolation pour génération d'alerte au fil de l'eau

  90. « nosql » sympa pas si évident

  91. Pas possible de faire des recherches très complexes (join, group

    by multiple, …) Plus ouvert avec le récent module d'agrégation en remplacement des facets dans la 1.0
  92. Facette : très puissant mais attention au scope, les OOM

    viennent vite Doc values pour stockage sur disque
  93. Moteur de recherche : parfois difficile de comprendre les résultats

  94. Message fourni à elasticsearch sans identifiant, génération par es Sauf

    pour certains cas où on peut déduire l'identifiant de la log (Grid Oracle) et updater le document dans es
  95. Couplage version serveur et transport client

  96. Compression efficace : 3 ko / log en entrée →

    1,8 ko en sortie en moyenne
  97. Aucune sécurité iptables Proxy Post 1.0 ou pas

  98. Outillage très limité pour l'instant Backup manuel Attendre 1.0 avec

    snapshot/incrémental backup
  99. Release fréquente Upgrade facile

  100. Haute disponibilité Scalable

  101. Partitioning aisé via le nommage des index Un par semaine

  102. 3 nœuds obligatoires sinon : soit pas de HA soit

    split brain 1 nœud peut être simplement master-only
  103. Paramétrage gateway... et discovery.zen... obligatoire Unicast Attention à la version

    du JDK, 7 mais pas forcément la toute dernière version
  104. Pas plus de la moitié de la RAM pour la

    heap Filter cache à paramétrer Fréquence et pause GC à surveiller Lock HEAP dans la RAM (mlockall) Pas swapper Nombre de CPUs important
  105. ihm IHM originelle de Logstash avait le mérite d'exister

  106. Kibana : php au début, porté Ruby, puis en Bootstrap

    & AngularJS
  107. Multicritère, facetting Dashboard pré configurés et customisables

  108. Ok pour le cas "général"

  109. Dashboard assez avancé (source blog.xebia.fr)

  110. Spécifique

  111. Kibana 3 inexistant au démarrage Intégration avec le framework utilisé

    sur le projet (ZK) pour homogénéité
  112. Maîtrise et customisation complète

  113. Besoin d'intégrer d'autres sources telles que JMX, Spring Batch, DB

    et de faire des corrélations
  114. Recherche multicritère et collant aux cas d'usages principaux Recherche sauvegardée

    avec facetting
  115. Ecran d'accueil type dashboard : est ce que mon système

    est OK
  116. Remarques diverses Fait ressortir tous les défauts des applications (visible

    dans les logs) de manière criante … et aussi ceux des logs eux mêmes
  117. Uniformisation des layout de logs indispensable n formats de date

    à gérer == cauchemar
  118. Multi lignes : plus simple avec délimiteur de début et

    de fin, comme Weblogic Lignes de logs auto porteuses
  119. Génération d'un identifiant de corrélation Suivi à travers toute l'architecture

    des logs relatifs à une même action utilisateur
  120. Enrichissement des messages avec environnement, projet et application pratique

  121. Besoin de superviser la supervision mais attention Cron > fichier_journal

    Job de détection de non réception de logs
  122. Décision de : filtrer (groker) côté agent côté serveur logguer

    directement en json ou json_event (format Logstash)
  123. Débat agent / agentless

  124. Autres pistes rsyslog tail intelligent, wildcard mais pas multiligne …

    en fait si depuis quelques mois mais très limité
  125. Buffer disque AMQP en beta

  126. Version très ancienne sur les distributions Pas possible d'en installer

    une plus récente
  127. syslog-ng : pas multiligne, ni wildcard sauf dans version premium

    Destination AMPQ pas disponible en premium
  128. syslog-ng : API pas si simple

  129. syslog-ng : fichier de persist (équivalent sincedb) non modulaire

  130. syslog-ng : buffer de sortie, lorsqu'il est plein, drop silencieusement

    les logs même si l'input est un fichier, on pourrait arrêter le tail
  131. syslog-ng : buffer persistant avec premium

  132. syslog-ng : logs avec apache tee -a | logger +

    rotation logrotate / apachectl graceful
  133. flume : réécrit en flume-ng

  134. flume : très performant, empreinte CPU modéré

  135. flume : pas (plus) de tail

  136. flume : cluster Hadoop sous la main

  137. flume : stockage HDFS

  138. flume : recherche immédiate dans Hadoop pas évidente … pas

    encore … intéractive déjà possible
  139. flume : Hadoop ops pas simple

  140. Piste intéressante : sink flume avec un split sur elasticsearch

    et HDFS/HBase ou en écoute de HDFS/HBase
  141. Graylog2 • installation ! (ruby, gem …), full Java dernière

    version . • spécifique GELF • Logback en GELF • mongodb nécessaire • mapping figé ? • un seul index (max … récemment) • analitycs idem que Kibana
  142. Heka (Mozilla) • 1ere annonce avril 2013 • inspiré de

    Logstash • Go (performant) • plugin • input/output limité (jeune) • module es depuis l'été 2013 by @tlrx • à surveiller
  143. Autres : • Spring XD avec des flux en |

    • Morphlines de Cloudera • Zlogd de Zumba • Utiliser Solr (Logsene@sematext)
  144. Splunk • très puissant • bien intégré • indexation brute

    • reporting sexy • corrélation / alerte • écosystème C et python • plugin by Splunk ou communauté • pas extensible / intégrable • très cher, ex : 4Go/j = 300 000€
  145. Solutions en mode SAAS • Loggly, New Relic, Papertrail, Logentries

    • ok/nécessaire pour application déjà dans le cloud • non maîtrise • flux extérieur • RSSI pas content • coût assez obscur
  146. ... Logo ici

  147. Apache Kafka • transport des logs • pour les plateformes

    à très forte charge • throughput impressionnant • > 20 000/s en production et > 200 000/s en consommation sur un portable • scalabilité horizontale • nativement persistant • ok dans un écosystème bigdata
  148. Performance Vitesse de lecture d'un fichier par Logstash Vitesse de

    traitement par Logstash Vitesse d'indexation par elasticsearch sur un PC portable avec des access log Apache
  149. Quelques chiffres ERDF 2 - 3 mois de logs pour

    8-10 env = 25 Go d'index elasticsearch capacité de traitement de 800m/s avec deux serveurs (RabbitMQ, Logstash, elasticsearch) 4000 logs/s pendant les rattrapages un test de performance aux limites de 40 min = 1 000 000 logs
  150. Pour finir Jeunesse relative des produits Problèmes d'intégration (contournés) Introduction

    de nouvelles technologies nécessaire (apprentissage, maîtrise, complexité) Overhead, très limité (Logstash et appender 10- 100ms) et rapport gain/perte OK
  151. Pour finir Automatisation d'installation multi environnements/projets/topologies réussie mais longue Des

    cookbooks chef, modules Puppet, Ansible, deb, RPM existent … si ils correspondent à votre environnement Architecture à scaler pour très grande volumétrie En plein mouvement
  152. Pour finir En plein mouvement Support éditeur désormais possible Beaucoup

    de ressources/documentation de qualité, pas le cas il y a deux ans
  153. Pour finir Centralisation des logs de plusieurs environnements et projets

    Temps de diagnostic des problèmes et des tests de performance réduit drastiquement Développeurs & SNx autonomes
  154. Pour finir Visibilité sur le système, son état Transparence sur

    la qualité « visible depuis les logs » Corrélation à travers toute l'architecture, top 10 erreurs, ... Recherche de reproductibilité de bug facile Statistiques diverses ...
  155. Merci

  156. Questions ?