Your SlideShare is downloading. ×
  • Like
Nantes JUG - Traçabilité dans une architecture distribuée avec Node.js et MongoDB
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Nantes JUG - Traçabilité dans une architecture distribuée avec Node.js et MongoDB

  • 951 views
Published

Les architectures distribuées soulèvent un certains nombre de problématiques en terme de traçabilité : détection des anomalies, suivi des utilisateurs, mesure des performances des différents services …

Les architectures distribuées soulèvent un certains nombre de problématiques en terme de traçabilité : détection des anomalies, suivi des utilisateurs, mesure des performances des différents services … Durant cette session, nous vous montrerons - démonstration à l'appui - comment nous avons apporté une solution simple à ces problématiques, en mettant en place un système de consolidation de logs avec Node.js et MongoDb.

Nantes JUG - mars 2013 - http://www.nantesjug.org

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
951
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Jérôme Creignou - @jcreignouSébastien Prunier - @sebprunier
  • 2. Application Application Application ESB ESB ESB ESB Controler Rules ControlerService [R] Service [R] Service [W] Legacy Service [W] Mainframe SGBDR
  • 3. Load Balancer Cluster 1 Cluster 2 Service A Service AService A Service A Service A Service A
  • 4. Application load bal. cluster clusterESB ESB ESB ESB load bal. cluster clusterServ. Serv. Serv. Serv. SGBDR
  • 5. Application load bal. cluster clusterESB ESB ESB ESB load bal. cluster clusterServ. Serv. Serv. Serv. SGBDR
  • 6. Application load bal. cluster clusterESB ESB ESB ESB load bal. cluster cluster Serv. Serv. Serv. SGBDR
  • 7. Application load bal. cluster clusterESB ESB ESB ESB load bal. cluster clusterServ. Serv. Serv. Serv. SGBDR
  • 8. SGBDRorg.apache.log4j.jdbc.JDBCAppender
  • 9.  CREATE TABLE ALL_LOGS (DATA BLOB) « On va abstraire la notion de log, créer un schéma pivot, des convertisseurs et … »
  • 10. * Log  Logarithme  John Neper  NepR
  • 11. Outil permettant de consolider un ensemble de traces (logs) techniqueset applicatives et de les restituer selon plusieurs axes d’analyse.
  • 12. 1 Loguer dans des fichiers Log File org.apache.log4j.FileAppender  Données brutes
  • 13. 1 Que logue-t-on ? ◦ Horodatage ◦ Id unique de requête (RequestID) ◦ User ◦ Service et opération exécutée ◦ Machine, nœud du cluster ◦ Couche applicative ◦ Environnement (dev, re7, prod …) ◦ Temps d’exécution ◦ En cas d’erreur  Code d’erreur  Message  Stacktrace
  • 14. 1 RequestID ◦ ID unique généré pour chaque action utilisateur ◦ Transporté de couche en couche ◦ Permet de reconstruire l’enchaînement des services-Xrequestid=123456789 <soap:Header> <traces> <requestid>123456789</requestid> </traces> </soap:Header>
  • 15. 2 Loguer au plus proche de l’environnement d’exécution Log File Log File Log File  La perte d’informations est limitée
  • 16. 3 Consolider de manière asynchrone Log File Log File  Les performances ne sont pas impactées
  • 17. 4 Stocker de l’information structurée { ts : "2013-03-18…" , Log user : "johndoe", File service : "xxxxx", op : "abcdef", elapsed : "154" }  L’exploitation des informations est facilitée
  • 18. 5 Ne pas oublier de purger !  Les données brutes & les données consolidées
  • 19. nepr Log nepr console File agent Log neprFile File agent nepr server Log nepr File agent Log nepr nepr File agent db Objet « trace » Objet « perf » Objet « anomalie »
  • 20.  Nepr agent & server : NodeJS ◦ Processus légers ◦ Simplicité de mise en œuvre ◦ Données structurées JSON Nepr db : MongoDB ◦ Stockage de données hétérogènes (schema less) ◦ Gros volumes de données en écriture ◦ L’ « eventual consistency » n’est pas un problème ◦ Stockage JSON
  • 21.  REST API ◦ POST  /data/:env/:couche/:machine ◦ GET  /perfs/:env/:service/:operation  /errors/:env/:service/:operation  /traces/:env/:requestid  /stats/:env/:service/:operation
  • 22.  Map Reduce var mapFn = function () { emit({ service: this.service, operation: this.operation, couche: this.couche }, { count: 1, elapsed: this.elapsed });}; var reduceFn = function (key, values) { var result = { count: 0, elapsed: 0 }; values.forEach(function (val) { result.count += val.count; result.elapsed += val.elapsed; }); return result; };
  • 23.  Extraction de logs significatifs via des regexp^ INFO|([0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2},[0-9]{3})|([^|]*)|([^|]*)|([^|]*)|([^|]*)|([^|]*) TIME-USED;(d*);0;0;  Envoi de données structurées au serveur { type:perf, date:todate(m[1]), userid:m[2], sessionid:m[3], requestid:m[4], service:m[5], operation:m[6], elapsed:parseInt(m[7]) }
  • 24.  Configurations centralisées sur le serveur nepr agent GET /conf/:env/ nepr server Mise à jour via « svn update » / « git pull »
  • 25.  Démonstration !