Configuration

To configure your Nagios and JNRPE environments to monitor DirX Identity servers:

  • Deploy the DirX Identity plugins to the JNRPE server.

  • Configure the JNRPE and Nagios servers to support DirX Identity plugin execution.

JAVA 11 Support

Currently, no JNRPE for JAVA11 is available.

Starting the JNRPE server gives some warnings with JAVA11:

An illegal reflective access operation has occurred
Illegal reflective access by io.netty.util.internal.PlatformDependent0(file:/D:/Program%20Files/JNRPE/lib/netty-all-4.0.19.Final.jar) to field java.nio.Buffer.address
Please consider reporting this to the maintainers of io.netty.util.internal.PlatformDependent0
Use --illegal-access=warn to enable warnings of further illegal reflective access operations
All illegal access operations will be denied in a future release

You can suppress these warnings by using the following options in the java call:

--add-opens java.base/java.nio=ALL-UNNAMED --add-opens java.base/sun.nio.ch=ALL-UNNAMED

For example, add these options to the %JAVACMD% line in the jnrpe.bat file.

Starting could also fail, because of the included YAJSW 11.04. You must replace the version 11.04 with version 12.16:

  1. Download YAJSW 12.6 from here:
    https://sourceforge.net/projects/yajsw/files/yajsw/yajsw-stable-12.16/yajsw-stable-12.16.zip/download

  2. Rename the folder JNRPE_install_path/wrapper to JNRPE_install_path/wrapper-11.04

  3. Unzip the file yajsw-stable-12.16.zip.

  4. Rename the new folder yajsw-stable-12.16 to wrapper.

  5. Move this folder wrapper to JNRPE_install_path/

  6. Copy the folder JNRPE_install_path/wrapper-11.04/etc into the new folder JNRPE_install_path/wrapper/.

If a JNRPE version supporting JAVA11 is available these workarounds are obsolete.

Deploying the DirX Identity Plugins

The DirX Identity installation provides the JNRPE plugin folder in dxi_install_path/nagiosSupport/dxiplugin. All of the required jar files are included in this folder.

To deploy the plugins to your JNRPE environment, simply copy this folder to the JNRPE_install_path/plugins subdirectory. Refer to the JNRPE documentation for details about JNRPE server directory structure.

Deploying the JNRPE plugins on Linux works without any further action.

On Windows, you may need to specify the CLASSPATH_PREFIX environment variable. Refer to all jar files in the JNRPE_install_path/plugins subdirectory.

Configuring the JNRPE Server

In Nagios and JNRPE, a "command" is an instance of a plugin that is configured with an explicit command line to invoke the plugin to perform a specific task. The JNRPE configuration file JNRPE_install_path/etc/jnrpe.ini is the repository for all of the commands available for execution by the JNRPE Server.

Each command definition follows the format:

Command Name : Plugin Name : Command Line

In Command Line parameters, you can supply hard-coded values or variables in the form $ARG*n$* to be resolved with specific values at execution time.

See the JNRPE documentation for complete details about JNRPE command syntax.

To configure your JNRPE installation to monitor DirX Identity servers with the DirX Identity Nagios plugins, update the JNRPE_install_path/etc/jnrpe.ini file in your JNRPE server environment to define your JNRPE commands. These commands can call the DirX Identity plugins or standard JNRPE plugins to check DirX Identity servers and other JMX-enabled servers like Tomcat and ActiveMQ.

The connection to the JMX interfaces are done with SSL/TLS. Make sure that the necessary certificate of the certification authority, which has signed the server certificates of the JMX interfaces, are included in the cacerts certificate store of the java implementation, which is used for running the JRNPE server.

We provide a sample jnrpe.ini file in dxi_install_path/nagiosSupport]/samples/JNRPE.

The next sections describe the sample command definitions given in this file and show examples of their use when run from the JNRPE interactive console.

CHECK_ADAPTOR and CHECK_ADAPTORBYNAME Commands

These commands check the outstanding responses of a specific JMS adaptor. The sample CHECK_ADAPTOR command is configured to check the ProvisioningRequestListener (see the --object parameter). The CHECKADAPTORBYNAME command accepts a JMS adaptor name as an argument.

Command Definitions

CHECK_ADAPTOR : DXI_CHECK_JMX --url service:jmx:rmi:///jndi/rmi://$ARG1$:$ARG2$/jmxrmi --object com.siemens.idm:type=idsj,topic=adaptor,name=ProvisioningRequestListener --attribute outstandingResponses --warning $ARG3$ --critical $ARG4$ --username domainadmin --password $ARG5$

