Consignation des messages, découvrez d'où proviennent les messages?

Question

À ce stade, nous avons trois sites Web, une API ouverte, une dizaine de services et de nombreuses autres parties de notre infrastructure; et ils peuvent tous envoyer des messages statistiques dans la file d'attente.

Mais, il y a un problème, nous aimerions vraiment savoir d'où viennent les messages, car nous avons eu quelques problèmes dans le passé, où une statistique a été enregistrée alors que cela ne devrait pas être possible. Pour les sites Web est assez facile, nous pouvons simplement insérer l'URL dans le message de file d'attente, et avoir une liste de regexes pour déterminer si un type de message est autorisé pour cette URL.

Mais comment pouvons-nous faire cela dans les autres applications, qui n'ont pas d'URL? Les messages sont parfois enregistrés très profondément dans l'infrastructure, ce qui peut être utilisé par toutes les applications, ce qui est plutôt difficile. Est-ce que quelqu'un a de bonnes suggestions?

Answer 1

Ils doivent en quelque sorte se connecter à la file d'attente. Ce serait un point parfait pour spécifier leur identité. Créer un wrapper pour votre objet de journalisation (ou le connecteur de la file d'attente), de sorte que vous pouvez stocker ces informations supplémentaires et le préfixer à tout message mis dans la file avant il est envoyé. [EDITION] En réponse à votre commentaire: Ma solution pour un cas similaire: Passer l'enregistreur le long d'une manière ou d'une autre. Dans mon cas, j'ai quelques méthodes statiques mais j'ai vraiment besoin de savoir qui les utilise (pas qu'elles soient appelées, c'est évident à partir du message du journal).

Ou vous pouvez mettre un jeton dans une ThreadLocal:

String token = "A"; 
try { 
    pushToken(token); 
    ...call method of B... 
} finally { 
    pullToken(token); 
} 

private static ThreadLocal context; 

public static void pushToken (String token) { 
    if (context.get() == null) 
     context.set(token); 
} 

public static void popToken (String token) { 
    if (token.equals (context.get())) 
     context.set(null); 
} 

Ce jeton survivront en bas de la pile.

Answer 2

Vous êtes sur la bonne voie avec l'URL. URL signifie «Unique Resource Locator».

Avez-vous mon point de vue?

Donnez à chaque installation d'enregistrement un identifiant unique.

Processus A ---> Alice

Processus B ---> Bob

etc ...

Vous pouvez construire votre journal comme ceci:

[Alice] certains Des choses sont arrivées. [Bob] d'autres choses sont arrivées.

Answer 3

Si vous utilisez log4j d'API de journalisation, vous serez peut-être intéressé par MDC - mapped diagnostic context. Il a été conçu en particulier pour ce type de problèmes. Découvrez logFaces - il vous laissera easily fish out des données de contexte particulières en temps réel ou en faisant des requêtes. Sinon, le ThreadLocal mentionné par Aaron semble raisonnable aussi, c'est juste que vous devrez faire le codage vous-même au lieu d'utiliser le concept prouvé de MDC utilisé dans log4j depuis longtemps et par de nombreux utilisateurs.

Divulgation: Je suis l'auteur de ce produit.