Know Your OSS Logs Part 2 – Java Servlet and NS/JSP Logs
Updated: Mar 26
In my previous article (Know your OSS Logs Part 1), I discussed the importance of monitoring iTP Web Server logs. If you are running Java servlet or JSP applications with iTP Web Server on NonStop, it becomes even more imperative that you monitor their logs. Why? Because they are your only conduit into what’s happening in the execution environment. Is the application running correctly? Was there an environment issue? Did the application abend? All these and other useful information are kept in the logs.
In this article, I want to share with you some basic information on Java, Servlet and JSP logs. Again, all this information is already available in the HP documentation, and so I am going to give you the “Cliff Notes ” version here:
What to monitor?
servlet.out | stdout. This is the default location for Servlet to write out APPLICATION messages. So, if there is any issue encountered by the applications, , e.g. Pathsend failures, or datafile security errors, etc., the messages are usually reported in this file. |
servlet.err | stderr. This is the location for Servlet to report errors encountered by the servlet. |
JSP rollover logs | Logs related to the Servlet/JSP processing, and may contain many, many entries, which include the servlet container’s activities and status. This is a particularly difficult log to sift through, as there can be so much information in there. These logs are configured to “rollover” (create a new one) based on certain criteria, such as date or size. |
servlet.out sample entry
$PM:inquiry-class failed with a server exception. An error has occurred with the link to the server.; TS/MP error 904; File system error 201; serverclass name: $PM.inquiry-class
Note: The above entry shows that the application has failed on a Pathsend and logged this message
JSP rollover log sample entry
An error occurred at line: 36 in the jsp file: /aceviI.jsp DataConversion cannot be resolved 33: // prepare the byte arrays 34: if (messageIn == null || messageIn.length() == 0) messageIn = ” “; 35: byte[] messageInBytes = new byte[messageIn.length()]; 36: DataConversion.JavaStrToCobolStr(messageInBytes, messageIn, 0, messageIn.length(), “UTF8”); 37: byte[] messageOutBytes = new byte[maxReplyLength];
Note: The above entry shows that the application has encountered a run time environment error due to missing code.
Why monitor?
Monitoring these logs allows you to check the health of the Java Servlet or NS/JSP applications and to detect errors as soon as they occur.
Did your Servlet just abort?
Did your NS/JSP just encountered a Pathsend error?
What NS/JSP pages are being accessed?
How can you quickly find the ERROR in your logs, among all those INFO and WARNING entires?
Which line of code in your Java Servlet has a problem?
Where are the logs?
The locations of these log files are specified in the server configuration file, and they usually reside in <NSJSP_HOME>/logs where <NSJSP_HOME> is /usr/tandem/webserver/servlet_jsp/ or /usr/tandem/webserver/servlets/
serlvet.out | /usr/tandem/webserver/servlets/logs/servlet.out |
servlet.err | /usr/tandem/webserver/servlets/logs/servlet.err |
JSP logs | /usr/tandem/webserver/servlets/logs/servlets.2012-08-02.log (rollover by date) |
Who should look at them?
The Operation team members are the people that monitor these log files as it allows them to check the health of the system. However,the log entries are very important to Developers during development or QA phases as well, as the logs will help them quickly pinpoint the locations of code issues.
If there are errors, then Development may be contacted to look at them.servlet.outOperation, Developmentservlet.errDevelopmentJSP logsAdministrator, Development
How to review the logs?
If you do it manually, it can be quite a daunting task to look through all the different entries to identify what you are looking for. While you could use cat, tail and vi to review them, realistically, you would be better off downloading your files to your desktop computer and using a desktop tool to sift through the file. But the best way is to automate with LogWatch.
Automate with LogWatch!
Instead of having to manually view these files in OSS directly, you can automate by using TIC LogWatch to:
Look for ERROR entries in the servlet logs
Look for any “thrown exception” messages
Extract the key information from the error messages and raise an alert email or EMS message to notify Operations or Development
Clone a copy of the entries to a Guardian file
All these and more can be done automatically with LogWatch
Read More Blogs
Feedback please
Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don’t forget, you can subscribe to our blogs to get automatic email notification when a new blog is available.
Phil Ly is the president of TIC Software, a leading provider of software and services for the NonStop community focused on NonStop application modernization. Under Phil's guidance, TIC Software has a proven track record of helping clients seamlessly integrate NonStop with next-generation technologies. A recognized technical leader, Phil is passionate about empowering organizations to unlock the full potential and longevity of their NonStop platform through innovative solutions.