- logback-user - mailman3.qos.ch

Is it safe to Logback for transaction protocols?
by Matthias Müller 17 Jun '18

17 Jun '18

Hi experts, as a backup for a data reception service, I am planning to use a logging facility/framework to pipe all received messages to a rolling series of backup files. The format of the received messages is simple, i.e. one line with id, timestamp and a vector of values and very much resembles the common format of log events. The backup files are a safety net to guard against bugs or unintended filtering in the downstream processing pipeline. Looking at Logback, its *RollingFileAppender* and the provided Triggers/Policies, the framework contains everything I need and it is well tested and designed. So I created a customized Logger class that instantiates Appender, Context and Policy/Trigger and also supplies a suitable event *Encoder* to create the messages as single- line strings. After a few tests the basic setup seems to work and I am pleased with the simplicity/flexibility of Logback's API and the overall processing speed. My only concern is robustness im my application scenario so the following questions primarily concern the possibilities of data loss, side effects and log pollution in this special setup. (In other words: Am I using Logback for a purpose that is within its design scope?) 1) Data loss: Is it generally safe to use logback for logging critical data to an external resource or may the framework lose data rows under certain circuumstances? (I don't intend to use Async appenders so far.) 2) Write Exceptions: Do clients of *UnsynchronizedAppenderBase#doAppend* always receive a *LogbackException* if an event could not be written to the log? I there a chance that an Event is not appended without notice? 3) Log pollution: Does Logback write any other messages except the exlicitly passed event to the log file (such as warnings or status messages)? (I've spotted various addWarn/addStatus etc. calls in the Class hierarchy but I am not sure if and where these messages are written to any logging targets). 4) Side effects with global logger configuration: When instantiating an configuring *RollingFileAppender* directly from Java code with a fresh *ContextBase* must I consider any side effects if I also use Logback as my global logging framework (e.g. via logback-classic / sl4j)? 5) Support for binary event encoding: Currently, the logged events are plain text. Am I right to assume that I could liberately encode events in an arbitrary binary format with Logback? (provided I supply a suitable Encoder class) I realize this list of questions might be a bit longer than usual. On the other hand the answers largely depend on Logback's fundamental design decisions and may thus not take too long to answer. Kind regards, Matthias

1 0

"logging_event_exception" does not exist
by Luciano Borges 04 Jun '18

04 Jun '18

Hi all, When DBAppender tries to run the following command: INSERT INTO logging_event_exception (event_id, i, trace_line) VALUES (?,?,?) I get the following error: ERROR: relation "logging_event_exception" does not exist. How to solve this problem? -- Luciano Borges

1 0

questions on logback
by Heubach Birgit (CI/DAD2.11) 24 May '18

24 May '18

Hi Logback Users, I would like to discuss with you two questions concerning logback. I have a REST Web Service that uses the appender "ch.qos.logback.core.rolling.RollingFileAppender" with rolingPolicy "ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy" with this config <fileNamePattern>${LOG_FILE}-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern> <maxFileSize>50MB</maxFileSize> <maxHistory>7</maxHistory> <totalSizeCap>500MB</totalSizeCap> I want to have all the logs deleted after 7 days. HOWEVER I realized on my System the rolling appender only runs when my Service is used. If my REST Service is not in use, there might be log files that are older than 7 days, which I would like to avoid. Question1: Is there any config that deletes logs according to <maxHistory> settings without using my Service? Question2: My REST Service has one Endpoint that is not logging anything. Lets assume, only this Endpoint is called and lets assume, there are logs older than <maxHistory>. In this case, does rolingFileAppender still delete files according to <maxHistory>?? THX and best regards Mit freundlichen Grüßen / Best regards Birgit Heubach CI/DAD2.11 Tel. +49 711 811-13899

1 0

Patter to exclude one MDC field
by Gonçalo Luiz 20 Apr '18

20 Apr '18

Hi, In an application with two log patterns, I would like to specify which MDC fields to exclude, instead of logging the whole MDC or selecting which fields to include. Is this possible? Gonçalo

1 0

Rolling with compression with changing logfile name
by Jonas Gröger 14 Apr '18

14 Apr '18

Hello! So we have a use case where + Applications get redeployed frequently (10 per day) + The applications run in containers (Openshift) + The container hostname is always different on redeploy (new container) + The logfile is named after the container hostname (i.e. svc-2-asdf) Using the RollingFileAppender with a <file>${HOSTNAME}.log</file> and a TimeBasedRollingPolicy with a <fileNamePattern>${HOSTNAME}.%d{yyyy-MM-dd_HH-mm}.log.gz</fileNamePattern> this works fine when we do not redeploy. On redeploy however the ${HOSTNAME} changes and logs are not compressed because the RollingFileAppender only compresses on roll which is every period (here: minute) if the filename is still in the same pattern, which its not here. Similarly the <maxHistory> and the <cleanHistoryOnStart> do not work here. For this I have created a RollingFileAppender that compresses on shutdown. You can find it here: https://gist.github.com/JonasGroeger/34bb004b30d18d8bc12642ba03141ac6 Is there another way without this custom Appender? -- Jonas

