ITM: Debugging the Situation Update Forwarder (SUF) - Part 3: Reading the Cache File
carinb 100000JKNU Visits (7867)
This is Part 3 in a series of SUF (Situation Update Forwarder) debugging posts.
Debugging the SUF means breaking down the components that allow for events to be sent back to ITM.
The major area of event handling include
- NetCool Event Management to handle the ITM event and writes the event out to a cache file.
- Persistence Directory Cache File to hand the event to the SUF listening process
- SUF process to read the cache file
- SOAP calls to send the event to the ITM SOAP client
To send event updates to a monitoring server, you must start the Situation Update Forwarder. This process is started automatically when the event server starts. To start the process manually, change to the <ins
On Windows: startSUF.cmd
On UNIX: startSUF.sh
To stop the process, run the following command:
On Windows: stopSUF.cmd
On UNIX: stopSUF.sh
On Windows, you can also start and stop the Tivoli Situation Update Forwarder service to start or stop the forwarding of event updates. You can start and stop this service either from the Windows Administrative Tools > Services utility or with the following commands:
net start situpdate net stop situpdate
Debugging tip: If the SUF is not starting properly, make sure the SUF is stopped and then check and see if there is a /tmp/stop file that was not removed. If the file exists when the SUF is not running, remove the file. Note the the SUF does need write access to the /tmp directory. If the /tmp/stop file exists before the SUF is started, it may cause problems with the startup.
The SUF has only a couple of key configuration settings that more commonly are the cause of SUF related errors.
The configuration files are found under the <ins
SOAP connection information for the Hub TEMS is stored in the situpdate.conf
An example of the file contents:
In almost all cases, these defaults are correct and should not be changed.
Debugging Tip: The fileLocation parameter points to the fully qualified directory for the persistence cache files. If the SUF is unable to read the cache files, check that this value is correct.
Debugging Tip: The cmsSoapURL should look exactly like the value of 'cms
SOAP connection userid and password are stored in <ins
Ensure this is a valid userid and password that can log into the soap client on the Hub TEMS.
Debugging Tip: The serverid value must *exactly* match the serverid seen in the sv= parameter of the event in the persistence cache file.
SUF Log Files
Here is where the SUF log files become important. You should not need to set any additional tracing in the SUF as most of the details can be found in the logs.
On Unix/Linux: /tmp/itmsynch/logs
On Windows: C:
For debugging, I recommend you stop the SUF process, move the old files from the logs directory and restart the SUF process so that you have new logs to review. This makes it easier to find the start up messages in the logs more easily.
In the sync_trace.log, it will log when it reads an event from the cache file.
First, using the logs, confirm that the cache file location that the SUF is reading is correct and that the SUF process has read-write authority to the cache file/directory.
to validate the cache file, you will find messages in the sync_trace/log confirming the filename.
2016.02.21 09:37:53.993-05:00 com.
Validate that it is reading from the correct directory (fully qualified) and file name and that there are no surrounding errors regarding reading the cache file.
Then you can also confirm the line that was read from the cache file.
The information will look like this example:
2016.08.25 09:08:19.084-04:00 com.
IBM Tivoli Monitoring Tivoli Event Synchronization acme.net IP Entry, parm 1 = op=a,
Once you see the events being read from the cache file, you have confirmation that the SUF process can read the event from the cache file and is able to receive events from Netcool for forwarding.
Subscribe and follow us for all the latest information directly on your social feeds: