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

Transcript

1. Vladislav Pernin @vladislavpernin
   Claire Villard
   Centraliser des logs
   24/02/2015
   

   View Slide

2. Agenda
   ●
   Pourquoi
   ●
   Architecture
   ●
   Supervision @ERDF
   ●
   Retour d'expérience
   

   View Slide

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
   

   View Slide

4. Cible
   ●
   Système temps réel (1s)
   ●
   Robuste
   ●
   Scalable
   ●
   Sans perte
   ●
   Recherche facile
   ●
   Complexité limitée
   

   View Slide

5. Architecture globale
   

   View Slide

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
   

   View Slide

7. Architecture physique …
   au début
   

   View Slide

8. Architecture physique …
   ensuite
   

   View Slide

9. Architecture physique …
   maintenant
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

15. Centralisation des logs
    & supervision (par les logs)
    @ERDF
    

    View Slide

16. Supervision @ERDF
    

    View Slide

17. Supervision @ERDF
    

    View Slide

18. Supervision @ERDF
    

    View Slide

19. Supervision @ERDF
    

    View Slide

20. Supervision @ERDF
    

    View Slide

21. Supervision @ERDF
    

    View Slide

22. Supervision @ERDF
    

    View Slide

23. Retour expérience
    

    View Slide

24. Logstash
    Le plus riche fonctionnellement
    

    View Slide

25. View Slide

26. View Slide

27. Packaging tar.gz
    

    View Slide

28. Packages officiels deb, RPM et docker
    

    View Slide

29. Rapide à mettre en œuvre
    

    View Slide

30. Bonne communauté
    

    View Slide

31. Encore jeune et mouvant
    Rétro compatibilité non assurée
    Fait désormais partie d'elasticsearch
    

    View Slide

32. Migration vers 1.2.x lourde à effectuer
    Codec
    Nouveau schéma JSON
    @fields.maprop -> maprop
    sélection par type -> conditional
    

    View Slide

33. Migration vers 1.5
    Externalisation des plugins
    Gem … offline ?
    

    View Slide

34. Problème de jeunesse désormais
    résolu tel que 40s de temps de
    démarrage
    

    View Slide

35. Tail intelligent :
    rotation
    multi-ligne avec regexp sur début &
    fin
    détection nouveaux fichiers
    wildcard et récursif
    exclusion
    start_position
    

    View Slide

36. Syslog
    Pratique pour les logs d'appliance
    

    View Slide

37. Découpage via grok
    Pattern custom
    WEBLOGIC_SERVER #### {DATA:appender}> {DATA:threadname}> (?:)?> {DATA:new_data_1}> <>
    
    

    View Slide

38. Très puissant mais pas facilement
    débogable
    regex à optimiser pour la
    performance
    voir grokdebug.cloudfoundry.com
    

    View Slide

39. Tests unitaires/performances
    sur Grok indispensables
    

    View Slide

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
    

    View Slide

41. input exec sur des scripts
    SQL/shell
    ex : statistiques détaillées sur les
    requêtes SQL Oracle capturées
    par le Grid
    

    View Slide

42. Très extensible (ex : attente
    correction bug, PR,
    customisation)
    

    View Slide

43. Exemple de customisation :
    Retry sur la création de la river
    ES
    Gestion d'une liste de brokers
    

    View Slide

44. Option -w nombre de threads des
    filtres, axe de tuning intéressant
    

    View Slide

45. if watchdog_timeout then;
    echo Probleme, sans doute
    sur les regex de Grok
    fi
    Process watcher (cron/supervisord)
    et redémarrage
    

    View Slide

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
    

    View Slide

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
    

    View Slide

48. Amélioration des performances
    notable depuis la version 1.2.x
    

    View Slide

49. Shipper light, feature -, perf +, jeune,
    à surveiller
    Exemple : logstash-forwarder
    (anciennement Lumberjack)
    

    View Slide

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)
    

    View Slide

