I'm running Sonatype Nexus 3.15.0-01 and am a little stumped about how to override the default logback configs.
I created a file called 'logback-overrides.xml' in the 'nexus-data/etc/logback' folder containing the following:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>/nexus-data/log/myApp.log</file>
<encoder>
<pattern>%date %level [%thread] %logger{10} [%file:%line] %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="FILE" />
</root>
</configuration>
This is essentially just a simple bit of config that should cause logs to be written to '/nexus-data/log/myApp.log'. I restarted the server after adding this file, to confirm it would pick up the new configs.
However, when I check for that file, it's not present. What am I missing here?
I posted this same question on the Sonatype forums here. To sum up the answer I got there, it isn't possible to override the default logback config this way.
Possible workarounds are:
Create your own logback.xml file and build your own Docker image that extends Sonatype’s official image.
Create a volume mount for /opt/sonatype/nexus/etc/logback and customize the logback.xml on your host machine.
Related
I have a Java web app that I run in Eclipse for my development environment. I use logback for logging to a custom file. The problem is certain logging statements, specifically those that traditionally go to catalina.out, do not end up in my log file. They do show up in my Eclipse console, but not in my custom logback log file.
When I run the same app in tomcat outside of Eclipse (via startup.bat), those catalina logging statements do get captured in a catalina.out file. But when running in Eclipse no catalina.out is created, so those logs don't persist.
Here's my logback-test.xml:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<!-- RollingFileAppender that rolls based on size and time -->
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${catalina.base}/logs/mylog.log</file>
<encoder>
<pattern>%date [%thread] %-5level %logger{10} [%file:%line] - %msg%n</pattern>
</encoder>
<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
<!-- rollover daily -->
<fileNamePattern>${catalina.base}/logs/mylog.%d{yyyy-MM-dd}.%i.log</fileNamePattern>
<!-- each file at most 20MB; keep 10 files worth of history, max total 20GB -->
<maxFileSize>20MB</maxFileSize>
<maxHistory>10</maxHistory>
<totalSizeCap>20GB</totalSizeCap>
</rollingPolicy>
</appender>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>logback-test %date [%thread] %highlight(%-5level) %logger{10} - %msg%n</pattern>
</encoder>
</appender>
<appender name="STDERR" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>logback-test %date [%thread] %highlight(%-5level) %logger{10} - %msg%n</pattern>
</encoder>
</appender>
<!-- set logging levels for specific packages -->
<logger name="org.apache.catalina.startup" level="INFO"/>
<!-- set level of the root logger and associate it with both appenders -->
<root level="INFO">
<appender-ref ref="FILE"/>
<appender-ref ref="STDOUT"/>
<appender-ref ref="STDERR"/>
</root>
</configuration>
This answer resolved my question: https://stackoverflow.com/a/5045247/3368818
Apparently, if, while running an app on tomcat via Eclipse, you want to capture the catalina logs in a file, you need to specify that via the Eclipse tomcat launch configuration settings.
I guess in a way this makes sense in that the catalina logs are perhaps not application specific, so maybe outside the scope of logback appenders. But on the other hand, shouldn't they get written to a log file by default anyway, just as they do if you launch your tomcat server outside of Eclipse?
I would like to configure logging appender based on the environment, for example while running in production I would like to configure an appender that would send log to elasticsearch but while on test or development mode this appender would not be enabled.
You can override the default logback config file by using "logback.configurationFile" system variable.
java -Dlogback.configurationFile=logback-prod.xml -jar your.jar
But, if what you need is the ability to use an env variable you can do this
without to use a third-party library:
Override the logback system variable inside the main micronaut class before call main, like following
#Singleton
public class MyMicronautApplication {
public static void main(String[] args) {
var env = System.getenv("MICRONAUT_ENVIRONMENTS");
if (env != null && !env.isEmpty()) {
System.setProperty(ContextInitializer.CONFIG_FILE_PROPERTY, "logback-" + env + ".xml");
}
Micronaut.run(MyMicronautApplication.class);
}
}
create you custom env based logback config file like: logback-dev.xml and put in resources dir.
the set env var MICRONAUT_ENVIRONMENTS=dev according to your deployment logic.
enjoy using logback-dev.xml, logback-prod.xml, logback-stagging.xml, etc
The work around i found was by doing conditional expressions in logback. You will need the following dependency
<!-- https://mvnrepository.com/artifact/org.codehaus.janino/janino -->
<dependency>
<groupId>org.codehaus.janino</groupId>
<artifactId>janino</artifactId>
<version>3.1.2</version>
</dependency>
Then in your logback.xml file, you can do a conditional statement such as following for selecting the appender you want to you use based on a micronaut profile. In my case, I wanted to activate the STDOUT appender if i was running the application locally but i did not want to activate the STDOUT profile if the app was running in any other environment such as dev or prod profiles, instead i wanted the RSYSLOG appender to be used.
<root level="info">
<if condition='property("MICRONAUT_ENVIRONMENTS").contains("local")'>
<then>
<appender-ref ref="STDOUT"/>
</then>
<else>
<appender-ref ref="RSYSLOG"/>
</else>
</if>
</root>
You can use conditional statements to configure other properties in your logback file.
As far I understand, Micronaut doesn't have similar thing like Spring boot ( ) implemented.
I think logback-production.xml (where production is profile
) doesn't work too - only logback.xml and logback-test.xml is suported.
I wasn't crazy about the idea of having multiple logback config files or pulling in another dependency (janino) to support this use-case.
You can also do this using environment variables.
In my logback.xml I defined 2 appenders, one for "DEV" and one for "PROD".
Then I dynamically select which appender to use via the LOG_TARGET variable. If the variable is not set then it defaults to "DEV".
<configuration>
<appender name="DEV" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%date{ISO8601} %-5level [%X{trace_id},%X{span_id}] [%thread] %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<appender name="PROD" class="ch.qos.logback.core.ConsoleAppender">
<encoder class="net.logstash.logback.encoder.LogstashEncoder" />
</appender>
<appender name="OTEL" class="io.opentelemetry.instrumentation.logback.v1_0.OpenTelemetryAppender">
<appender-ref ref="${LOG_TARGET:-DEV}"/>
</appender>
<root level="info">
<appender-ref ref="OTEL"/>
</root>
</configuration>
Is there a way to set a single destination folder, such that I can specify where all log files should be created rather than having to set it on an appender by appender basis?
You can define a property in the logback configuration file an use it as below
<configuration>
<property name="USER_HOME" value="/home/sebastien" />
<appender name="SPRING_LOGS" class="ch.qos.logback.core.FileAppender">
<file>${USER_HOME}/spring.log</file>
<encoder>
<pattern>%msg%n</pattern>
</encoder>
</appender>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>${USER_HOME}/myApp.log</file>
<encoder>
<pattern>%msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="FILE" />
</root>
</configuration>
Note that logback can read the variables from System properties or a separate properties file too. Follow the manual for more details.
I've wasted a lot of time configuring Logback to work with Spring Boot and I'd like to share my configuration, hoping to save other people from wasting their time.
My example is similar to Andy Dufresne's above, with one key difference - no <property> tag. This was really important in my case because if you include the <property name="logs_dir" value="." /> you won't be able to override it using system properties, which I wanted to do like this:
java -jar -Dlogs_dir=~/newLogsDir yourApp.jar
Also note the default value is set inside the path variable - ${logs_dir:-.}. Hope this helps:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
<pattern>%-20(%d{yyyy-MM-dd HH:mm:ss} %highlight([%-5level])) %msg%n</pattern>
</encoder>
</appender>
<appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${logs_dir:-.}/system.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- rollover monthly -->
<fileNamePattern>system-%d{yyyy-MM}.log.zip</fileNamePattern>
<maxHistory>12</maxHistory>
<totalSizeCap>3GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%-26(%d [%-5level]) %logger{35} - %msg%n</pattern>
</encoder>
</appender>
</configuration>
I have a spring boot app, and I run the fat .jar as a systemd service.
I struggled a couple of hours on how to set the LOG_PATH relative to the user's home dir.
Here is what worked for me:
in application.properties I have:
logging.path=${HOME}/attach_logs
in logback-spring.xml I have:
<springProperty scope="context" name="LOG_PATH" source="logging.path"/>
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOG_PATH}/console.log</file>
References:
Getting the user home path in application.properties in Spring Boot
Accessing the application properties in logback.xml
Spring boot logging path
logback how to set destination folder for log files
My app runs in Jetty8 and is leveraging Logback's RequestLogImpl (which is just great, by the way). Recently we discovered that if logback has a problem rolling over files, the logging message that would have alerted us to that appears nowhere because we had not configured Jetty to redirect its stderrout to any log file. My current release corrected that problem, but now I notice an excessive volume of INFO messages from logback in the jetty stderrout file like
06:32:14,893 |-INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [/data/logs/md-stage-app4.dev.mgg.request.3.log] to [/data/logs/md-stage-app4.dev.mgg.request.4.log]
I only really care about these messages if the rename failed or something, which these messages come out as WARN. How can I get the logback stuff to just log at WARN and above into the jetty stderrout logfile?
My app itself does, indeed, <root level="info"> the root logger.
etc/jetty.xml has the following excerpt:
<!-- Logback Access Log implementation -->
<Ref id="RequestLog">
<Set name="requestLog">
<New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl">
<Set name="fileName">etc/logbackAccess.xml</Set>
</New>
</Set>
</Ref>
etc/logbackAccess.xml is:
<configuration>
<!-- always a good activate OnConsoleStatusListener -->
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />
<appender name="SIZE_ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>/data/logs/md-app3.request.log</File>
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
<fileNamePattern>/data/logs/md-app3.request.%i.log</fileNamePattern>
<minIndex>1</minIndex>
<maxIndex>5</maxIndex>
</rollingPolicy>
<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<maxFileSize>1MB</maxFileSize>
</triggeringPolicy>
<encoder>
<pattern>%h %l %u [%t] "%r" %s %b%n%fullRequest%n</pattern>
</encoder>
</appender>
<appender-ref ref="SIZE_ROLLING" />
</configuration>
The status messages are printed because of the line
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />
in logback-access.xml (etc/logbackAccess.xml in your case). By adapting OnConsoleStatusListener and OnPrintStreamStatusListenerBase, you should be able able to create a custom StatusListener which prints status messages except INFO messages originating at RenameUtil.
I am looking to use Logback Classic DB Appender (ch.qos.logback.classic.db.DBAppender) in the application. Database is Sybase ASE. I use c3p0 connection pool.
Besides the DB appender, I also have a rolling file appender. Problem is, with the DB Appender I see a drastic decrease in performance. For instance, with only rolling file appender, it takes 13 ms (milli seconds) to log the messages to file. However, with rolling file appender and db appender together, it takes 4510 ms (4.5 seconds) to output the same set of messages to file and database.
Logback DBAppender document mentions that with c3p0 connection pool, it takes around 1ms to insert a single logging statement. Numbers I am seeing are thousand times more than that. Wonder what could be wrong. Following is my logback.xml file:
<configuration debug="true" scan="true">
<property resource="log.properties" />
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<!-- encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${log.file.dir}/${project.artifactId}.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- daily rollover -->
<fileNamePattern>${project.artifactId}.%d{yyyy-MM-dd}.log</fileNamePattern>
<!-- keep 30 days' worth of history -->
<maxHistory>${log.file.rolling.history.days}</maxHistory>
</rollingPolicy>
<encoder>
<pattern>%-4relative [%thread] %-5level %logger{35} - %msg%n</pattern>
</encoder>
</appender>
<appender name="DB" class="ch.qos.logback.classic.db.DBAppender">
<connectionSource class="ch.qos.logback.core.db.DataSourceConnectionSource">
<dataSource class="com.mchange.v2.c3p0.ComboPooledDataSource">
<driverClass>${log.db.driver}</driverClass>
<jdbcUrl>jdbc:sybase:Tds:${log.db.server}:${log.db.port}/${log.db.name}</jdbcUrl>
<serverName>${log.db.server}</serverName>
<databaseName>${log.db.name}</databaseName>
<user>${log.db.user}</user>
<password>${log.db.password}</password>
</dataSource>
</connectionSource>
</appender>
<root level="INFO">
<appender-ref ref="CONSOLE" />
<appender-ref ref="FILE" />
</root>
</configuration>
Any pointers appreciated.
Thanks.
I found the following from logback manual:
If your JDBC driver supports the getGeneratedKeys method introduced in JDBC 3.0 specification, assuming you have created the appropriate database tables as mentioned above, then no more steps are required, except for the usual logback configuration.
Otherwise, there must be an SQLDialect appropriate for your database system. Currently, we have dialects for PostgreSQL, MySQL, Oracle and MS SQL Server.
for oracle, it said the supported version is :(10.2.0.1)
link:
http://logback.qos.ch/manual/appenders.html#DBAppender
If you have no a Dialect class in your JDBC driver, you can get from hibernate, and put it in your source, I don't know whether it can work.