Logging Adventures Continued

Last time, I regaled you with log file locations. This time I'll delve into something a bit more interesting (at least from a technical standpoint). One problem I have seen with our out of the box logging strategy is our inability to really see what is going on with some of the embedded application servers. For instance, which portlets are being hit in Collaboration, how many times, and what is their peak use? How often does the document repository get hit? What is the usage of the publisher container?

Yes, we have an Analytics product which gives us some insight into these questions, but from the technical perspective this doesn't always seem to be enough, since Analytics is more of a business analysis tool. What if I want to know more granular load and usage statistics? Out of the box, this doesn't seem to be something we provide you on a silver platter.

Ah, but that's why I have a blog, right?

Configuring a Valve for your Embedded Tomcat Instance

I guess the title says it all here. In order to get the granular logging I spoke about above, I set up an AccessLogValve for the embedded tomcat instance I was hosting Collaboration Server on. Remember my previous post about the embedded application server? Turns out that having your own server.xml to monkey with comes in handy here...

Get started logging by:

1. Following the instructions in my previous post by modifying your wrapper config to use a custom server.xml. In case you're lazy... modify wrapper_base.conf by adding the following lines:

   wrapper.app.parameter.1=com.plumtree.container.Bootstrap
   wrapper.app.parameter.2=3
   wrapper.app.parameter.3=-config
   wrapper.app.parameter.4=%APPLICATION_PATH%/settings/config/newServer.xml
   wrapper.app.parameter.5=start
   wrapper.app.parameter.6=org.apache.catalina.startup.Bootstrap
   wrapper.app.parameter.7=true
   wrapper.app.parameter.8=1
   wrapper.app.parameter.9=stop

2. You can either pre-generate a server.xml by running the application server (Collab, Document Repository, etc) without modifying wrapper_base.conf first, or you can just copy and modify the below to suit your needs, and save it to newServer.xml.

   <Server port="11929" shutdown="SHUTDOWN" debug="0">
     <Service name="collaboration">
       <Connector port="11930"
                  maxThreads="100" minSpareThreads="25" maxSpareThreads="75"
                  enableLookups="false" redirectPort="11931" acceptCount="500"
                  debug="0" connectionTimeout="2000"
                  disableUploadTimeout="true"
                  useBodyEncodingForURI="true"
                  maxHttpHeaderSize="16384" />
                  
       <!-- Define the top level container in our container hierarchy -->
   
       <Engine name="collaboration" defaultHost="localhost" debug="0">
      
         <Host name="localhost" debug="0" appBase="C:\sandbox\bea\ptcollab\4.2\bin\../webapp"
          unpackWARs="false" autoDeploy="true"
          xmlValidation="false" xmlNamespaceAware="false">
   
           <Logger className="org.apache.catalina.logger.FileLogger"
                    directory="C:\sandbox\bea\ptcollab\4.2\bin\../logs"  prefix="collaboration_log." suffix=".txt"
               timestamp="true"/>
   
         </Host>
       </Engine>
     </Service>
   </Server>

3. Next, add the valve to your custom server.xml underneath the Engine element and restart the service:

   <Valve className="org.apache.catalina.valves.AccessLogValve"
                              directory="logs"  prefix="collabtest_access_log." suffix=".txt"
                              pattern="common" resolveHosts="false"/> 

4. You can now use an HTTP log analysis tool, like analog, to gather some extremely detailed stats on your embedded application server.

Unfortunately, there are no free lunches. Here's a few notes you may want to read before doing this:

• I would recommend you set resolveHosts to false in the AccessLogValve (as recommended by the docs) because of the DNS resolution performance implications.
• To continue in the performance vein, there could definitely be a performance hit with this component. You will want to: (a) test it before putting it in production, and (b) make sure you log the minimum amount of data necessary.
• You may also want to watch the amount of threads spawned by enabling the valve. The maxThreads attribute in the Connector element (above, server.xml) might be useful to you in this instance.