Tomcat, catalina.out flooded, is custom logging possible?

Hello friends!

When a client has our home webpage loaded, there is a webservice call made every 5 seconds and it returns a large chunk of data. This floods the catalina.out log with the INFO request, it's cookie and other header information, and then the data which the service returns to the client. This makes it difficult to investigate other client actions and webservice issues because this service's logging is in the way. Also, on a given day catalina.out can reach over 15gb

I know it's possible to change the level of logging to ERROR or WARN, but I still want INFO on some of the webservice calls.

Is it possible to stop all logging for this particular webservice, route this particular webservice's logging to another file, remove cookie information from catalina (this takes up a big chunk of unnecessary space), remove other header information from the call?

Not sure if I can think of any other ways, but please let me know if you have any solutions that can help my problem.


apache-tomcat-8.5.4
java-1.8_45
log4j-2.6.2           (this is currently logger tomcat uses, but i'll change back to JULI if it will help!)
Oracle Linux Server release 6.7



Please let me know your thoughts and if any more information could be of use.
Thank you very much in advance,
Chris  

below is an example of the beginning of a info logging statement, I now realize that it uses org.glassfish.jersey.filter.LoggingFilter
Researching to see if this may be any help


Sep 14, 2016 4:26:14 PM org.glassfish.jersey.filter.LoggingFilter log
INFO: 3354 * Server responded with a response on thread http-nio-58080-exec-2
3354 < 200
3354 < Content-Type: application/json

I realize now that this should most likely be a jersey question rather than a tomcat question. I apologize for putting this in the incorrect place.

MODS: can you please delete this thread or move it? I don't see a way for me to do it myself

Actually, this is an OK forum for this question - you were asking about catalina.out.

The first thing to realize about catalina.out is that in J2EE, webapps are each responsible for their own logging or lack thereof. Anything that shows up in catalina.out gets there because it's either

A) output by a System.out/System.err print (BAD)

B) output by Tomcat's own logger (NOT the application loggers)

C) Re-routed from an application logger (where the logger destination was stdout or stderr).

Pretty much all Java support libraries use a logger rather than brute-force System.out/err writes, so anything written straight to stdout is most likely a badly-written webapp. In case C, you'll have a webapp writing indirectly to stdout, but you'll notice that the logged message has certain attributes such as severity and time/date that a brute-force print statement wouldn't have.

The common convention when a class wants to log something is that the logger it uses will have the same name as the fully-qualified classname of the class itself. So you might have a logger named "org.apache.digester.Digester".  So if I define a logging channel that reports everything from logger "org.apache" at level "INFO", then I'll get a log with lots of info-level messages, both from the Digester and from other org.apache packages as well.

But let's say that in particular you want full debugging for the Digester class itself, and only info-level messages from the other classes in the org.apache.digester package and WARN or higher-level severity from org.apache as a whole. In that case, you would define the target log channel to report:

org.apache WARN
org.apache.digester INFO
org.apache.digester.Digester DEBUG

The same applies to other systems, including org.apache.jersey (or whatever Jersey's package structure is).

This is a characteristic of logging itself, not specific to either Tomcat or to Jersey, so if you want even more info on the subject, ask in our "logging" forum.

Thank you very much for your response Time Holloway! Now I have a clearly understanding of catalina.out, tomcat, and logging. This logging issues has been quite the learning experience.

The reason I originally made this post was because I assumed this logging was coming from tomcat's own logger, option B. Now i see my issue lies within option C.

Let's see if I can use this information and more research to figure this out for myself before I post to logging.

Thanks again for your thorough response, I appreciate it!

better* understanding of catalina.out....

sad there's no way to edit a post on this forum