CHECK_ADAPTORBYNAME : DXI_CHECK_JMX --url service:jmx:rmi:///jndi/rmi://$ARG1$:$ARG2$/jmxrmi --object com.siemens.idm:type=idsj,topic=adaptor,name=$ARG3$ --attribute outstandingResponses --warning $ARG4$ --critical $ARG5$ --username domainadmin --password $ARG6$

Arguments

The CHECK_ADAPTOR command takes the following arguments:

  • ARG1 - Host.

  • ARG2 - JMX port.

  • ARG3 - Warning level.

  • ARG4 - Critical level.

  • ARG5 – Password for JMX authentication with user domainadmin.

The CHECKADAPTORBYNAME command takes the following arguments:

  • ARG1 - Host.

  • ARG2 - JMX port.

  • ARG3 – Name of the JMS adaptor to check.

  • ARG4 - Warning level.

  • ARG5 - Critical level.

  • ARG6 – Password for JMX authentication with user domainadmin.

Examples

This example shows that there are no outstanding messages for the ProvisioningRequestListener adaptor by using the low water mark (900) as the warning level and the high water mark (1000) as the critical level:

JNRPE> command:CHECK_ADAPTOR localhost 39999 900: 1000: dirx
Value: 0
DXI_CHECK_JMX : OK - outstandingResponses is : 0|State=0,000000;900:;1000:;0,00000
0

This example simulates a warning by defining the warning level to 0:

JNRPE> command:CHECK_ADAPTOR localhost 39999 0: 1000: dirx
Value: 0
DXI_CHECK_JMX : WARNING - outstandingResponses is : 0|State=0,000000;0:;1000:;0,00
0000:

This example uses CHECK_ADAPTORBYNAME to check the EntryChangeListener adaptor:

JNRPE> command:CHECK_ADAPTORBYNAME localhost 39999 EntryChangeListener 900: 1000 dirx
:
Value: 0
DXI_CHECK_JMX : OK - outstandingResponses is : 0|State=0,000000;900:;1000:;0,00000
0

This example generates an error for CHECK_ADAPTORBYNAME by using the unknown adapter name EntryChangeListenerxx:

JNRPE> command:CHECK_ADAPTORBYNAME localhost 39999 EntryChangeListenerxx 900: 1000: dirx
DXI_CHECK_JMX : CRITICAL - An error has occurred during execution of the DXI_CHECK_JMX plugin returning 0 , error : com.siemens.idm:type=idsj,topic=adaptor,name=EntryChangeListenerxx
JNRPE>

CHECK_CSERV and CHECK_CSERVATT Commands

These commands check the state of the C++-based Server (IdS-C) (CHECK_CSERV) or the specified C++-based Server attribute (CHECK_CSERVATT). The State attribute is currently the only C++-based Server attribute that is meaningful to check.

Command Definitions

CHECK_CSERV : DXI_CHECK_CSERVER --host $ARG1$ --port $ARG2$ --attribute State --warning $ARG3$ --critical $ARG4$

CHECK_CSERVATT : DXI_CHECK_CSERVER --host $ARG1$ --port $ARG2$ --attribute $ARG3$ --warning $ARG4$ --critical $ARG5$

Arguments

The CHECK_CSERV command takes the following arguments:

  • ARG1 - Host.

  • ARG2 - JMX port. See the section "Identifying the JMX Ports of DirX Identity Servers" for information on how to determine a C++-based Server’s JMX port.

  • ARG3 - Warning level.

  • ARG4 - Critical level.

Examples

Here is an example of the CHECK_CSERV command that checks whether or not the server is available:

JNRPE> command:CHECK_CSERV  localhost  5315 :6 ~:3
Value: 10
DXI_CHECK_CSERVER : OK - State is : 10|State=10,000000;:6;~:3;-2,000000

Here is an example of the CHECK_CSERVATT that provides State as the attribute name:

JNRPE> command:CHECK_CSERVATT  localhost  5315 State :6 ~:3
Value: 10
DXI_CHECK_CSERVER : OK - State is : 10|State=10,000000;:6;~:3;-2,000000

CHECK_IDSJ Command

This command checks the state of the Java-based Server (IdS-J).

Command Definition

CHECK_IDSJ : DXI_CHECK_JMX --url service:jmx:rmi:///jndi/rmi://$ARG1$:$ARG2$/jmxrmi --object com.siemens.idm:type=idsj,topic=core,name=Server --attribute State --warning $ARG3$ --critical $ARG4$ --username domainadmin --password $ARG5$

Arguments

This command takes the following arguments:

  • ARG1 - Host.

  • ARG2 - JMX port.

  • ARG3 - Warning level.

  • ARG4 - Critical level.

  • ARG5 – Password for JMX authentication with user domainadmin.

