Java vers rsyslog: sortie STANDARD ou syslog?
Ma compréhension de rsyslog est qu'il s'agit d'une implémentation de serveur syslog commune sur les machines Ubuntu.
De Plus, mon compréhension que rsyslog peut être utilisé pour crochet/capture STDOUT sortie ainsi que standard syslog messages.
Enfin, ma compréhension est que rsyslog peut ensuite transférer tout messages capturés (encore une fois, provenant de STDOUT ou d'un client syslog) sur un autre serveur, tel qu'un agrégateur de journaux, ou un autre serveur rsyslog, etc.
Donc tout d'abord, si quelque chose que j'ai déclaré ci-dessus est incorrect, veuillez commencer par corriger ma compréhension de la façon dont syslog/rsyslog travail et leur relation les uns aux autres!
Si mes hypothèses sont plus ou moins correctes, étant donné les deux options suivantes:
-
Option # 1: Connectez-vous à
STDOUTet configurezrsyslogpour capturer ce flux et transférer les messages de journal à un processus distant (par exemple un agrégateur de journaux); ou -
Option # 2: Connectez-vous à
sysloget configurezrsyslogpour le capturer et transférer les messages de journal au même processus distant
Compte tenu de ces deux options, je préférerais #1 puisque:
- Lors de l'exécution locale ou à partir d'unE, {[3] } s'imprime sur la console; et
- Lors de l'exécution sur un environnement non local, {[3] } sera simplement "collecté" par
rsyslog
Si je vais avec l'option # 2, je perds la visibilité de la console lors de l'exécution localement.
Cela dit, y a-t-il des problèmes de sécurité/performance/autres préoccupations/mises en garde/pièges de la journalisation vers STDOUT qui rendraient l'option #2 plus attrayante/souhaitable? Si oui, quels sont-ils?
1 answers
Vous devez utiliser l'un des nombreux enregistreurs (c'est-à-dire java.util.journalisation, etc.), puis configurez - le comme approprié pour chaque cas d'utilisation. Pour les tests locaux, configurez l'enregistreur sur STDOUT. Pour la production, configurez-le pour syslog.
En enregistrant simplement STDOUT, vous perdez toutes les métadonnées fournies par l'enregistreur, ou éventuellement utilisables par syslog, car tout ce que vous pouvez enregistrer est le message.
Par exemple, dans Glassfish, tout ce qui est exécuté sur STDOUT est enregistré en tant qu'INFORMATION dans les journaux Glassfish.
Donc, si vous exécutez Log4j sur STDOUT, les journaux sont capturés, mais ce que vous ne capturez pas, c'est s'ils sont WARN ou DEBUG ou autre. La BALISE est capturée, dans le cadre du message, mais le message est, apparemment, opaque par rapport à quelque chose qui traverse l'enregistreur lui-même.
Si vous aviez configuré Log4j pour utiliser l'enregistreur Glassfish, (qui est java.util.logger), puis le journal Glassfish capturerait les méta-informations( comme le niveau), comme mappé au système de journal Glassfish (par exemple, Log4j DEBUG est j.u.l AMENDE). Maintenant, un visualiseur de journaux peut avoir accès à ces données et agir dessus.
C'est pourquoi vous ne voulez pas simplement vous connecter à STDOUT si possible. Mieux vaut se connecter à quelque chose de plus haut niveau, et laisser une étape ultérieure décider comment le rendre et organiser les données.