Log File Lament

Body

While the style in which an IBM Sterling B2B Integrator (SI) Support Analyst goes about troubleshooting an issue may vary, a core part of our job is reviewing log files. It's also one of the most frustrating parts. Here's why: we rarely receive what we ask. For most Analysts, it's not that we're trying to avoid talking to you or don't want to join a web conference, it's just that we want it to be productive when doing so. Log files are key to us knowing the next steps in troubleshooting.

Awhile back I blogged about "IBM Sterling Integrator B2B PMR Best Practices"  yet despite the frequent visitors to that entry,  the log file lament continues.  When support provides a link to a "must gather" that technote indicates all the BASIC information support needs to start troubleshooting. You can start with that main "must gather" collection that I've provided and locate one that applies to your issue or you can try googling for it yourself using a search term similar to this:  Sterling Integrator must gather keyword site:ibm.com 

For the keyword substitute your situation for example: AS2, database, performance, file gateway, etc. This way when you open the PMR you can supply the files we need to hit the ground running! Or better still, you can search the files yourself for an error message and then google for that and possibly solve the issue yourself.

The next issue is the format of the files. When we ask for a log file (or log files) - we want the entire log file: not a screen shot, not an excerpt, not a PDF nor a Miscrosoft Word document. We want the entire log, in the format SI wrote them. A related log file problem seems logical - we want the log files from the day and time of the issue. It's frustrating to download log files, unzip them, only to determine they're not from the time the issue occurred. It's also frustrating to download a file that has a non-descriptive extension type - because we don't know what tool to use to review it ( zip, open office, wireshark, notepad, etc). For example, if you compress a set of files into a tar or a zip file, please leave the extension *.tar or *.zip - don't rename it to *.PMR or *.dump  (by default Windows doesn't know how to open it and we'll try guessing but that doesn't always work).

Here's an example of what happens when we go to download a binary file that you've renamed to *.log or *.txt - the download expected ascii text but the content is binary. I now have to rename or zip this file up in order to be able to download it correctly.

Related to getting the log files from a day/time of the problem, having them zipped up and uploaded to the PMR is providing too many log files. SI creates sub-directories under the log directory. The main log directory contains the current logs, while the sub-directories contain logs from a previous day. For example in the snapshot below, the logs_08152016_081735 contain the logs from 08/15/2016 that existed prior to a restart of SI. The rest of the individual logs shown in the snapshot are the most current. If the logs in logs_08152016_081735 have nothing to do with the problem in your PMR then EXCLUDE those from the zip file. If instead the logs in logs_08152016_081735 are the ones that captured the issue, then zip up that sub-directory only (exclude the current logs). A very large zip file results when you include all of the log directory's sub-directories. This takes more time for you to upload and equally as much time for us to download, unzip and then try and determine which files are relative to the issue at hand.

Another concern of ours is how the files are uploaded. If we ask you to zip the files up, there's a reason. It can be that there will be a lot of individual files or that the combined size might be large, but we're asking you to compress the files into a single one then upload that. It may be that you have multiple nodes and we want all the logs for each node in their own package. Or, it could be that on our end we don't want to be inundated with alerts notifying us that there's been an update to the PMR. Just imagine you upload 10 files to a PMR - for us it's like having the doorbell ring 10 times. Multiply that by the number of log files we could potentially get in a given day for all the PMRs in our queue and you can visualize how disruptive that can be when we're trying to focus on a problem. 

Now that you've gathered the logs from the day and time of the issue and you've zipped up everything requested in the "must gather" that applies to your situation, provide us with any key information that pertains to the problem. This can include a partner name, a protocol (HTTP, FTP, SFTP, etc.) an error message, an IP address or hostname, etc. Just keep in mind the more relevant information and data you provide to us from the start, the quicker we can resolve your issue.