Examples

Here is an example command that shows that the state of the Java-based Server is good:

JNRPE> command:CHECK_IDSJ localhost 39999 :6  :3 dirx
Value: 8
DXI_CHECK_JMX : OK - State is : 8|State=8,000000;:6;:3;0,000000

Here is an example command that shows that Java-based Server is down:

JNRPE> command:CHECK_IDSJ localhost 39999 :6  :3 dirx
DXI_CHECK_JMX : CRITICAL - An error has occurred during execution of the DXI_CHECK_JMX plugin returning 0 , error : Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is:
    java.net.ConnectException: Connection refused: connect]
JNRPE>

CHECK_JMXMEM Command

This command uses the standard JNRPE plugin CHECK_JMX to check the standard JVM memory usage attribute. You can use this command to check any Java application; you only need to select the correct JMX port. The section "Identifying the JMX Ports of DirX Identity Servers" provides instructions for determining the JMX ports for DirX Identity Servers.

Command Definition

CHECK_JMXMEM : CHECK_JMX --url service:jmx:rmi:///jndi/rmi://$ARG1$:$ARG2$/jmxrmi --object java.lang:type=Memory --attribute HeapMemoryUsage -K used -I HeapMemoryUsage -J used --warning $ARG3$ --critical $ARG4$ --username domainadmin --password $ARG5$

Arguments

The CHECK_JMXMEM command takes the following arguments:

  • ARG1 - Host.

  • ARG2 - JMX port.

  • ARG3 - Warning level.

  • ARG4 - Critical level.

  • ARG5 – Password for JMX authentication with user domainadmin (optional).

CHECK_TOMCAT Command

This command uses the standard JNRPE plugin CHECK_TOMCAT to check the Tomcat server. See the CHECK_TOMCAT JNRPE plugin documentation for details.

CHECK_WF and CHECK_WF_EXC Commands

