However when you execute the check in an SSH session as the nagios user, it executes correctly.

Explanation

When you test the plugin in an SSH session, you are using a session that has environment variables loaded from your bash profile. This includes an extended PATH which allows bash to find the require modules.

In some environments, when the plugin is executed by the monitoring engine, these environment variables are not loaded and hence the plugin does not know where to find them and fails.

Define Global Environment Variables

In this solution, you will define variables required for you plugins globally.

Specifically:

Add the path /usr/local/important_application to the PATH environment

Add the variable ORACLE_HOME=/usr/lib/oracle/11.2/client64

This is performed by editing a specific file that nagios checks when it starts:

/etc/sysconfig/nagios

By default, this file does not exist, but you will create it just by opening vi to the file.

These operating systems use systemd which has a different method, referencing existing environment variables like $PATH will not work. If you wish to define the path, you will need to define the entire path variable (which is shown below).

The following is being applied:

Re-define the PATH environment to include /usr/local/important_application

Add the variable ORACLE_HOME=/usr/lib/oracle/11.2/client64

This is performed by editing a specific file that mod-gearman2-worker checks when the service starts:

RAM Disk

If you later configure Nagios XI with a RAM Disk using our installation script, the settings you just added will be lost. You will need to follow the steps above (Define Global Environment Variables) to re-add the environment variables and it will work again.

How Can I See The Environment Variables ?

One way to see what environment variables are present when the plugin executes is to create a simple plugin that will output them. From this you create a command and service and then you can see the result in the XI GUI.