51. Perte de logs conséquentes en sortie vers
    RabbitMQ en charge sur les versions < 1.4
    

    View Slide

52. Ok sur Windows avec
    la version 1.5
    

    View Slide

53. Ko AIX/Solaris
    Ok avec prochaine version
    JRuby ?
    

    View Slide

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 ?
    

    View Slide

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
    

    View Slide

56. Job de nettoyage des sincedb
    car inode recyclés très vite
    

    View Slide

57. désactivation de invokedynamic dans
    JRuby sinon :
    -Djruby.compile.invokedynamic=false
    

    View Slide

58. Appender Spring AMQP
    Rapide à mettre en œuvre
    

    View Slide

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

    View Slide

60. Nommage des threads à faire
    Gestion du cycle de vie des thread,
    timer $^*% !
    

    View Slide

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
    

    View Slide

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
    

    View Slide

63. Queue avec limite de taille / retry
    avec un offer timeout une fois
    plein
    … mais pas avec 200 ms
    d'attente
    

    View Slide

64. Overhead négligeable au profiler
    en sampling
    en tout cas, pas plus que le
    framework de log
    

    View Slide

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)
    

    View Slide

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
    

    View Slide

67. Existe des équivalents Logback mais
    ne semblent pas packagé et plutôt
    spécifique
    Simple à faire à la main
    

    View Slide

68. RabbitMQ
    Bel outil
    

    View Slide

69. Erlang à compiler sur RHEL car pas de
    RPM nox récent
    Un paquet est sorti il y deux mois (à
    tester)
    

    View Slide

70. Bonne documentation
    

    View Slide

71. Fonctionne tout de suite
    

    View Slide

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
    

    View Slide

73. … comme tout logiciel
    

    View Slide

74. Cron forçant la fermeture des connexions
    si des queues ont des messages en
    attente et pas de consumer
    

    View Slide

75. Script de démarrage (/etc/init.d)
    robuste à écrire pour couvrir tous les
    cas
    ex : attente du timeout tcp de fin
    

    View Slide

76. Cluster et queues distribuées
    

    View Slide

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
    

    View Slide

78. Sécurisation user/password et SSL
    

    View Slide

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

    View Slide

80. Upgrade 2.x → 3.x difficile
    Upgrade 3.x -> 3.x+n OK
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

83. Scale moyennement
    Plus de nœuds et répartition manuelle
    Multiplier les queues
    

    View Slide

84. Récentes federated queues
    ou plugin de routage en consistent
    hashing sur différentes queues
    … au détriment de la complexité
    

    View Slide

85. Empreinte CPU en charge importante
    De préférence sur des serveurs dédiés
    

    View Slide

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

    View Slide

87. elasticsearch
    Bel outil
    

    View Slide

88. Grande communauté
    

    View Slide

89. Documentation … à chercher :)
    En progrès
    

    View Slide

90. Produit devenu mature
    

    View Slide

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

    View Slide

92. Assez performant (5000 stacktraces/s
    sans tuning) sur un SAN
    Recherche parmi 30 millions lignes de
    logs en quelques millisecondes
    

    View Slide

93. N'a jamais été le goulot
    d'étranglement en ingestion des
    logs
    

    View Slide

94. Hyper puissant pour stocker, chercher
    dans les logs en temps réel (1s)
    

    View Slide

95. Packages officiels deb, RPM et docker
    

    View Slide

96. River RabbitMQ très pratique
    Problèmes de robustesse
    reconnexion résolu
    OOM avec le queuing consumer
    Singleton cluster wide
    Scale pas
    

    View Slide

97. … mais les rivers sont deprecated et
    supprimées en 1.5
    pas très compliqué à reproduire sous
    un autre forme
    elasticsearch-gatherer à surveiller
    

    View Slide

98. Il faut structurer ses logs pour
    bénéficier complètement du moteur
    

    View Slide

99. Nécessite de savoir comment on va
    chercher pour savoir comment
    indexer et avec quel mapping
    

    View Slide

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
     

     View Slide

