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.

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
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
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 ?