Il y a énorme nombre d'énormes de threads exécutant en parallèle continuellement (supposons cette partie continue)). Tous les fils veulent enregistrer certaines données d'application, essentiellement un ensemble de valeurs.
Plusieurs threads comme Ceci et Ce suggère log4net et log4j, mais je veux connaître le processus réel? Aussi comment plusieurs threads écrivent au même fichier journal? Le verrou de niveau de fichier est-il requis pour chaque thread? Comment tout cela fonctionne-t-il?
Tout pointeur vers la compréhension de tous les détails serait apprécié.
merci.
3 Réponses :
En ce qui concerne le point 1, je connecte habituellement tout (associé à la fonctionnalité) dans le même fichier, mais la ligne de journalisation inclut toujours certaines informations de contexte qui me permettent de suivre (via Grep ou autre chose) le flux du contexte / demande. < P> Exemple (un scénario avec des appels): de cette façon, c'est si quelqu'un demande "Qu'est-ce qui est arrivé à appeler d'AA à BB à 12h34 aujourd'hui?" Je viens de grep soit AA à BB (ou le moment où cela s'est passé), puis, une fois que j'obtiens l'identifiant d'appel, l'appel complet de l'appel est juste une question de grepping à nouveau avec l'ID. Autre Des trucs comme le chat, la présence, etc. iraient dans son propre fichier (il n'aurait pas fort de sens de mélanger cette info dans un seul fichier monolithique). Si vous voulez par fil (au lieu de par action / Demande) Il suffit de loger le nom du fil qui effectue l'action. concernant le point 2, rotation quotidienne avec log4j. Je ne sais pas le point 3 ... peut-être que tu veux dire Analyser un fichier journal pour récupérer des modèles? Tout outil prenant en charge Regex fera le tour (Grep étant le plus pratique).
logging.apache.org/log4j/1.2/manual.html Faites défiler jusqu'à "Performance". Devrait vous donner des indices.
Comme les commentaires ci-dessus disent déjà, des cadres d'exploitation forestière existent précisément à vous libérer de vous inquiéter de tels détails de bas niveau. Log4J ou ses successeurs comme Logback peuvent gérer la journalisation par plusieurs threads en toute sécurité et efficacement. Vous dissiez simplement au cadre de journalisation quoi de vous connecter et où, et tout fonctionne (généralement: -)
Pour la journalisation des données spécifiques au thread, vous pouvez envisager d'utiliser un contexte de diagnostic. Ceci Tant que les sauvegardes et le post-traitement dépendent de vos objectifs réels. Typiquement des scripts simples ou une seule commande comme gzip et grep est tout ce dont vous avez besoin. Il est difficile de dire plus sans informations concrètes.
Une bibliothèque comme Log4J pourra être configurée pour vos besoins.
Splitting dans trop de fichiers rendra difficile de déboguer des problèmes, mais un seul fichier monolithique laisse une soupe de processus mixtes. J'aurais un fichier pour chaque processus atomique, c'est-à-dire qu'un responsable de messagerie peut utiliser son propre fichier journal. Les informations supplémentaires de débogage pour JDBC pourraient avoir son propre fichier journal, mais des erreurs et des événements majeurs seraient toujours déclarés dans le journal des applications principales.
Les bibliothèques de journalisation majeures prennent en charge la division et la rotation du journal. Pour une application Web bien utilisée, je préfère avoir un fichier journal effectué pour chaque jour, et également divisé sur une certaine taille. Vous pouvez construire un cron pour zip de bousages plus anciens et, en fonction de l'application, vous pouvez les sauvegarder pendant quelques mois ou indéfiniment.
En ce qui concerne le débogage de l'utilité, vous pouvez grep pour certaines chaînes telles que "exception" à signaler. Si vous recherchez des statistiques, vous devez créer un journal pour cet objectif spécifique en plus de votre journal de processus.
Les journaux peuvent être synchrones ou asynchrones, et ce dernier est généralement préférable pour la performance. En général, une file d'attente de messages est construite puis écrite par un fil séparé. Donc, plusieurs threads peuvent écrire sur cette file d'attente ou tampon en mémoire et un thread verrouille et écrivez le fichier. C'est à peu près en arrière-plan et vous n'avez pas à y penser à moins que vous n'écrivez à une énorme quantité de données.
Habituellement, la méthode de journalisation serait synchronisée de sorte que vous n'avez pas à vous soucier de l'accéder à partir de plusieurs threads. En ce qui concerne les sauvegardes, il existe des copies de l'ombre au niveau du système de fichiers dans la plupart des systèmes de fichiers - je doute que vous devriez vous inquiéter de cela de l'application.
Le point d'utiliser un cadre d'exploitation forestière est exactement qu'il vous éparpre de vous inquiéter de tous ces détails.
@Michael Borgwardt: Je vois ton point mais je veux connaître les détails.