February 2016 - logback-user

Logback => TLS/SSL => Syslog ?
by Otis Gospodnetić 21 Feb '19

21 Feb '19

Hi, Does Logback support sending logs to Syslog servers via TLS/SSL? I have a feeling Logback doesn't have a SyslogAppender that can send data using TLS. I say that because I don't see a mention of "syslog" on http://logback.qos.ch/manual/usingSSL.html and I see http://jira.qos.ch/browse/LOGBACK-890 that mentions TLSSyslogAppender, but it looks like this never ended up in Logback. I've only found it committed here: https://github.com/balabit/logback/commit/e0d89de2536e0925a6c816a50793f6a74… Could anyone please clarify? Thanks, Otis -- Monitoring * Alerting * Anomaly Detection * Centralized Log Management Solr & Elasticsearch Support * http://sematext.com/

2 1

More information about log back mechanism and configuration
by Roberto Pecoraro 29 Feb '16

29 Feb '16

Hi team, I would like to reduce kairosdb traces in log files, then i need to change the configuration in order to have limited log size and wrap around log files. This is my current log configuration file: <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level [%file:%line] - %msg%n</pattern> </encoder> </appender> <appender name="logfile" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>log/kairosdb.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern>log/kairosdb.%d{yyyy-MM-dd}.log</fileNamePattern>  <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d{MM-dd|HH:mm:ss.SSS} [%thread] %-5level [%file:%line] - %msg%n</pattern> </encoder> </appender> <logger name="com.mchange.v2.c3p0" level="WARN"/> <root level="DEBUG"> <appender-ref ref="stdout"/> <appender-ref ref="logfile"/> </root> </configuration> My requirement is to have 'N' files of maximum size 'S' MB which go in rollover, possibly leaving the first file unchanged. Thanks and regards Ciao Roberto.

2 1

Release of logback version 1.1.6
by Ceki Gulcu 29 Feb '16

29 Feb '16

Hello all, The logback team is happy to announce the release of logback version 1.1.6. It contains important bug fixes and improvements. It should hit the Maven central repository by the time you read this message. Here some notable changes that you should be aware of. * Logback now *requires* SLF4J version 1.7.16 or later. * MDC values are no longer inherited by child threads. * Packaging data (as output in stack traces) is now disabled by default. Please refer to the news page for precise details. http://logback.qos.ch/news.html You can receive logback related announcements by subscribing to the QOS.ch announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce You may also receive announcements via twitter by following: https://twitter.com/qos_ch Enjoy, -- Ceki

1 0

JMXConfigurator problem with IBM WebSphere
by Dale.Chapman＠medavie.bluecross.ca 24 Feb '16

24 Feb '16

Hi Folks. I have looked through the archives looking for an answer on what to do to get the JMXConfigurator working with WebSphere. The last entry I was able to see was from Ceki on Jun 12, 2012. Has anyone done any further research into this? If not, this is what I have found. I have spent some time trying to understand the problem. What I have been able to figure out is how to configure WebSphere to show the Logback JMX MBean in an "unsupported" mode using the platform MBean server. found here ( https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.jazz.repository… ) Essentially, you need to configure websphere with the following JVM arguments: -Dcom.ibm.team.server.monitoring.mbean.server=WebSphere -Djavax.management.builder.initial= -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false Once I did this, I was able to get jconsole to allow me to manage Logback within WebSphere. I would prefer to be able to use jconsole in the supported JSR160RMI connector mode. This involves configuring websphere with the following JVM argument: -Dcom.ibm.team.server.monitoring.mbean.server=WebSphere and then configuring jconsole with the information contained in the same article in the Option 2: Setting up JMX in JSR160RMI connector section. When I configured WebSphere and jconsole in this fashion, I was able to connect to an MBean server, but it did not include the Logback bean. With the help of a couple of coworkers, we were able to find the following documentation: https://www-01.ibm.com/support/knowledgecenter/SS7K4U_8.5.5/com.ibm.websphe… which indicates that WebSphere expects that the MBean be registered as follows: MBeanFactory mbfactory = AdminServiceFactory.getMBeanFactory(); mbfactory.activateMBean("SnoopMBean", snoop, "snoopMBeanId", "SnoopMBean.xml"); The code I downloaded from git for Logback shows that the JMXConfigurator uses the following: MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); mbs.registerMBean(jmxConfigurator, objectName); I was thinking that an appropriate solution to the WebSphere problem might be to add a JVM config flag such as org.qos.logback.websphere and if the flag is set to true, the begin() method of the JMXConfiguratorAction class could follow the expected IBM MBean registration instead of the standard. Opinions? Dale Chapman, Architect - MAAX Support Medavie 506-867-4430 dale.chapman@medavie.bluecross.ca----------------------------------------------------------------------- This communication, including any attached documentation, is intended only for the person or entity to which it is addressed, and may contain confidential, personal, and/or privileged information. Any unauthorized disclosure, copying, or taking action on the contents is strictly prohibited. If you have received this message in error, please contact us immediately so we may correct our records. Please then delete or destroy the original transmission and any subsequent reply. Thank you. La présente communication, y compris toute pièce qui y a été jointe, est destinée uniquement à la personne ou à l’entité à laquelle elle a été adressée, et contient des renseignements à caractère confidentiel et personnel. Toute diffusion ou reproduction non autorisée ou toute intervention entreprise relativement à son contenu est strictement interdite. Si vous avez reçu ce message par erreur, veuillez nous le signaler immédiatement afin que nous puissions effectuer la correction à nos dossiers. Veuillez par la suite supprimer ou détruire le contenu de la transmission originale ainsi que toute réponse ultérieure. Merci. -----------------------------------------------------------------------