101. Mapping custom :
     Compression (par défaut désormais)
     Élimination de la duplication
     Analyseur custom
     Élision
     Type précis
     Indexation multi field
     

     View Slide

102. En cas de nouveau mapping :
     attendre prochaine rotation d'index
     (jour/semaine)
     réindexer, possible sans
     interruption avec des alias
     

     View Slide

103. Percolation possible pour génération
     d'alertes au fil de l'eau
     

     View Slide

104. « nosql » sympa pas si évident
     

     View Slide

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
     

     View Slide

106. Facette : très puissant mais attention
     au scope, les OOM viennent vite
     Doc values pour stockage sur disque
     Circuit breaker (> 1.4)
     

     View Slide

107. Moteur de recherche : parfois difficile
     de comprendre les résultats
     

     View Slide

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
     

     View Slide

109. Requêtage possible très puissant
     

     View Slide

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:)
     )
     

     View Slide

111. Couplage version serveur
     et transport client
     

     View Slide

112. Compression efficace : 70 % entre les
     logs en entrée et la taille des
     documents
     

     View Slide

113. Aucune sécurité
     iptables
     proxy
     Shield est désormais là
     (commercial)
     

     View Slide

114. Outillage très limité
     Curator
     Marvel (commercial)
     Snapshot / incrémental backup
     

     View Slide

115. Release fréquente
     Upgrade facile
     

     View Slide

116. Haute disponibilité
     Scalable
     

     View Slide

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
     

     View Slide

118. 3 nœuds obligatoires sinon :
     soit pas de HA
     soit split brain
     1 nœud peut être simplement master-only
     

     View Slide

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
     

     View Slide

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
     

     View Slide

121. ihm
     IHM originelle de Logstash avait le
     mérite d'exister
     

     View Slide

122. Kibana : php au début, porté Ruby,
     puis en Bootstrap & AngularJS
     

     View Slide

123. Multicritère, facetting
     Dashboard pré configurés et
     customisables
     

     View Slide

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

     View Slide

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

     View Slide

126. Spécifique
     

     View Slide

127. Kibana 3 (4 maintenant) inexistant au
     démarrage
     Intégration avec le framework utilisé
     sur le projet pour homogénéité
     

     View Slide

128. Maîtrise et customisation complète
     

     View Slide

129. Besoin d'intégrer d'autres sources
     telles que JMX, Spring Batch, DB
     et de faire des corrélations
     

     View Slide

130. Recherche multicritère et collant aux
     cas d'usages principaux
     Recherche sauvegardée avec facetting
     

     View Slide

131. Ecran d'accueil type dashboard : est ce
     que mon système est OK
     

     View Slide

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
     

     View Slide

133. Uniformisation des layout de logs
     indispensable
     n formats de date à gérer == cauchemar
     

     View Slide

134. Multi lignes : plus simple avec délimiteur
     de début et de fin, comme Weblogic
     Lignes de logs auto porteuses
     

     View Slide

135. Génération d'un identifiant de corrélation
     Suivi à travers toute l'architecture des logs
     relatifs à une même action utilisateur
     

     View Slide

136. Enrichissement des messages avec
     environnement, projet et application
     pratique
     

     View Slide

137. Besoin de superviser la supervision
     mais attention
     Cron > fichier_journal
     Job de détection de non réception de
     logs
     

     View Slide

138. Décision de :
     filtrer (groker) côté agent
     côté serveur
     logguer directement en json ou
     json_event (format Logstash)
     

     View Slide

139. Logguer sur fichier puis Logstash
     Envoyer directement au broker
     

     View Slide

140. Débat agent / agentless
     

     View Slide

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)
     

     View Slide

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)
     

     View Slide

143. ...
     Logo ici
     

     View Slide

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
     

     View Slide

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
     

     View Slide

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
     

     View Slide

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
     

     View Slide

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
     

     View Slide

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

     View Slide

150. Merci
     

     View Slide

151. Questions ?
     

     View Slide