i am having trouble with configuring Log4j correctly. I was expecting Log4j to rotate my catalina.out file at midnight when configuring it like the following..
log4j.properties:
log4j.rootLogger=INFO, CATALINA
# Define all the appenders
log4j.appender.CATALINA=org.apache.log4j.DailyRollingFileAppender
log4j.appender.CATALINA.File=/var/log/tomcat7/catalina.out
log4j.appender.CATALINA.Append=true
log4j.appender.CATALINA.Encoding=UTF-8
# Roll-over the log once per day
log4j.appender.CATALINA.DatePattern='.'yyyy-MM-dd-HH-mm'.log'
log4j.appender.CATALINA.layout = org.apache.log4j.PatternLayout
log4j.appender.CATALINA.layout.ConversionPattern =%d{HH:mm:ss} %5p [%t] - %m%n
After configuring I restarted Tomcat and
everything is written to:
/var/log/tomcat7/catalina.out
To test my configuration i changed the current date time to like 23:59:59:
#ls -l /var/log/tomcat7/
-rw-r--r-- 1 tomcat7 tomcat7 5840 4. May 00:00 catalina.out
As you can see, it didnt rotate at midnight... (?)
When restarting Tomcat it works perfectly fine:
#ls -l /var/log/tomcat7/
-rw-r--r-- 1 tomcat7 tomcat7 5840 4. May 13:37 catalina.out
-rw-r--r-- 1 tomcat7 root 2395 4. May 00:00 catalina.out.*CURRENTDATE*.log
Is it even possible to rotate my logfiles without restarting Tomcat?
Thanks in advance,
Marley
There are three solutions for this problem:
change default tomcat logging façade that writes to catalina.out to for example: slf4j, with all the benefits that comes with using it and log4j.
configure system cron to run logrotate of tomcat log files
change default logging class from ConsoleAppender to FileAppender.
Benefits of solutions:
very flexible as the slf4j offers many options especially with log4j, that you use anyway.
simple and doesn't require touching tomcat configuration.
simple change of configuration that disables console output
Disadvantages:
require additional libraries, affects all applications that tomcat is hosting, requires replacing default configuration with log4j.
cron+logrotate works only in linux; it might be not as simple in windows with scheduler. Requires extra scripting in windows environment.
provides only simple backup with date. Date pattern cannot be set. Does not compress rotated files.
Solution for First issue, is described here
Solution for Second issue is described here
Solution for Third issue is described here
You can as well combine solutions. For example use crontab to gzip files that where created by changing catalina.out to other name.
I would also suggest to leave tomcat so it logs to catalina.out, and configure your application to different file with log4j. This way logs from tomcat that are not immaterial won't spam your logs.
Is it even possible to rotate my logfiles without restarting Tomcat?
Yes, if you're willing to work for it.
Your log4j configuration will only end up fighting with the standard shell redirection that bin/catalina.sh uses to redirect stdout to logs/catalina.out. You can't simply use log4j configuration to change how System.out behaves.
If you want to rotate conf/catalina.out you will have to take some alternative measures depending on how to launch Tomcat:
If you use jsvc to launch Tomcat and you are using commons-daemon 1.0.4 or later, then you can send SIGUSR1 to the jsvc process to re-open the log files. That will allow you to move the existing log file to another file (which just changes its name and continues to log to the new filename) and then do 'kill SIGUSR1': the original filename will then be re-opened and new logs messages will go to it.
If you use bin/catalina.sh to launch Tomcat, you can modify it so that it no longer does redirection and instead pipes output to a rolling-logger process like Apache httpd's rotatelogs or chronolog.
Related
I am working with a ubuntu web server, where I have tomcat 8 and running a web application on tomcat. Recently I have faced some problem with cpu uses 100%. When I restart the tomcat server it is running good, but after one day or a few hour again same problem arise ( 100% cpu use) and that problem make my site slow. When I see the process list with htop command then i see so many process like
/opt/java8/jre/bin/java -Djava.util.logging.config.file=/opt/tomcat8/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoader
What can i do now? I want to disable tomcat internal logging fully but cannot do this.
What is the function of juli in tomcat? Is it use for only logging? If so i not need any logging. I don't want to see the above process any more. Please help me.
JULI is Tomcat implementation of java.util.logging API. To turn logging off, in ${catalina.base}/conf/logging.properties configure the root logger like this and make sure that there are no child loggers that override this setting:
.level = OFF
My current project taking Log4j for logging output but when it is deployed on websphere 7 it seems the logging file is always occupied by the server hence Log4J cannot close it and open a new file. Current log file can expand to 1.5 Gb if on DEBUG level. I went through a few online tutorials but didn't get a solid solution. So I open this thread for any opinion or experience on making log4J works on WS 7.
Current log4J is on 1.2.15, and the project is a plain POJO/JSP application without other containers(like Spring, I do have another project with same issue on Spring/tomcat, will open in another thread). And here is the log4j.properties:
log4j.rootCategory=INFO, ROL
#
# Rolling File Appender
#
log4j.appender.ROL=org.apache.log4j.RollingFileAppender
log4j.appender.ROL.Encoding=UTF-8
log4j.appender.ROL.File=C\:\\Logs\\AppOut.log
log4j.appender.ROL.MaxFileSize=10000KB
log4j.appender.ROL.MaxBackupIndex=10
log4j.appender.ROL.layout=org.apache.log4j.PatternLayout
log4j.appender.ROL.layout.ConversionPattern=%d -- %p -- %c -- %m%n
But this configuration just doesn't make log file roll over.
UPDATE:
It seems like each time when I try to remove the log file after stop the application(not the server), it is always saying "the file is opened by another application" which only refers to Websphere. I can guarantee that there is no other application is opening the log file. The only way to release lock on it is stop the application server.
Thanks in advance for any ideas.
we use was 7 (with portal server 6.1 on top). (We wrap our calls to the logger using the sl4j lbrary, but I don't think that is relevant to the problem here). can't really see any major difference, other than we don't set the root category, and we explicitly set the additivty to false.
Below is part of our config (showing just one of our appenders) which works just fine and rolls the logs every 10MB as expected. Perhaps it's something configured in WAS itself - I'm not a WAS admin expert and didn't install WAS myself but could ask one of our admins on Monday if you haven't solved it.
log4j.logger.com.xxx.protection=TRACE, A1
log4j.additivity.com.xxx.protection=false
# other appenders excluded
log4j.appender.A1=org.apache.log4j.RollingFileAppender
log4j.appender.A1.File=${LOG_ROOT}/applLogs/ui_and_business_logic.log
log4j.appender.A1.MaxFileSize=10MB
log4j.appender.A1.MaxBackupIndex=10
log4j.appender.A1.Append=true
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d %p %t %c MSG: %m%n
I take it that you've seen this article - http://www.ibm.com/developerworks/websphere/techjournal/0802_supauth/0802_supauth.html
I have an application which is configured on IBM WebSphere 6.0 version.
In that application, where ever the System.out.printlN() Statements, are there
Where do they get printed?
I mean which log files, will get it printed?
In standalone I can check in the console, that application is deployed in windows server box
How to Identify where all the log.debug, log.info statements get printed from the application into the server box.
I tried checking in log4j.properties, but didnot find any useful info about that.
Background, we have a Websphere app server, where we have configured 2 Nodes and I am deploying in the Node 01, on my changes and trying to debug, but no help.
Please guide if any one has past exp on it.
I haven't been using WebSphere 6 lately. I newer versions you have a profile directory and a log directory within where the log file reside.
The second option is to go into the WAS administration console and go to "Troubleshooting > Logs and Trace > server_name " there you can directly view the logs. This way is documented for WAS 6.0 as well.
As others have hinted, by default the SystemOut.log and SystemErr.log files are located in each node's profiles/<profileName>/<serverName>/logs directory. (These locations and file names can be overridden in the Administration Console.)
log4j logs will depend on the appenders in your log4j configuration (could be a log4j.properties or a log4j.xml file), but might also be affected by whether anything in your application uses Jakarta Commons Logging. If it does, you may find all log4j logging also going to SystemOut.log.
It should get logged in Program files/IBM/SDP/profiles/runtimes/baseV6...
something like this .currently am at home and I don't have exact path.But search in profile directory .
You should always define your own path for appenders in your applications logging.xml instead of using default path of WAS.
The log files are resided at C:\Program Files\IBM\SDP\runtimes\base_v7\profiles\was70profile1\logs\server1
I am using Logback in my application hosted on Websphere App Server. Logback is configured to log to System Out (and others are hesitant to change to a different file). The issue is that Websphere uses its own format for logging to System Out. Executing logger.debug("test") in my app yields:
[8/7/12 12:27:55:629 CDT] 0000003a SystemOut O DEBUG com.myapp... test
where everything up to the "O" is added by Websphere. The rest is from Logback
I have set up Logback to use the following pattern: %-5level %logger{36} - %msg%n so that I don't repeat timestamp and thread info which Websphere does on its own, but I am still annoyed that I can't fully customize the logging to System Out from within Logback.
I don't know a whole lot about logging best practices. Before, I have logged to separate files by web app, but for this project, I was told the System Out files are monitored by a third party and I should not change from using System Out. Is there any way to get around my issue given these requirements and tell Websphere not to mess with my System Out logging, or is the only solution to start logging to a different file? Thanks!
Your logback is configured to write messages to System.out. However, everything that is written to System.out is redirected by WebSphere and written to the SystemOut.log file with the same format as log messages produced by WebSphere, but with a severity indicator "O". It is not possible to change that.
Note that it is likely that the people who told you to use SystemOut.log actually meant that you should ensure that logging is done using WebSphere's log system so that messages are written with the correct category and severity and that log levels can be changed at runtime. Since WebSphere's log system is build on java.util.logging you should probably just replace logback by slf4j-jdk14 to satisfy their requirement.
I don't think you're going to be able to change the format. And if you could, it might break the current monitoring anyway.
I wonder if anyone would mind if you log to two loggers at the same time, SystemOut for the existing monitoring, and your own for a more readable format.
The problem is that Logback redirects the messages to console output instead of java.util.logging. Console output has no log levels and that's why WebSphere just writes "O".
We solved this by implementing a Logback appender that redirects logs to JUL (java.util.logging) instead. We convert Logback log levels to JUL levels (e.g. Logback "ERROR" is JUL "SEVERE").
We also wanted to use Websphere's trace options. If trace is enabled for a class/package pattern, you will see Logback DEBUG and TRACE messages in Websphere's trace.log. You can also check if the trace is enabled by calling Logback's isDebugEnabled() / isTraceEnabled().
See this answer with a full implementation:
https://stackoverflow.com/a/74386323/395879
I'm parsing gigantic Tomcat log files and I was wondering: when you stop, redeploy and then restart a Webapp, do the logs get automatically appended to the last debug.log.
More specifically: can you see in a unique debug.log file logs coming from two different deployments of a same .war?
So, for example, can you have logs from up to 11am from, say, version 1.0 of, say, example.war and then logs from 1pm coming from, say, version 1.1 of example.war in the same debug.log? Is this depending on the logger used and the way it is configured?
Tomcat will debug every error in the same log file, it doesnt matter if there is two different war files. Try using log4j (http://tomcat.apache.org/tomcat-5.5-doc/logging.html) it allows you to separate everything into different log files.