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

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

Edc84722f6c279f6a3ef1584fc03acff?s=47 Vladislav Pernin
March 25, 2015
260

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

Edc84722f6c279f6a3ef1584fc03acff?s=128

Vladislav Pernin

March 25, 2015
Tweet

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

  25. None
  26. None
  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 ?