1 0

Rolling file appender not working for portal.log in /portal
by David Brown 23 Feb '16

23 Feb '16

Howdy, I looked at the archived email but no way to search. I am using logback in uportal on two different machines both running the uportal server @localhost. The one machine is using a fresh clone of uportal. The other machine is my dev box for the company implementation of uportal. My machine logback is working as expected with the file rolling appender. The company dev box is issuing diskspace warnings because portal.log is growing unbounded. There are no .gz files in the /portal directory which leads me to believe the rolling file appender is not working. Inspection of logback.xml provides no clues as to what is wrong. Any diagnostics or suggestions welcomed. Kindly regards.

2 1

how to deactivate logger (OFF) in the threads. The messages are still displayed in the console
by Sky Dog 23 Feb '16

23 Feb '16

Hi all, I am using a small logback.xml conf file to display the logger messages into the console ---------------------------------------------------------------------------- <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>OFF</level> </filter> <encoder> <pattern>%d{HH:mm:ss.SSS} %-5level %logger{25} - %msg%n</pattern> </encoder> </appender> <root level="INFO"> <appender-ref ref="STDOUT"/> </root> <logger level="ERROR" name="general"/> <logger level="OFF" name="net"/> <logger level="OFF" name="wire"/> <logger level="OFF" name="VM"/> <logger level="OFF" name="dump"/> <logger level="OFF" name="gas"/> <logger level="INFO" name="sync"/> <logger level="INFO" name="blockqueue"/> </configuration> ---------------------------------------------------------------------------- The problem is, I still see the *VM* and *gas* messages from the logger although I have deactivated it (OFF): 2016-02-22 21:36:13.389 INFO 7574 --- [ Thread-10] *gas* : [369500479] Spent for cause: [DUP1], gas: [3] 2016-02-22 21:36:13.389 INFO 7574 --- [ Thread-10] *VM* : [278] Op: [DUP1 ] Gas: [478018] Deep: [0] Hint: [] 2016-02-22 21:36:13.389 INFO 7574 --- [ Thread-10] *gas* : [369500479] Spent for cause: [PUSH4], gas: [3] 2016-02-22 21:36:13.390 INFO 7574 --- [ Thread-10] *VM* : [283] Op: [PUSH4 ] Gas: [478015] Deep: [0] Hint: [abc00bb4] 2016-02-22 21:36:13.390 INFO 7574 --- [ Thread-10] *gas* : [369500479] Spent for cause: [EQ], gas: [3] The classes which uses the logger, they define it as follows: private static final Logger logger = LoggerFactory.getLogger("VM"); private static final Logger dumpLogger = LoggerFactory.getLogger("dump"); What am I missing? I want to avoid the *VM* and *gas* messages Regards and thanks in advance! S.

2 1

logging stopped, using AsyncAppender and SocketAppender
by Tara Czutno 15 Feb '16

15 Feb '16

I have 3 servers with various java process, I want all processes to write to one log on machineA. I am doing a load test with a lot of logging, but it appears logging from the main process has stopped. Is there a way to check for logback status? Is the setup below the correct way to go about having one log? I set this up so SimpleSocketServer is running with this config: <configuration scan="true" scanPeriod="60 seconds"> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/opt/twc/logs/ecp.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/opt/twc/logs/ecp.log.%d{yyyy-MM-dd}</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d{ISO8601} %-14mdc{application} %-5level [%t] %logger{100} - %msg%n %xEx</pattern> <immediateFlush>false</immediateFlush> </encoder> </appender> <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>100000</queueSize> <discardingThreshold>0</discardingThreshold> <includeCallerData>true</includeCallerData> <maxFlushTime>5000</maxFlushTime> <appender-ref ref="FILE"/> </appender> <root level="DEBUG"> <appender-ref ref="ASYNC"/> </root> </configuration> All other processes are running with this config: <configuration> <appender name="SOCKET" class="ch.qos.logback.classic.net.SocketAppender"> <remoteHost>ecplogger</remoteHost> <port>6000</port> <reconnectionDelay>5 seconds</reconnectionDelay> <includeCallerData>true</includeCallerData> <queueSize>100000</queueSize> <eventDelayLimit>100 milliseconds</eventDelayLimit> </appender> <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>100000</queueSize> <discardingThreshold>0</discardingThreshold> <includeCallerData>true</includeCallerData> <maxFlushTime>5000</maxFlushTime> <appender-ref ref="SOCKET"/> </appender> <root level="ALL"> <appender-ref ref="ASYNC"/> </root> </configuration>

