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.
Related
I have a Maven java project, my logging.properties is placed under resources folder. I have configured to print FINE level messages using console logger.
The WAR file generated has the properties file under WEB-INF/classes but, the application when deployed and executed, I can see only INFO level logs.
Should i initialize any LogConfiguration apart from having my logging.properties in the correct path ?
As describe here, you configure loggers in Liberty by something like this in the server.xml:
<logging traceSpecification="*=audit:com.myco.mypackage.*=debug"/>
and see the logging metatype doc to configure other aspects like log file size, number of logs to keep, etc.
Or, as the article mentions, you can use the bootstrap.properties
entries to do the same, e.g. com.ibm.ws.logging.trace.specification.
Though WebSphere also supports java.util.logging APIs, its full infrastructure isn't necessarily configured the same way as say Tomcat, which your app may be patterned after.
If you want to configure different logging behavior for different applications you can have the application Java code use a different Logger name for each, and then configure them differently through the single server.xml config (or also potentially separate the apps out onto different servers).
Dynamically changing the trace settings on a running server can be done simply by editing the server.xml config (as can dynamically configuring almost any aspect of Liberty).
I'm trying to essentially configure logging in three places, independently. Ideally, each component that is logging is fully unaware of the others. I'd like to use logback for this, as it seems to have some decent features and performance.
Here are the places from which I would like to log from and to:
Tomcat (7) should log to ${catalina_home}/logs/catalina.out, and should only log Tomcat events (deployments, server startup, etc)
A web application hosted in Tomcat should log to ${catalina_home}/logs/application.log, and should only log application things, like results of request validations or errors
A library that is included in the web application should log to ${catalina_home}/logs/library.log, and should only log things specific to that library, like time it takes to interact with some other web-service or library-specific errors
I know this is probably not the way it would work, but I would think I need to have a logback.xml file for each concern. Actually, I have created them and added to the classpath such that I get a "logback.xml occurs multiple times on the classpath" error.
I can see why I would need to consolidat my application and my library logback configuration to a single logback.xml file, but how would I keep the container logging config separate from the application+library logging config? Adding a logback config file to my application, as well as logback enabling Tomcat as described here, still yields a "multiple logback.xml" error. And, Chapter 9 of the logback user manual, which talks about separation of logging, doesn't really show how to separate the container and applications (just multiple applications), unless I am missing something there.
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 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.
I am using Tomcat version 5.5.x. My WAR sets its own logging properties successfully and logs to $TOMCAT_HOME/logs/.YYYY-MM-DD.log. Everything that is written to my log is also written to catalina.out. Is there a way to stop the redundant logging to catalina.out stop?
Change your application's logging configuration so it doesn't log anything to the console/standard out. Tomcat redirects standard out to the catalina.out file, so if you see output in catalina.out it implies your application is writing to the console.