Akka Journalisation à l'extérieur de l'Acteur

j'ai un acteur Akka qui fait un appel à MyObject.foo() . MyObject n'est pas un Acteur. Comment puis-je configurer la Journalisation? Avec un acteur c'est simple, parce que je peux juste mixer ActorLogging. Dans MyObject, Je n'ai pas accès au contexte.système. Est-ce que je crée un akka.event.Logging avec AkkaSystem() et puis quoi pour le logsource implicite?

43
demandé sur matanster 2012-04-15 01:48:51

4 réponses

en fait, je redirigerais Akka logging vers et j'utiliserais cette API directement dans toutes les classes non liées. Ajoutez d'abord ceci à votre configuration: 

akka {
    event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
    loglevel = "DEBUG"
}

puis choisir une implémentation SLF4J, je suggère . Dans vos acteurs continuer à utiliser ActorLogging trait. Dans d'autres classes, il suffit de s'appuyer sur L'API SLF4J - ou mieux encore - essayer slf4s façade autour de SLF4J.

conseil: essayez le modèle de journalisation suivant dans Logback: 

<pattern>%d{HH:mm:ss.SSS} | %-5level | %thread | %X{akkaSource} | %logger{1} | %m%n%rEx</pattern>

le %X{akkaSource} imprime le chemin de l'acteur lorsqu'il est disponible (tout comme la journalisation standard).

23
répondu Tomasz Nurkiewicz 2012-04-14 21:58:27

en utilisant Akka 2.2.1, j'ai pu mettre ceci dans mon application pour me connecter à l'extérieur d'un acteur: 

import akka.event.Logging
val system = ActorSystem("HelloSystem", ConfigFactory.load.getConfig("akka"))
val log = Logging.getLogger(system, this)
log.info("Hi!")

cela semble être une solution plus simple pour unifier la journalisation d'une application.

21
répondu bnsmith 2013-09-24 13:00:43

j'ai maintenant décidé de simplement passer mon système de journalisation central par Di constructor injection (Guice). Et dans mes classes qui font la journalisation régulièrement( où l'asynchronisme est important), je prends le système d'Actors injecté et j'appelle le 

this.log = akka.event.Logging.getLogger(actorSystem, this);

dans les classes constructeur.

8
répondu Antony Stubbs 2012-05-19 20:34:39

comme il a été mentionné, vous êtes gâté pour les options pour la journalisation non-acteur dans un système d'acteur. Je vais essayer de vous fournir un ensemble d'heuristiques pour vous aider à déterminer comment vous devez procéder à la journalisation pour votre travail.

  1. vous pouvez utiliser un logger (log4j 1.x, logback, log4j 2.x) directement en code acteur et non acteur.
    • cette option associe étroitement votre code à une implémentation logger. C'est bien, si c'est votre code, à ne pas utiliser ailleurs, mais pas très bien si vous construisez une bibliothèque ou avez l'intention d'ouvrir votre travail.
    • si vous faites cela, vous n'obtenez aucun avantage du système acteur. Les appels de journalisation peuvent devenir des appels de blocage, selon la façon dont vous avez configuré votre logger, et donc cela est mal vu partout où la performance ou le contrôle de la contre-pression sont des préoccupations importantes.
    • parce que le code de l'acteur (avec les services qu'il peut consommer) peut fonctionner sur de nombreux différents threads, certaines activités traditionnelles de journalisation telles que l'utilisation d'un threadlocal MDC (Mapped Diagnostic Context) peuvent entraîner des conditions de course bizarres et le swtiching de contexte avec la sortie de journaux à partir de messages qui passent d'un acteur à l'autre. Des activités telles que l'échange de MDCs sur des messages avant leur envoi peuvent devenir nécessaires pour préserver le contexte entre le code acteur et le code non acteur.
    • pour capturer les événements ActorSystem tels que les lettres mortes et la supervision, vous pouvez avoir besoin de écrivez un adaptateur de journalisation et spécifiez-le dans votre application.conf. Ces sont assez simple.
  2. vous pouvez utiliser la façade SLF4J pour l'enregistrement des acteurs et des non-acteurs.
    • vous n'êtes plus couplé à un impl logger et de plus vos services ne sont pas couplés à akka. C'est la meilleure option pour la portabilité.
    • vous pouvez hériter du comportement de blocage de votre cadre de log.
    • Vous pourriez avoir à gérer Mdc
    • pour capturer les événements ActorSystem vous devez spécifier" akka.événement.slf4j.Slf4jLogger" dans votre application.conf
    • vous aurez besoin d'inclure un jar fournisseur slf4j sur le chemin de classe pour acheminer les événements de journal slf4j à votre logger choisi
  3. vous pouvez utiliser Akka's Logging comme votre façade à la fois dans le code acteur et non-acteur
    • vous n'êtes pas couplé à un Logger impl ou à slf4j, mais vous êtes couplé à une version d'akka. C'est probablement une exigence de votre système de toute façon, mais pour les bibliothèques, il pourrait réduire la portabilité.
    • vous devez passer autour d'un système d'acteur pour agir comme le" bus " pour les bûcherons. L'accouplement serré à un système d'acteur de travail réduit encore plus la portabilité. (Dans une application, je construis habituellement un petit trait LoggingViaActorSystem avec un ActorSystem implicite ou global, ce qui le rend plus facile de traiter cela en code mais pas entre les dépendances).
    • la journalisation non-bloquante aynchrone est garantie, même si votre logger ne les supporte pas. L'uniformité causale de l'enregistrement est probablement attribuable à l'utilisation d'une seule boîte aux lettres destinée aux consommateurs. Cependant, la sécurité de la mémoire et la contre-pression ne sont pas (je crois que Akka logging utilise une boîte aux lettres non limitée) --
    • Il ya des options telles que l'utilisation d'un Diagnostikloggingadapter pour éviter la complexité de la gestion de votre propre Mdc que le travail passe d'acteur à acteur. La cohérence doit être préservée même si le code non-acteur mute ces MDC.
    • l'enregistrement n'est pas susceptible d'être disponible lors d'un incident de mémoire, et est sensible à l'insuffisance de thread sur le dispatcheur par défaut
    • vous aurez besoin de spécifier votre logger choisi dans l'application.conf sauf si vous êtes intéressé à se connecter à la norme out

vous êtes invités à mélanger et assortir les comportements ci-dessus si nécessaire pour répondre à vos exigences. Par exemple, vous pouvez choisir de vous lier à SLF4J pour les bibliothèques et utiliser Akka logging pour tout le reste. Il suffit de noter que le mélange du blocage et du non-blocage de la journalisation pourrait causer des conditions de course où les causes (enregistré async via un acteur) sont enregistrées après leurs effets (enregistré sync directement).

6
répondu Matthew Mark Miller 2016-02-18 20:04:28