1 1

Log file ot created
by Paolo Di Tommaso 14 Feb '16

14 Feb '16

Hi, After upgrading from Logback 1.1.3 to version 1.1.5 I've noticed that it isn't creating the log file any more. I'm using a RollingFileAppender configured using a piece of code like this: RollingFileAppender result = logFileName ? new RollingFileAppender() : null result.file = logFileName def rollingPolicy = new FixedWindowRollingPolicy( ) rollingPolicy.fileNamePattern = "${logFileName}.%i" rollingPolicy.setContext(loggerContext) rollingPolicy.setParent(result) rollingPolicy.setMinIndex(1) rollingPolicy.setMaxIndex(9) rollingPolicy.start() result.rollingPolicy = rollingPolicy result.encoder = createEncoder() result.setContext(loggerContext) result.setTriggeringPolicy(new RollOnStartupPolicy()) result.start() Something has changed that logic ? Cheers, Paolo

2 4

MDC.clear() invoked in child class deletes parent keys
by Kuu 10 Feb '16

10 Feb '16

Hello, I found an issue using the MDC. I have a filter that does the following: .... MDC.put("key", value); filterChain.doFilter(request, response); value = MDC.get("key"); ... And the value is empty. The problem comes because a child controller class does: MDC.put("key2") ... some logic.... finally{ MDC.clear(); } And that call deletes all the content of the map. The problem is that the child class does not check if the MDC contains something. Of course this could be considered as a bad practice, but this "clear()" method is too risky as it deletes ALL, even the parent keys... I found this ticket : http://jira.qos.ch/browse/LOGBACK-325 <http://www.google.com/url?q=http%3A%2F%2Fjira.qos.ch%2Fbrowse%2FLOGBACK-325…> but it seems to be resolved. The version I'm using is the loback-classic 1.1.2 Let me know if you need more information. Thank you. Best Regards, Javier

3 2

OSGi wiring problems when using SLF4J+Logback
by Joel W 01 Feb '16

01 Feb '16

Hi all, I’m switching logging mechanisms from JUL to SLF4J+Logback on an application that is an OSGi bundle - it’s a plugin for an OSGi application. However, I’m getting some wiring problems: many Logback dependencies don’t seem to be resolved. I have the relevant Maven dependencies as follows: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.12</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>1.1.3</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.1.3</version> </dependency> All 3 of these are specified in the class path of the application runner script. This script also points to a basic logback.xml configuration file that just prints to stdout. For bundling I use the maven-bundle-plugin v3.0.1, where the relevant directives are: <Export-Package> org.slf4j*, ch.qos.logback* </Export-Package> <Embed-Transitive>true</Embed-Transitive> The application gets assembled using maven-assembly-plugin v2.6; I’ve attempted to have the above 3 dependencies start as bundles, before the main application, or simply included them in my /lib/ folder. Upon attempting to initialize the application, I get the error: 14:13:01.540 [FelixStartLevel] ERROR o.p.o.framework.FrameworkSlf4jLogger - Error starting file:/…/app-name/target/distribution/bundles/app.jar org.osgi.framework.BundleException: Unresolved constraint in bundle app [15]: Unable to resolve 15.0: missing requirement [15.0] osgi.wiring.package; (osgi.wiring.package=groovy.lang) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4002) ~[org.apache.felix.main-4.4.1.jar:na] at org.apache.felix.framework.Felix.startBundle(Felix.java:2045) ~[org.apache.felix.main-4.4.1.jar:na] at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1299) ~[org.apache.felix.main-4.4.1.jar:na] at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304) [org.apache.felix.main-4.4.1.jar:na] at java.lang.Thread.run(Thread.java:745) [na:1.8.0_25] If I include groovy.lang* in the <Export-Package> directive, then I get another missing requirement: javax.jms, and this keeps going with packages that Logback depends on (javax.mail, java.mail.internet, javax.servlet…). I’ve experimented quite a bit, but unfortunately I can’t spot what I’m missing or doing wrong. Does anyone have any idea what might be wrong? Any help would be greatly appreciated! Many thanks, Joel

2 2