EM4i is great for monitoring IBM i messages and getting responses from users without requiring them to sign on. But we’ve been asked a number of times whether we could bring EM4i and AAG together, allowing EM4i messages to be sent directly into Nagios instead of—or as well as—to individual users.
The idea is straightforward. Nagios receives the message together with the EM4i response link. An operator viewing the message in the Nagios interface can respond directly, while notifications generated by Nagios can also include the response link, allowing the recipient to answer the IBM i message without signing on.
Initially, we questioned the value of this. EM4i can already send messages directly to the users who need to respond, so why add Nagios into the process?
The answer is centralised management.
If Nagios is already your central monitoring and notification platform, it makes sense to manage the distribution of IBM i alerts there as well. When someone joins, leaves or changes responsibilities, you can update the notification configuration in Nagios rather than maintaining the same information separately in both Nagios and EM4i.
There are already several ways to get IBM i messages into Nagios. You can use the standard AAG checks to pull messages directly from the IBM i, or use the EM4i checks and take advantage of EM4i’s filtering to ensure Nagios only sees the messages that actually matter.
Alternatively, as we demonstrated in a previous post on real-time IBM i monitoring, you can build your own message queue monitors and use NG4i commands to push those events directly into Nagios.
This new approach is slightly different.
Rather than Nagios finding or monitoring the messages, we are simply adding Nagios as another EM4i delivery target, in much the same way that EM4i currently supports *EMAIL, *SMS and *PUSHOVER.
Configuration is simple. Create an EM4i user and set the preferred send method to *NAGIOS. From that point, messages flow through the normal EM4i processing and filtering, but instead of being delivered directly to an individual service, they are sent to Nagios.
NG4i needs to be installed and configured on the IBM i because EM4i uses the NG4i SNDSVCCHK command to send the message data to the Nagios server. This also means we can take advantage of the existing secure passive-check infrastructure already provided by NG4i.
Testing the new integration
For our test, NG4i was already installed and configured to send passive check data to Nagios, so the foundation was already in place.
We then configured an EM4i user with *NAGIOS as the preferred delivery method and allowed EM4i to process messages exactly as it normally would. The difference is that selected IBM i messages now appear within Nagios, complete with the information required for an operator—or the recipient of a Nagios notification—to respond to the original IBM i message.
The result brings together two complementary capabilities: EM4i decides which IBM i messages matter and provides the response mechanism; AAG and Nagios provide the central monitoring, notification and distribution platform.
For organisations already using Nagios as their operational dashboard, that means fewer places to maintain notification lists, less duplication of administration, and another step towards managing IBM i by exception rather than continually watching the system.
EM4i setup
The only thing required in EM4i is to create the Nagios User, this will have a preferred send method of *NAGIOS as can be seen in the screen below. The name and nickname do not matter and the user does not have to exist on the IBM i.
Next we need to add the User to a distribution list. We have created a new distribution list with just Nagios on it.
We have only added a single user to the distribution list, but you can added as many as you wish, because the send method is defined at the message level every user in the distribution list will have messages sent via their preferred send method.
Int the message configuration enter the Send by method as *USRDEF and make sure you set the correct distribution list.
NG4i setup
NG4i needs to be configured to send passive check data to the Nagios Server, below is an example of configuring NG4i (Operations menu, NRDP menu Option 1) with the required information, we have changed the API token (it can be found on the Nagios Server under Admin,inbound transfers,NRDP).
Note: The Nagios check name sent to Nagios XI will always be hostname_check_EM4i_MSG, the Hostname below will result in SAS1002_check_EM4i_MSG.
You do not have to restart NG4i after configuring the NRDP settings.
Nagios XI setup
We are using Nagios XI in this instance, however we have tested with our own Nagios Core stack with NRDP installed and it works just as well. There is a Wizard provided to configure a passive check in Nagios XI, in Nagios Core you will need to configure each part manually.
Click on the passive check wizard (Configure, configuration wizards), this will provide the following screen
Enter the address of your host, it must match the Hostname that you will be sending the passive check data from (see the host name in the 5250 screen above). click next.
Provide the Service Name that you are going to set up.
Note: the name will always be Hostname_check_EM4i_MSG.
Press next and the following screen will be shown, you can press finish with defaults at this stage.
Now that we have EM4i, NG4i and Nagios set up we can test with a *INQ message using the command provided with EM4i for send test *INQ messages to QSYSOPR.
When you look at the EM4i jobs you will see that for a *INQ message the MSGPOL job is now going into a DLY, this is because this job is reaching out to the web site looking for a response to the message we just sent.
When you look at the QSYSOPR message queue you can see that the message we just sent is sitting there waiting for a response.
When we look at the Service status on Nagios XI we can see that a message has been received and is waiting for a response. You will see a respond link in the message text, clicking this will display a web form allowing you to respond to the message directly from Nagios (right click the link to push the request to a new tab).
Clicking the link will return the familiar we form that allows a response to be taken for the message, you can only enter the allowed values for the message response.
In this case the only responses allowed are ‘Y’ or ‘N’, select the appropriate response and press send.
You will see a confirmation form stating that the message response has been sent to the web server ready for the IBM i polling job to pull it back.
Once the poller has pulled the message back to the IBM i it will pass the response back to the message. You will see the message in QSYSOPR has now had the appropriate response taken.
If there are no more messages waiting for a response the poller job will now go back to DEQW waiting for the next message to be sent to the web server for a response.
As you can see Nagios, AAG and EM4i can work together to provide a rounded solution for you systems management and Dev Ops needs.
Call and book a demo, happy to show what EM4i and Nagios can achieve together.