10
votes

Log4J RootLogger semble hériter du niveau de journal d'un autre enregistreur. Pourquoi?

J'ai une configuration log4j dans laquelle l'enregistreur racine est censé enregistrer les messages de niveau d'erreur et ci-dessus à la console et un autre enregistreur enregistre tout à Syslog.

log4j.properties est: p>

private static final Logger logger = Logger.getLogger("SGSearch");
.
.
.
logger.info("Commencing snapshot index [" + args[1] + " -> " + args[2] + "]");

java log4j

1 commentaires

J'ai rencontré ce même problème / confusion. Voir Stackoverflow.com/Questtions/3023690/... .

3 Réponses :

6
votes

Informations rapides sur les niveaux

Niveaux log4J
Les enregistreurs peuvent être attribués. Les ensemble de niveaux possibles, qui est débogué, Info, avertir, erreur et fatals sont défini dans l'org.apache.log4j.level classe.
Si un enregistreur donné n'est pas attribué niveau, alors il hérite d'un de ses ancêtre le plus proche avec un assigné niveau.
L'enregistreur racine réside en haut de la hiérarchie de l'enregistreur. Il existe toujours et a toujours un niveau attribué.
J'ai modifié votre exemple de configuration log4j pour fonctionner de cette façon: xxx
J'espère que cela vous aide.

6 commentaires

Merci. Cela a fonctionné mais j'ai trouvé que je devais ajouter la ligne "log4j.logger.sgsearch = TOUT, SGSearch" ainsi que sur l'exemple que vous avez donné.

@Andrewr: Ou vous auriez pu faire ce log4j.appender.sgsearch.threshold = Tout mais que cela ferait log4j.rootlogger inutile (si je ne me trompe pas).
Je pense que cette solution est sous-optimale. Voir ma suggestion ci-dessous. Eh bien, @adriaan Koster, la solution a aidé le questionneur et c'est ce qu'il / elle voulait. Assez juste. Je viens de penser que l'ouverture de l'enregistreur racine est une erreur courante, en raison de la malentendus de la façon dont les œuvres de «additivité» dans Log4J. Réglage du seuil de l'appendeur est la clé ici. J'ai utilisé votre réponse dans ma réponse à Stackoverflow.com/questions/3023690/... à ma propre question similaire à Stackoverflow.com / Questions / 3023690 / ... .

22 votes La manière dont les œuvres de chaînage log4j sont un peu comptent intuitif (pour moi au moins). Voir Le manuel log4J . Si le niveau de la demande est égal ou supérieur au seuil de l'enregistreur correspondant le plus spécifique, il est accepté. Une fois que la demande est acceptée, elle est traitée par la chaîne complète d'ancêtres, quels que soient leurs seuils! supprimer le comportement du chute, ajoutez: xxx Cela entraînera des demandes géré par Logger SGSearch pour ne plus être transmis la chaîne. Une autre suggestion: Ne nommez pas votre enregistreur et votre appendend, car à un moment donné dans l'avenir, ou un collègue les mélangera en haut. Le nom de l'enregistreur doit indiquer quel type de journalisation est traité, le nom du Appender doit spécifier où se passe la journalisation. Donc, dans ce cas, je pense que «SGSearch» pourrait être le nom de l'enregistreur et l'appendend doit être appelé quelque chose comme «LocalSyslog». BTW: À mon avis, vous faites la bonne chose en restreignant la racine Enregistreur avec un seuil élevé et l'abaissant pour des enregistreurs spécifiques. Cela évite l'encombrement des bibliothèques fortes (Apache en a quelques notoires). 5 commentaires Cela me surprend que Log4J n'applique pas le seuil d'événement de journal des enregistreurs parent (où l'enregistreur racine est le plus haut des plus grandes) indépendamment de leurs enregistreurs enfants. Merci! Votre réponse a été très utile. Je me réfère à votre réponse dans ma réponse à Stackoverflow.com/questions/3023690/... à ma question similaire à Stackoverflow.com / Questions / 3023690 / ... . "Une fois que la demande est acceptée, elle est traitée par la chaîne complète d'ancêtres indépendamment de leurs seuils!" Si cela est vrai, alors n'est-ce pas un bogue dans log4j? Comportement qui est tellement contre-intuitif doit être une erreur. Je pense que cela a à voir avec la minimalisation de la quantité de travail à faire par événement de journal. Mais comme je l'ai dit au début de ma réponse, c'est un peu contrer intuitif au début. Je comprends maintenant mieux comment les enregistreurs héritent des annexes et bien que ce comportement me semblait étrange au début, je conviens que ce n'est pas un bogue, mais est un moyen utile de réduire le nombre d'appendeurs que vous avez besoin d'associer une chaîne de boucleurs. 0 votes Réglage du seuil sur une base par ventre est la clé ici: log4j.appender.sgsearch.threshold = débogage et log4j.appender.r.threshold = erreur C'est une solution bien meilleure que la suggestion de désactiver "l'additivité" - le problème avec c'est que tout ce que vous voulez plusieurs annonceurs à gérer seront vaincus par celui-ci - afin que vous ne puissiez pas, par exemple , Envoyez quelque chose qui est un message Message de niveau sur la console et syslog si vous définissez une additivité à false ... 0 commentaires

Articles qui pourrait vous intéresser : Comment envoyer une liste vide à la clause IN Code de réponse 403 inattendu lors de la récupération des données des API Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player Comment définir un tableau dans jsonobject