These sample commands check a statistics attribute of the specified workflow. The command definitions given here specify the Export Users to LDIF workflow in the --object parameter. When specifying a different workflow name, be sure to enclose it in double quotation marks (") because workflow names contain blank spaces.

Command Definitions

CHECK_WF : DXI_CHECK_JMX --url service:jmx:rmi:///jndi/rmi://$ARG1$:$ARG2$/jmxrmi --object "com.siemens.idm:type=idsj,topic=core,name=Statistics,name0=My-Company,name1=Provisioning,name2=Source Realtime,name3=LDIFfile,name4=Export Users to LDIF" --attribute $ARG3$ --warning $ARG4$ --critical $ARG5$ --username domainadmin --password $ARG6$

CHECK_WF_EXC : DXI_CHECK_JMX --url service:jmx:rmi:///jndi/rmi://$ARG1$:$ARG2$/jmxrmi --object "com.siemens.idm:type=idsj,topic=core,name=Statistics,name0=My-Company,name1=Provisioning,name2=Source Realtime,name3=LDIFfile,name4=Export Users to LDIF" --attribute $ARG3$ --warning $ARG4$ --critical $ARG5$ --ExceptionState $ARG6$ --username domainadmin --password $ARG7$

Arguments

The CHECK_WF and CHECK_WF_EXC commands take the following arguments:

  • ARG1 - Host.

  • ARG2 - JMX port.

  • ARG3 - Attribute name (for example, join.SUCCEEDED, join.AddFailed).

  • ARG4 - Warning level.

  • ARG5 - Critical level.

  • ARG6 (CHECK_WF_EXC only) - Exception definition. Defines whether an exception (for example, "counter not available" or "server not reachable") should be treated as UNKNOWN (u), CRITICAL (c), WARNING (w) or OK (o).

  • ARG6 (CHECK_WF only) – Password for JMX authentication with user domainadmin.

  • ARG7 (CHECK_WF_EXC only) – Password for JMX authentication with user domainadmin.

Examples

This example checks the join.SUCCEEDED attribute and sets the warning and critical values to simulate a warning:

JNRPE>  command:CHECK_WF localhost 39999 join.SUCCEEDED 1: 2: dirx
Value: 1
DXI_CHECK_JMX : WARNING - join.SUCCEEDED is : 1|State=1,000000;1:;2:;0,000000
JNRPE>

This example checks the join.SUCCEEDED attribute and shows that the workflow has never been started because the counter is not available. Because u is the specified exception definition, UNKNOWN is returned:

JNRPE>  command:CHECK_WF_EXC localhost 39999 join.SUCCEEDED 1: 2: u dirx
DXI_CHECK_JMX : UNKNOWN - An error has occurred during execution of the DXI_CHEC
K_JMX plugin returning 0 , error : com.siemens.idm:type=idsj,topic=core,name=Sta
tistics,name0=My-Company,name1=Provisioning,name2=Source Realtime,name3=LDIFfile
,name4=Export Users to LDIF

Identifying Java-based Server Attributes to Check

You can use the standard JMX console (JConsole) graphical monitoring tool included in the Java Development Kit (JDK) to identify the name of the Java-based Server attribute you want to check. For example, let’s look at the CHECK_WF command. The workflow object name configured in this command is:

jmxrmi --object "com.siemens.idm:type=idsj,topic=core,name=Statistics,name0=My-Company,name1=Provisioning,name2=Source Realtime,name3=LDIFfile,name4=Export Users to LDIF"

This workflow name is displayed in JConsole at the following location:

nagios-support/media/image4

In the Name column of the right-hand pane, ObjectName contains the name needed for configuring the DXI_CHECK_JMX plugin’s jmxrmi --object parameter.

The attribute name (here, join.EventRequestProcessedFailed) can be found in JConsole at this location:

image5

In the Attribute value section, the Name column contains the attribute name needed for configuration.

Identifying the JMX Ports of DirX Identity Servers

To obtain the JMX port for a Java-based Server, examine the following parameter in the INI file dxi_install_path/ids-j-domain-Sn/bin/idmsvc.ini:

-DIDM_JMXPORT=40005

For example:

15=-DIDM_JMXPORT=40005

For more information, see the section "Java-based Server INI File Parameters" in the chapter "Managing DirX Identity Servers" in the DirX Identity Connectivity Administration Guide.

Or look in the configuration.ini file in dxi_install_path for parameter
IdS-J.jmx_port=40005

To obtain the JMX port for a C++-based Server, use the DirX Identity Manager:

  • Log in to the DirX Identity Manager and select the Connectivity View.

  • In the Connectivity View, select the C Server object in the tree (in DirX Identity Servers → C Servers) and then click the JMX Access tab.

  • In JMX Service, follow the link to the JMX Service object (by clicking the Properties icon) and then use the value given in Data Port (in the Connection Parameters section).

For more information, use the DirX Identity Manager context-sensitive help.

Configuring Nagios

To configure a Nagios installation for JNRPE plugin execution:

  • Define the call to the JNRPE server in nagios_install_path/nagios/etc/objects/commands.cfg

  • Define the services you want to make available from the Nagios Web interface in nagios_install_path/nagios/etc/objects/localhost.cfg

We provide some Nagios configuration files in dxi_install_path/nagiosSupport/samples/. The JNRPE subfolder contains JNRPE configuration samples, while the Nagios subfolder contains samples for the Nagios configuration.

Defining the JNRPE Call

In the Nagios commands.cfg file, define the call to the JNRPE server. Provide the command name and the command line. Here is an example:

define command{
        command_name    jcheck_nrpes
        command_line    $USER1$/jcheck_nrpe -H $ARG1$ -p 5667 -t $ARG2$ -c $ARG3$ -a $HOSTADDRESS$ $ARG4$ $ARG5$ $ARG6$ $ARG7$ $ARG8$ $ARG9$
        }

See the Nagios documentation for a description of command definition format.

Defining the Services

In the Nagios localhost.cfg file, define the JNRPE commands that you want to make available as "services" from the Nagios Web interface. Provide a name for the service, specify the JNRPE command name you defined in the JNRPE server jnrpe.ini file that Nagios is to run and provide values for arguments to the command line.

This example defines a service named "JNRPE SSL IDSJ-Status" that calls the CHECK_IDSJ JNRPE command to check the state of an IdS-J server running on a host (the given password is used to authenticate via JMX):

define service{
        use                            local-service     ; Name of service template to use
        host_name                      hostname
        service_description            JNRPE SSL IDSJ-Status
        check_command                  jcheck_nrpes!JNRPE_host!10!CHECK_IDSJ!40005!:6!:3!<password for JMX authentication to ids-j>
        notifications_enabled           0
        }

This example defines a service named "JNRPE SSL MEM on IDSJ" that calls the CHECK_JMXMEM JNRPE command to check the standard JVM memory usage attribute for java-based DirX Identity server running on a remote host:

define service{
        use                             local-service         ; Name of service template to use
        host_name                       distributed_host_A
        service_description             JNRPE SSL MEM on IDSJ
        check_command                   jcheck_nrpes!JNRPE_host!10!CHECK_JMXMEM!40005!4248302272!5498760192!<optional password for JMX authentication to ids-j>
        notifications_enabled           0
        }

See the Nagios documentation for a description of service definition format.