Monitor an IBM i (OS/400) server as easily as any other server

An important part of any monitoring concept is the servers in the infrastructure. But there is still one server that is sometimes left out of a global monitoring concept: the IBM i server, also known as the OS/400 or iSeries. 

These servers are often managed by a dedicated team – or even by a single person – that is completely autonomous. Because this operating system is very stable, there are few elements monitored; if they are monitored, it is done using tools provided by the manufacturer. Moreover, it often happens that the teams that manage the global monitoring concept and the team responsible for the IBM i servers do not communicate with each other.

As a result, IBM i servers are often not integrated into the global monitoring policy implemented by the company. But this doesn't have to be the case.

This is a guest blog post by Pascal Ruckebusch of M81.

M81 and IBM i servers

The company M81 has developed the Control for i product to address this problem. M81 focuses on one of the main obstacles: IBM i administrators are very familiar with the operation of their system and the commands that need to be used, and they do not want to invest in open commands or settings that are too different from what they usually handle.

We have therefore developed controls in the form of native IBM i commands, which can be easily understood and used by the administrators of these systems. The link with PRTG is made by using a single plugin to which the IBM i specialists pass commands as parameters. 

How it works

The Control for i product must be installed on the IBM i server (the term used is "IBM i partition"), and an agent must be started. For IBM i specialists, this is a subsystem containing two jobs that must be active at all times. It provides "classic" IBM i commands that allow more than 150 checks to be performed. These controls are in the form of IBM i commands such as the CTCHKSBS command, which lets you check whether a subsystem is active or stopped, as well as if jobs that should be active in the subsystem are in fact active.

This command, like all the others, is based on the rules used by all standard IBM i commands. They will therefore seem natural to an IBM i administrator who will know how to use them immediately. They can be used on a 5250 session to test and validate parameters before being integrated into PRTG.

The domains covered by the commands delivered as standard with Control for i are numerous. The list below is not exhaustive:

• Monitoring of jobs and subsystems
  • Active subsystems
  • Active jobs
  • Jobs in MSGW (waiting for an answer to a message)
  • Jobs in LCKW (waiting for a lock)
  • Batch jobs successfully completed
  • Number of jobs in JOBQs
• Monitoring of other system components
  • Hardware problems
  • Disk space
  • CPU usage (possibly for a particular subsystem)
  • User profiles
  • Presence and size of objects in library or files in the IFS
  • Deadlines for certificates
  • Status of lines / controllers / devices
  • Number of spools in OUTQs
  • Library size and evolution
• Backup monitoring
  • Status of backups with or without BRMS
  • Tape availability for backups
• High availability monitoring
  • Mimix
  • Quick EDD
  • iTera
• ERP M3
  • There are several controls to monitor this ERP,
  • Including GRID
• Message monitoring
  • A very complete module with a fine parameterization allows the generation of alerts when messages are received in the MSGQ, in the system log, or in BRMS.
  • It is possible to set up actions (answer, call of a command or a program) that will be automatically performed.

If the IBM i administrator doesn’t find the right command, it’s also possible to use any existing RPG or CLP program to create a specific probe in a few minutes.

Integrating with PRTG

Once the IBM i administrator has made a list of the controls to be performed, finalized all the parameters for each control, and tested everything, they can either configure the controls in PRTG or pass this detailed list on to the person who will perform the PRTG configuration.

The link with PRTG is done with a unique plugin that must be placed in the directory C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXML.

As an example, let's take the IBM i command to check if there are jobs in error status that are waiting for a response to a message (jobs in MSGW state):

The procedure for creating the corresponding probe in PRTG is as follows:

Select "CUSTOM SENSORS" and then choose "EXE/Script Advanced".

Give the sensor a name:

Then select the name of the plugin (check_control4i_prtg.exe) and enter the IBM i command as part of the parameter for the plugin: 

The rest of the settings for this probe are PRTG specific and have nothing to do with the Control for i product.

Here's what the sensor looks like in PRTG:

Following the above procedure, you can add several sensors for various metrics:

With the Control for i product, IBM i servers and partitions can now be monitored by PRTG, and alerts can be managed by the team that already performs Level 1 for all other servers in the company.

The IBM i expert no longer needs to spend time constantly monitoring these points and can focus on more interesting tasks.