Using RPM logging to monitor and troubleshoot
When we first released RPM Remote Print Manager® ("RPM"), we included a rudimentary log so we could have a record for the customer to review, with incoming jobs and print status.
I felt it was important to know that if they left RPM running overnight and wanted to know what had happened, they should be able to tell at a glance whether the expected jobs had arrived and what time they printed. For instance, knowing the specific time could help them determine who walked off with it. That’s a troubleshooting call I hoped we could avoid!
I still remember my first exposure to the AS/400 when a customer called to say that RPM was not working correctly with their system. I asked them to turn on detailed logging for networking and send that to me. That’s how I learned that the print system on the AS/400 had different expectations than what I was used to in the Unix world. I could program around that and get the customer going, all because of basic logging.
Notably, we invested a substantial amount of effort in logging in the RPM 6.2 release. The current state of logging in RPM is that we have three logs:
- The message log, which lives in the RPM database along with job metadata and overall configuration (the job files themselves are on disk)
- The event log, which is an SQLite database in the RPM install folder
- Diagnostic logs, which are text files also found in the RPM install folder
The Message Log
The message log is the primary diagnostic tool that RPM maintains. But, since it lives in the database, it can be the most invisible of the three.
RPM is set up on its own to do a certain amount of logging to the message log, so you don’t need to do anything with it to use it. Many don’t know it’s there.
For an introduction, please review the message log page
For help with finding jobs that have already been processed, see What happened to my print jobs?
The Event Log
The event log is probably the most visible, as it lives in the corner of the user interface.
For an introduction, please review the event log page
The Diagnostic Log
The diagnostic log is part of most of the programs we ship with RPM, yet it is behind the scenes and takes extra steps to activate.
For an introduction, please review the diagnostic log page
Critical Events
The critical events log is supposed to be a small log, and we look to the user to remove items from the log when they are addressed. We don't limit the size of this log or remove items automatically.
Any time the user interface is opened, it will show all the critical events in order received with the most recent on top.
Note that the critical events page lists all the critical events along with our recommendations on what to do about each one.
These situations are for the user or system administrator to address. They are not errors from RPM; they are events that RPM reports.
A word of advice
If you could first consult with us about a problem you experience to get our advice on what logs to send and which diagnostic log settings to use, it would probably save us a great deal of time and help you get your resolution.
It’s not helpful to send a log file without any idea what we need.
It’s even less helpful to send us a file with diagnostic log settings from another unrelated problem but nothing related to the problem you are now experiencing.