Logging is one of the essential components of system monitoring and diagnosis. Logging is the action of collecting a series of events for the purpose of determining what steps were taken by a program. It is thus very important to configure logging in a manner that helps you monitor application processing.
The Syslog and Event Viewer
Linux/Unix and Windows by default have logging abilities. The systems use different terms and programs. The syslog is the Linux/Unix term for the main log generated by the operating system. In Windows it is called the Event Viewer. The Windows Event Viewer by default is enabled. The syslog on Linux/Unix is not enabled by default.
The syslog is a plain text file with each event taking a single line (normally). The Event Viewer is an application with a logging hierarchy (System->Application->Event).
Here is a sample of the syslog:
Here is a sample of the Event Viewer:
To enable the syslog, follow the basic syslog configuration available here:
Configuring the syslog daemon
However, this just outputs the messages and does not provide instructions for dedicated logging or more often, rotating and archiving the logs when they get too big.
All syslog configuration is outside of the scope of IBM Integration Bus (IIB) as it just uses your OS’s logging hooks. You must then configure your syslog at the OS level. Here are some (free) options you have.
Splitting / Filtering
Splitting is taking a single input and dividing it into several outputs. Filtering is the removal of data from an input so that only the desired data is left in the output. The examples above are simple examples of both. You filtered out only the IIB records and then split IIB from the rest of the data.
Log Rotation
Log rotation and archiving are common topics brought up by admins as a way to manage disk space. IIB will generate several logs beyond the above syslog. Common ones are:
- Integration node stdout and stderr (console.txt on Windows)
- Integration server stdout and stderr (console.txt on Windows)
- httplistener stdout and stderr (console.txt on Windows)
There are no limits to the file size and some traces (class loader trace, JSSE trace) can write to the logs as well. If you don’t turn off the traces or handle the errors, your logs can fill quickly.
Generating Custom Log Entries
The above information is useful in setting up your logs and will show the entries generated automatically by IIB such as unhandled errors and configuration changes. But this is not always enough, especially when debugging or developing a flow. To overcome this, you need to generate dynamic user messages. IIB provides several ways to produce your own log entries:
- Trace node
- Throw node
- THROW command in ESQL & Throw in Java
- DECLARE HANDLER command in ESQL
By using these in the flow, you can log a vast amount of data. These can help with issues encountered in flows and can also be used to return useful errors to clients.
Log4j
Log4j is a set of Java libraries from Apache used for logging purposes. As it is Java code, it can be integrated into IIB. Not only can you use the libraries in a Java compute node, but there is also a supportpac which adds a logging node built from the Log4j libraries. The down side is that it writes to its own log file, not to a syslog or trace, unlike the throw statements.
The best use of Log4j is inline logging. While primarily used with Java, it can be called from ESQL if you create a simple procedure that calls a Java method that does the actual logging.
The Log4j node is less sophisticated than the trace node built in. The Log4j node is limited in where it can pull data from. For example, in the trace node sample above, you can extract information about the integration node, integration server, application, flow, and node. You can also access multiple trees simultaneously and write custom text. Log4j cannot do that. It can output a single message tree or part of one. Or it can output a line of custom text.
More information:
Apache Log4j 1.2
IAM3: WebSphere Message Broker – Node for log4j
Configuring the Log4j node in WebSphere Message Broker
I hope this helps extend the logging functionality in IIB.
#IIB
#monitoring
#logging