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. Poitou Charentes JUG - mai 2013 - http://www.poitoucharentesjug.org

1. Traçabilité dans une
architecture distribuée
avec Node.js et MongoDB
[@jcreignou] Jérôme Creignou
[@sebprunier] Sébastien Prunier

2. Architecture
Application Application Application
ESB ESB ESBESB
Service
SGBDR
Service
Rules
Service Service
Composite
Service
Composite
Service
Legacy
Mainframe

3. Infrastructure
Load Balancer
Cluster 1
Service A
Service A
Service A
Cluster 2
Service A
Service A
Service A

4. Architecture &
Infrastructure
App SGBDRL. B. L. B.
A
A
A
A
B
B
B
B
C
1.1
C
1.2
C
2.1
C
2.2

5. Notre mission

6. Objectif 1

7. Traçabilité !
App SGBDRL. B. L. B.
A
A
A
A
B
B
B
B
C
1.1
C
1.2
C
2.1
C
2.2

8. Objectif 2

9. Détection d'anomalies
App SGBDRL. B. L. B.
A
A
A
A
B
B
B
B
C
1.1
C
1.2
C
2.1
C
2.2

10. Objectif 3

11. Mesure des performances !
App SGBDRL. B. L. B.
A
A
A
A
B
B
B
B
C
1.1
C
1.2
C
2.1
C
2.2

12. Vous avez 15 jours !
KISS(Keep It Short and Simple)
(Keep It Simple Stupid)
(... *)
* http://fr.wikipedia.org/wiki/Principe_KISS

13. Conseil (Xebia Essentials)

14. FBI (Fausse Bonne Idée)
org.apache.log4j.jdbc.JDBCAppender
SGBDR

15. FBI (Fausse Bonne Idée)
● CREATE TABLE ALL_LOGS (DATA BLOB)
INEXPLOITABLE !
● « On va abstraire la notion de log, créer un
schéma pivot, des convertisseurs et … »
PAS EVOLUTIF !

16. Notre solution
John Napier, en France Neper,
théologien, physicien, astronome et
mathématicien écossais.
Log ~ Logarithme
-> John Neper ~ NepR

17. NepR
Outil permettant de consolider un
ensemble de traces (logs) techniques
et applicatives et de les restituer selon
plusieurs axes d’analyse.

18. Bonne pratique 1
● Logguer dans des fichiers
○ org.apache.log4j.FileAppender
Log
File
Les données tracées sont brutes, non transformées

19. Bonne pratique 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

20. Bonne pratique 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>
HTTP
SOAP

21. Bonne pratique 2
● Loguer au plus proche de l’environnement d’
exécution
La perte d'information est limitée
Log
File
Log
File
Log
File

22. Bonne pratique 3
● Consolider de manière asynchrone
Les performances ne sont pas impactées
Log
File
Log
File
Serveur de
consolidation

23. Bonne pratique 4
● Stocker de l’information structurée
L'exploitation des informations est facilitée
Log
File
Serveur de
consolidation
{
ts : "2013-03-18…" ,
user : "johndoe",
service : "xxxxx",
op : "abcdef",
elapsed : "154"
}

24. Bonne pratique 5
● Ne pas oublier de purger !
Le cycle de vie des données est maîtrisé

25. Solution technique
Log
File
Log
File
Log
File
Log
File
nepr
agent
nepr
agent
nepr
agent
nepr
agent
Log
File
nepr
console
nepr
server
nepr
db
document trace
document perf
document anomalie

26. Choix technologiques
● 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

27. nepr-server
● REST API
○ POST
■ /data/:env/:couche/:machine
○ GET
■ /perfs/:env/:service/:operation
■ /errors/:env/:service/:operation
■ /traces/:env/:requestid
■ /stats/:env/:service/:operation

28. nepr-server
● 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;
};

29. nepr-agent
● Extraction de logs significatives via des
regexps
● 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], 10)
}
^ 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

30. nepr-agent
● Configurations centralisées sur le serveur
● Mise à jour via "svn update"
GET /conf/:env/
Log
File
nepr
agent
nepr
server
Log
FileLog
FileLog
FileLog
File
?
??

31. nepr-console
● Démonstration !

32. Bilan de la version 1
● Le POC est réussi !
● La version 1 répond à un réel besoin
○ mise en oeuvre lors des premiers déploiement de
services
○ utilisée pour l'analyse d'erreur lors de tests
d'intégration de services
■ "une erreur est remontée à l'utilisateur, quel service est fautif ?"
○ utilisée lors des campagnes de performances
■ "un problème de performance est détecté lors d'un acte de
gestion, quel(s) service(s) est(sont) fautif(s) ?"

33. Nouvel objectif
Mise en production ! *
* (vous avez 30 jours)

34. Roadmap version 2
● Recentrage sur les besoins primordiaux des
utilisateurs finaux de NepR
● MongoDB -> Couchbase
● Industrialisation de l'installation des agents
● Monitoring des agents
● KnockoutJS -> AngularJS
Work In Progess ...

35. nepr-server API v2
● POST
○ /data
● GET
○ /data/:type/:requestId
■ :type = "error" ou "trace"
○ /data/:type/:start/:end/:env/:layer?/:op?
■ :start & :end = intervalle de temps
■ :env = "DEV", "RE7", "PROD" ...
■ :layer = "esb", "composite", "rule" ...
■ :op = service / opération

36. Pourquoi Couchbase ?
● Vues (Map / Reduce)
● Installation d'un cluster
● Console d'administration

37. Pourquoi Couchbase ?
● Performances

38. Installation des agents
● Installation via un navigateur
○ http://nepr-server/agent/install-agent.vbs
● install-agent.vbs
○ nodejs.msi
○ node-agent.js (en tant que service windows)
○ démarre le node-agent
● node-agent.js
○ ZIP du code de nepr-agent
○ configuration du nepr-agent
○ toutes les 60 sec, réinstalle et redémarre si besoin

39. Configuration des agents
● Les configurations sont stockées dans
Couchbase
○ GET /agent/config.js
{
"type": "agentConf",
"ip": "10.231.240.59",
"date": "2013-05-21T15:35:55.002Z",
"confs": [
{
"environment": "DEV",
"component": "esb"
},
{
"environment": "RE7",
"component": "composite"
}
]
}

40. Monitoring des agents
● Une collection qui stocke le timestamp de la
dernière demande de configuration de
chaque agent
● Une page de restitution des status pour les
administrateurs de NepR

41. nepr-console
● Adaptation des vues pour répondre au
besoin des utilisateurs
○ Recherches
■ par requestId
■ par service / opération
○ Filtres
■ dates, environnement, couche
○ Affichage des erreurs
■ "twitter like"
● Utilisation de AngularJS

42. Alternatives
● Logstash
● Logio
● Graylog2
● Loggly
● ...

43. ● Merci pour votre attention !
● Des questions ?
The end