1 0

configuring multiple logger contexts
by Raymond Auge 12 Apr '18

12 Apr '18

Is it possible to manage the logs of multiple logger contexts in one config file? The use case is where two contexts have the same logger name but two different levels are desired: ```  <logger name="foo" level="DEBUG" />  <logger name="foo" level="INFO" /> ``` -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

1 0

How can I prevent SLF4J's infamous “multiple bindings” warning at build time for maven build?
by Debraj Manna 11 Apr '18

11 Apr '18

I have seen a similar question being answered in stackoverflow https://stackoverflow.com/questions/25335497/how-can-i-prevent-slf4js-infam… Is it possible achieve something like this via maven also ?

1 0

Logger not responding to log level configuration
by Bryan Baugher 21 Mar '18

21 Mar '18

Hi everyone, I'm running a jetty (version 9.4.8.v20171121) web application using logback. If worth while I'm using the following logging mods[1][2]. I'm attempting to just change the log levels of various packages to WARN or ERROR but I'm still seeing INFO level messages. Here is my logback config ( https://gist.github.com/bbaugher/925bfb154384bd35802dadc63196f3e1) and I've even added (-Dlogback.debug=true) to print out more info. I see the following in my logs ( https://gist.github.com/bbaugher/60c19c86f91a9ca7c506c7420cca49e1) which seems to show my config being picked up but I'm still seeing INFO level logs for packages that are set to WARN or ERROR. Any ideas or help would be greatly appreciated. [1] - https://raw.githubusercontent.com/jetty-project/logging-modules/master/capt… [2] - https://raw.githubusercontent.com/jetty-project/logging-modules/master/cent…

1 0

Logging from Tomcat Webapp
by Neeraj Vaidya 28 Feb '18

28 Feb '18

Hi, I am trying to use logback+slf4j for logging in my Apache Tomcat webapp. Apache Tomcat version : 9.0.2 Logback Version : 1.2.3 OS : RHEL 6.9 (Santiago) I have placed the slf4j and logback JAR files in WEB-INF/lib folder of the webapp. I have the following logback.xml file contents. This file is in WEB-INF/classes : <?xml version="1.0" encoding="UTF-8"?> <configuration debug="true"> <property name="logdir" value="/tmp"/> <property name="processlogfile" value="mycomp-webapp.log"/> <statusListener class="ch.qos.logback.core.status.NopStatusListener" /> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder>  <Pattern>%msg%n</Pattern> </encoder> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>TRACE</level> </filter> </appender> <appender name="PROCESS" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${logdir}/${processlogfile}</file> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>${logdir}/${processlogfile}.%d{yyyy-MM-dd}.%i </fileNamePattern> <maxHistory>10</maxHistory> <maxFileSize>10MB</maxFileSize> </rollingPolicy> <encoder> <Pattern>%date{yyyy-MM-dd'T'HH:mm:ss.SSSXXX} - [%thread] - LEVEL=%-5level - %logger{36} - %msg%n</Pattern> </encoder> </appender> <logger name="com.mycomp" level="TRACE"> <appender-ref ref="PROCESS"/> <appender-ref ref="STDOUT"/> </logger> <root level="TRACE"> <appender-ref ref="STDOUT"/> <appender-ref ref="PROCESS"/> </root> </configuration> The log file is created in /tmp (as defined by the configuration above), however, it is empty. And I have lots of trace messages in my webapp. I thought atleast the console appender messages should get logged to catalina.out, but that is also not the case. At Tomcat startup, I am able to see logback framework is picking up the logback.xml file from the WEB-INF/classes folder and so on, but just no hint of any messages being logged. Regards, Neeraj

1 0

logback version 1.3.x and Java 8
by Ceki 12 Feb '18

12 Feb '18

Hello All, Two weeks ago I started a poll [1] asking whether logback 1.3.x series should upgrade to Java 8 or remain with Java 7. Out of 400 responses, 370 participants favor upgrading to Java 8 (92.5%), with 24 participants favoring remaining with Java 7 (6%), and 4 participants declaring that they do not intend to move to logback 1.3.x series anyway. Given the strong majority, I think we have a mandate to upgrading to Java 8 for the logback 1.3.x series. Comments welcome, [1] https://doodle.com/poll/s7n3wk59694pmnbs -- Ceki Gülcü

1 0