Lyon elasticsearch meetup - centralisation de logs @erdf 2015/03

Transcript

1. Vladislav Pernin @vladislavpernin Claire Villard Centraliser des logs 24/02/2015
2. Agenda • Pourquoi • Architecture • Supervision @ERDF • Retour d'expérience
3. 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
4. Cible • Système temps réel (1s) • Robuste • Scalable • Sans perte • Recherche facile • Complexité limitée
5. Architecture globale
6. 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
7. Architecture physique … au début
8. Architecture physique … ensuite
9. Architecture physique … maintenant
10. Quelques chiffres ERDF 7 projets, 45 environnements du DEV à la PROD, 600 serveurs clients Répartis entre 12 environnements 4 "PROD" : zones réseau différentes et environnements projets
11. Quelques chiffres ERDF - Production 680M de documents 232Go (464Go avec la réplication) 40 index Index le plus gros : 126 560 706 documents pour 41.8Go 2 shards et 1 replica
12. Quelques chiffres ERDF - Production Une dizaine de queue 230 msg/s en moyenne 2.000 msg/s en pic consommés sans prendre de retard
13. Quelques chiffres ERDF - Production IHM journée type : 10 000 requêtes/j (moyenne 7 requêtes/m) dont 25% via une API REST 178 comptes utilisateurs
14. Quelques chiffres ERDF - Projet elasticsearch : 121M de documents / 68 Go / 37 index rabbitmq : 100m/s, pic à 8000m/s consommés avec du retard … et des problèmes IHM : 15 000 requêtes/j 210 comptes utilisateurs
15. Centralisation des logs & supervision (par les logs) @ERDF
16. Supervision @ERDF
17. Supervision @ERDF
18. Supervision @ERDF
19. Supervision @ERDF
20. Supervision @ERDF
21. Supervision @ERDF
22. Supervision @ERDF
23. Retour expérience
24. Logstash Le plus riche fonctionnellement
27. Packaging tar.gz
28. Packages officiels deb, RPM et docker
29. Rapide à mettre en œuvre
30. Bonne communauté
31. Encore jeune et mouvant Rétro compatibilité non assurée Fait désormais partie d'elasticsearch
32. Migration vers 1.2.x lourde à effectuer Codec Nouveau schéma JSON @fields.maprop -> maprop sélection par type -> conditional
33. Migration vers 1.5 Externalisation des plugins Gem … offline ?
34. Problème de jeunesse désormais résolu tel que 40s de temps de démarrage
35. Tail intelligent : rotation multi-ligne avec regexp sur début & fin détection nouveaux fichiers wildcard et récursif exclusion start_position
36. Syslog Pratique pour les logs d'appliance
37. 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}>
38. Très puissant mais pas facilement débogable regex à optimiser pour la performance voir grokdebug.cloudfoundry.com
39. Tests unitaires/performances sur Grok indispensables
40. Tests rspec #test case 4 sample({"type" => "log4erdf-fonctionnel", "message" => "20121128-11:27:51.903|INFO|XXXXX|application|version|appender|XX-PERF- TX=perftx#UTI_T_LOGIN=loginid#DOR_ID=dorid#Id_correlation=idcorrelation#UTI_ID=loginname| class#method#arguments|stracktrace|"}) do #Test insist { subject["date"] } == "20121128-11:27:51.903" insist { subject["level"] } == "INFO" insist { subject["hostname"] } == "XXXXX" insist { subject["application"] } == "application" insist { subject["version"] } == "version" ... reject { subject["tags"] } == "_grokparsefailure" end
41. input exec sur des scripts SQL/shell ex : statistiques détaillées sur les requêtes SQL Oracle capturées par le Grid
42. Très extensible (ex : attente correction bug, PR, customisation)
43. Exemple de customisation : Retry sur la création de la river ES Gestion d'une liste de brokers
44. Option -w nombre de threads des filtres, axe de tuning intéressant
45. if watchdog_timeout then; echo Probleme, sans doute sur les regex de Grok fi Process watcher (cron/supervisord) et redémarrage
46. Le watchdog_timeout peut arriver sur le parsing d'une énorme log Exemple : avec un AOPLogger sur les arguments sans limite ! log en debug avec un gros XML
47. 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
48. Amélioration des performances notable depuis la version 1.2.x
49. Shipper light, feature -, perf +, jeune, à surveiller Exemple : logstash-forwarder (anciennement Lumberjack)
50. RabbitMQ pas conseillé par le fondateur car « complexité, standard mouvant et performance en mode persistant » Conseille redis ou zeromq … persistence, sécurité, installation ... Notre avis : marche très bien avec le lapin jusqu'à des volumétries moyennes (<5000/s)
51. Perte de logs conséquentes en sortie vers RabbitMQ en charge sur les versions < 1.4
52. Ok sur Windows avec la version 1.5
53. Ko AIX/Solaris Ok avec prochaine version JRuby ?
54. Sortie statsd / Graphite Retour arrière chez ERDF car trop de complexité, produit hors souche, pas automatisable facilement, api bizarre, besoin/périmètre ?
55. 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
56. Job de nettoyage des sincedb car inode recyclés très vite
57. désactivation de invokedynamic dans JRuby sinon : -Djruby.compile.invokedynamic=false
58. Appender Spring AMQP Rapide à mettre en œuvre
59. Mais pas thread safe (correction apportée et remontée)
60. Nommage des threads à faire Gestion du cycle de vie des thread, timer $^*% !
61. Problème si RabbitMQ a déclenché son disk watermark, le client Java RabbitMQ, à l'arrêt est bloqué dans un appel com.rabbitmq.utility.BlockingValueOrException.uninterruptibleGetValue Idem si le mot de passe est incorrect Egalement deadlock possible à l'arrêt des applis si des messages restent à envoyer à la destruction des appenders
62. Écriture d'un listener configurable enrichissant une liste d'appender avec des appenders AMQP Configuration du framework de log reste indépendante de la solution de centralisation de logs
63. Queue avec limite de taille / retry avec un offer timeout une fois plein … mais pas avec 200 ms d'attente
64. Overhead négligeable au profiler en sampling en tout cas, pas plus que le framework de log
65. 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 log4j 2 prévu (LMAX Disruptor)
66. 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
67. Existe des équivalents Logback mais ne semblent pas packagé et plutôt spécifique Simple à faire à la main
68. RabbitMQ Bel outil
69. Erlang à compiler sur RHEL car pas de RPM nox récent Un paquet est sorti il y deux mois (à tester)
70. Bonne documentation
71. Fonctionne tout de suite
72. 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
73. … comme tout logiciel
74. Cron forçant la fermeture des connexions si des queues ont des messages en attente et pas de consumer
75. Script de démarrage (/etc/init.d) robuste à écrire pour couvrir tous les cas ex : attente du timeout tcp de fin
76. Cluster et queues distribuées
77. 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
78. Sécurisation user/password et SSL
79. Dossier d'exploitation à faire Documenter les différents cas d'exploitation connus
80. Upgrade 2.x → 3.x difficile Upgrade 3.x -> 3.x+n OK
81. 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 Mais très lent
82. Performances limitées en mode persistant et répliqué … 3 000 messages / s 6 000 / s sans la persistance Suffisant pour notre cas d'usage (il y a 2 ans)
83. Scale moyennement Plus de nœuds et répartition manuelle Multiplier les queues
84. Récentes federated queues ou plugin de routage en consistent hashing sur différentes queues … au détriment de la complexité
85. Empreinte CPU en charge importante De préférence sur des serveurs dédiés
86. Loadbalancer nécessaire pour une federation vers un cluster
87. elasticsearch Bel outil
88. Grande communauté
89. Documentation … à chercher :) En progrès
90. Produit devenu mature
91. Log faisant parfois peur (Corrupted...) Tri curieux
92. Assez performant (5000 stacktraces/s sans tuning) sur un SAN Recherche parmi 30 millions lignes de logs en quelques millisecondes
93. N'a jamais été le goulot d'étranglement en ingestion des logs
94. Hyper puissant pour stocker, chercher dans les logs en temps réel (1s)
95. Packages officiels deb, RPM et docker
96. River RabbitMQ très pratique Problèmes de robustesse reconnexion résolu OOM avec le queuing consumer Singleton cluster wide Scale pas
97. … mais les rivers sont deprecated et supprimées en 1.5 pas très compliqué à reproduire sous un autre forme elasticsearch-gatherer à surveiller
98. Il faut structurer ses logs pour bénéficier complètement du moteur
99. Nécessite de savoir comment on va chercher pour savoir comment indexer et avec quel mapping
100. 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
101. Mapping custom : Compression (par défaut désormais) Élimination de la duplication Analyseur custom Élision Type précis Indexation multi field
102. En cas de nouveau mapping : attendre prochaine rotation d'index (jour/semaine) réindexer, possible sans interruption avec des alias
103. Percolation possible pour génération d'alertes au fil de l'eau
104. « nosql » sympa pas si évident
105. 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 depuis la 1.0
106. Facette : très puissant mais attention au scope, les OOM viennent vite Doc values pour stockage sur disque Circuit breaker (> 1.4)
107. Moteur de recherche : parfois difficile de comprendre les résultats
108. 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
109. Requêtage possible très puissant
110. Exemple (extrait) de query de filtre !(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:) )
111. Couplage version serveur et transport client
112. Compression efficace : 70 % entre les logs en entrée et la taille des documents
113. Aucune sécurité iptables proxy Shield est désormais là (commercial)
114. Outillage très limité Curator Marvel (commercial) Snapshot / incrémental backup
115. Release fréquente Upgrade facile
116. Haute disponibilité Scalable
117. Partitioning aisé via le nommage des index Un par semaine 2 shards par index Volume de documents pas forcément prévisible / sharding par simple
118. 3 nœuds obligatoires sinon : soit pas de HA soit split brain 1 nœud peut être simplement master-only
119. Paramétrage gateway... et discovery.zen... obligatoire Unicast Attention à la version du JDK, 7 mais pas forcément la toute dernière version Pas de G1
120. Pas plus de la moitié de la RAM pour la heap Fréquence et pause GC à surveiller Lock HEAP dans la RAM (mlockall) Pas swapper Nombre de CPUs important
121. ihm IHM originelle de Logstash avait le mérite d'exister
122. Kibana : php au début, porté Ruby, puis en Bootstrap & AngularJS
123. Multicritère, facetting Dashboard pré configurés et customisables
124. Ok pour le cas "général"
125. Dashboard assez avancé (source blog.xebia.fr)
126. Spécifique
127. Kibana 3 (4 maintenant) inexistant au démarrage Intégration avec le framework utilisé sur le projet pour homogénéité
128. Maîtrise et customisation complète
129. Besoin d'intégrer d'autres sources telles que JMX, Spring Batch, DB et de faire des corrélations
130. Recherche multicritère et collant aux cas d'usages principaux Recherche sauvegardée avec facetting
131. Ecran d'accueil type dashboard : est ce que mon système est OK
132. 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
133. Uniformisation des layout de logs indispensable n formats de date à gérer == cauchemar
134. Multi lignes : plus simple avec délimiteur de début et de fin, comme Weblogic Lignes de logs auto porteuses
135. Génération d'un identifiant de corrélation Suivi à travers toute l'architecture des logs relatifs à une même action utilisateur
136. Enrichissement des messages avec environnement, projet et application pratique
137. Besoin de superviser la supervision mais attention Cron > fichier_journal Job de détection de non réception de logs
138. Décision de : filtrer (groker) côté agent côté serveur logguer directement en json ou json_event (format Logstash)
139. Logguer sur fichier puis Logstash Envoyer directement au broker
140. Débat agent / agentless
141. Autres pistes rsyslog (multiligne limité, AMQP beta, versions anciennes) syslog-ng (pas multiligne, ni wildcard, ni buffer persistant sauf dans version premium, AMPQ pas en premium, API ..., 1 fichier persist, buffer sortie …) flume / hadoop (pas de tail, Hadoop, intéractif ..., ops …) Piste intéressante : sink Flume avec un split sur elasticsearch et HDFS/HBase ou écoute de HDFS/HBase ou elasticsearch-hadoop Graylog2 (ruby gem …, Java dernière version, GELF spécifique, mongodb, mapping, 1 index)
142. Autres pistes Heka (Mozilla, à surveiller) Spring XD avec des flux en | Morphlines de Cloudera / Zlogd de Zumba / Utiliser Solr (Logsene@sematext) Splunk (puissant, bien intégré, indexation brute, reporting, corrélation / alerte, C et python, plugin, pas extensible / intégrable, très cher) PAAS (Loggly, New Relic, Papertrail, Logentries / ok/nécessaire dans le cloud, RSSI pas content, coût assez obscur)
143. ... Logo ici
144. 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 • API consommation pas simple
145. 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 RabbitMQ a montre ses limites
146. 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
147. Pour finir En plein mouvement Support éditeur désormais possible Beaucoup de ressources/documentation de qualité, pas le cas il y a deux ans
148. 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 Devenu un des outils le plus utilisé chez ERDF
149. 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 ...
150. Merci
151. Questions ?