tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: parse mod_jk log
Date Mon, 07 Oct 2013 13:53:38 GMT
Don't top post.

> From:   Daniel Mikusa <>
> To:     "Tomcat Users List" <>
> Date:   10/07/2013 04:21 PM
> Subject:        Re: parse mod_jk log
> On Oct 7, 2013, at 2:57 AM, wrote:
>> Hi,
>>          I have enable 'debug' mode and find such lines in mode_jk log. 
>> There are other types of lines also
>> Mon Oct 07 10:39:34 2013][993:1188796736] [debug] 
> service::jk_lb_worker.c 
>> (1157): service worker=node2 route=node2\par
>> Can I know how I should parse this log to prove that connections are 
>> actually routed to two nodes( two tomcat instances) properly ?
> Could you just look at the access logs on the two Tomcat nodes?  Those 
> would certainly show when a request is routed to each node (i.e. node-aa 
> will have only records for requests sent to node-a and vise versa).  That 
> would also be better than running with debug log level enabled all the 
> time.
> wrote:
 > Ok. I am already doing that. I thought mod_jk logs can be parsed using
 > something like awstats.
 > Mohan

The mod_jk log, like the Apache httpd and Tomcat error logs are normally meant for 
debugging problems, not for long-term usage or statistics.
Writing logs is quite expensive from a server point of view, that's why the recommendation

and default "logging levels" are set low.
A hint is the "debug" level that you had to set to get your original mod_jk log.

Error logs will generally exhibit multiple interleaved lines from different children or 
threads of the server handling multiple parallel requests, making it quite time-consuming

to bring back together what concerns a single request e.g.

Access logs on the other hand are designed to be analysed for statistical/graphical 
purposes, that's why they tend to follow a generic format easy to parse with awstats and 
similar programs.  That is also why they generally tell you all you need to know about one

request, in one single line : quick to write, easy to parse later.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message