These plugins will let you monitor the following:

• ports
• send ports
• queues
• location
• orchestration
• cluster host instance process
• spool size
• msdtc process

Service checks för check_biztalk plugin

Port for the MSSQL server that BizTalk uses

define command{
command_name check_biztalk_ports
command_line $USER1$/check_biztalk -U $USER11$ -P $USER12$ -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p
}

Critical-range for queues

define command{
command_name check_biztalk_queues
command_line $USER1$/check_biztalk -U $USER11$ -P $USER12$ -H $HOSTADDRESS$ -W $ARG1$ -C $ARG2$
}

Specific receive location(s) to check, comma-separated

define command{
command_name check_biztalk_specific_locations
command_line $USER1$/check_biztalk -U $USER11$ -P $USER12$ -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -l $ARG3$
}

Critical-range for orchestrations

define command{
command_name check_biztalk_orchestration
command_line $USER1$/custom/check_biztalk -U $USER11$ -P $USER12$ -H $HOSTADDRESS$ -o $ARG1$ -O $ARG2$
}

Critical-range for sendports

define command{
command_name                   check_biztalk_sendports
command_line                   $USER1$/custom/check_biztalk -U $USER11$ -P $USER12$ -H $HOSTADDRESS$ -d $ARG1$ -D $ARG2$
}

Service check för check_biztalk_cluster_host_instance plugin

Cluster instances running

define command{
command_name check_biztalk_cluster_host_instance
command_line $USER1$/custom/check_biztalk_cluster_host_instance $ARG1$
}

Service check for check_biztalk_msdtc

Check the active instance

define command{

command_name check_biztalk_msdtc
command_line $USER1$/custom/check_biztalk_msdtc $ARG1$
}

Service check for check_nrpe plugin

Tracks the size of the spool for all message box.

define command{
command_name check_biztalk_spool_size
command_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c CheckCounter -a ‘Counter:Spool Size=\BizTalk:Message Box:GeneralCounters(biztalkmsgboxdb:sevmcoinsql)\Spool Size’ ShowAll MaxWarn=$ARG1$ MaxCrit=$ARG2$
}

Notes: For more performance counter relate to Biztalk, visit Microsoft Technet.

Remarks

The mentioned plugins above have not been fully tested with all Biztalk versions, thus means that the variables passed to the plugin or the functionality can differ in your environment.

REV 2, 2012-05-07

Prerequisites

Download NRPE client from our repository and install it on your server. You can follow the installation manual even if it’s not written for the version of NRPE you run.

Adding the server and basic checks

Now are you ready to add your new RHEL server to op5 Monitor.

1. Login to your op5 Monitor and go to ‘Configure’ -> ‘New host’
2. Fill in all information about your server and  in the ‘Service Checks’ section, select ‘Add UNIX Client Services(NRPE)’. Then click on ‘Adding services’.  This will scan your server for some basic checks.
   
3. In the next window you will get a list of services. Choose ‘Select all’ or individuals depending of your needs. Then click on ‘Finish’.
   
   • Network checks “Net”  example
   • Ping
   • SSH Server
   • HTTP Server
   • HTTPS Server
   • MySQL
   • NRPE agent checks example
   • Current users
   • System load
   • Disk usage
   • Total processes
   • Swap usage

    

4. Save your changes.
5. Done

Note: You may need to do minor changes to the services you add, depending on how your server is configure.

Additional checks

There are many checks and plugins from op5 or Nagios Exchange community that could meet your needs. On op5.com you can find many resources like manuals, FAQ’s, webcasts and how-to’s on how to efficiently monitor a range of various hardware, services or applications in your Redhat environment.

Some resources example

JMX aplication server: HOW TO MONITOR YOUR APPLICATION SERVER WITH OP5 MONITOR AND JMX4PERL

HP/Compaq servers: MONITORING HP/COMPAQ SERVERS

RHEV 2: HOW-TO MONITOR A KVM INSTALLATION

IPMI sensor: HOW-TO MONITOR A SERVER WITH ENHANCED IPMI SENSOR

Webinject: MONITORING WEBSITES WITH WEBINJECT

FAQ – search for: Redhat

Op5 supported plugins: LIST OF PLUG-INS.

Inspiration

If you are in need of some inspiration we recommend you to browse our live demo-environment. The live demo reflects an real environment that is currently in production.

Need assistance?

Please do not hesitate to contact our support if you have any questions or feedback in regards to the how-to’s or plug-ins.

REV 2, 2012-05-09

Prerequisities

• op5 Monitor Enterprise with op5 Trapper Extension

Configuration

1. Configure your Cisco devices to send traps to op5 Monitor.
   # snmp-server enable traps
   # snmp-server host monitor-server-ip public snmp syslog
2. op5 Monitor Trapper Extension configuration:

• Create a host and a service for your trapper sending device. The service need to be added manually for this example to work. Set the service to “Active checks disabled”

host_name: “op5-system”
service_name: “Interface linkstatus”

• Log on to your op5 Monitor server with ssh and create the directory where you will place your rules. The rules you will create below is to update the handler, after the handler is updated trapper won’t be using those until you’ll need to update your handler after changes or modifications.

# mkdir /opt/trapper/share/addons/cisco-syslog

• Use your favorite editor to add the following (“vi” in this example)

# vi /opt/trapper/share/addons/cisco-syslog/cisco-syslog.lua

• Copy/paste the following handler:

–result.host = string.match(trap.host, ‘^([%w-%d]+)\.’) or trap.host
result.host = trap.host
log(‘Trap from: ‘ .. trap.host)
log(‘Resulting host: ‘ .. result.host)
for k, v in pairs(trap.fields) do
        if string.match(k,’^\.1\.3\.6\.1\.4\.1\.9\.9\.41\.1\.2\.3\.1\.3\.(%d+)$’) then
               log(‘Trap severity is: ‘ .. tostring(v))
               if v == 8 or v == 7 or v == 6 then
               result.state = STATE.OK
       elseif v == 5 then
               result.state = STATE.WARNING
       elseif v == 4 or v == 3 or v == 2 or v == 1 then
               result.state = STATE.CRITICAL
       end
               log(‘Severity to state: ‘ .. result.state)
       elseif string.match(k,’^\.1\.3\.6\.1\.4\.1\.9\.9\.41\.1\.2\.3\.1\.4\.(%d+)$’) then
               log(‘Trap type is: ‘ .. tostring(v))
               if v == “UPDOWN” then
                       result.service = “Interface linkstatus”
               elseif v == “DUPLEX_MISMATCH” then
                       result.service = “Interface duplex status”
               elseif v == “foobar” then
                       result.service = “Interface foobar”
               else
                       result.service = “All traps”
               end
               log(‘Result service is: ‘ .. result.service)
       elseif string.match(k,’^\.1\.3\.6\.1\.4\.1\.9\.9\.41\.1\.2\.3\.1\.5\.(%d+)$’) then
               local message = v
               log(‘Trap message is: ‘ .. message)
               result.message = message
               result.tag = (string.sub(v, string.find(v,’[%u%l+]+Ethernet[%d+/%d+/%d+]+’)))
               log(‘Tag matching: ‘ .. result.tag)
       end
end

• Save the handler.

Note: This handler, when loaded will match all traps of the type (Cisco Syslog MIB) and set severity in Monitor as stated above.

• Next, add the handlers we just created to trapper and tell how and when to use them.

• Create the handler:

# /opt/trapper/bin/traped create handler cisco-syslog

• Update handler with the information we entered earlier:

# /opt/trapper/bin/traped update cisco-syslog < /opt/trapper/share/addons/cisco-syslog/cisco-syslog.lua

• Verify that your handler are there:

# /opt/trapper/bin/traped list handlers
cisco-syslog

• Next we need to tell trapper which OIDs should be associated with these handlers:

# /opt/trapper/bin/traped bind .1.3.6.1.4.1.9.9.41.2* cisco-syslog

• And verify that your handler are listed as below:

# /opt/trapper/bin/traped list matches
.1.3.6.1.4.1.9.9.41.2*          cisco-syslog

• Next restart trapper:

# service trapper restart

Example

• Now when you have create a handler you can test it with the following test case and see in Monitor and logs the result.

• From the command promt in your op5 Monitor server run the following(It is a one line command).
  # /usr/bin/snmptrap -c public -v 2c op5-system ‘ ‘ .1.3.6.1.4.1.9.9.41.2 \
  .1.3.6.1.4.1.9.9.41.1.2.3.1.3.4435 i 4 \
  .1.3.6.1.4.1.9.9.41.1.2.3.1.2.4435 s “LINEPROTO” \
  .1.3.6.1.4.1.9.9.41.1.2.3.1.4.4435 s “UPDOWN” \
  .1.3.6.1.4.1.9.9.41.1.2.3.1.5.4435 s “Line protocol on Interface GigabitEthernet1/0/13, changed state to down” \

• Take a look at your op5 Monitor SNMP trapps page. There will you see a row with the test trapp in a down state

• You can even see logs from trapper-connector (receiving) and trapper-processor (handling) in /var/log/messages (as stated in the handlers “log()”), like this:

May  8 13:33:53 ps-beta64 trapper-collector[23031]: 2012-05-08 13:33:53 op5-system [UDP: [127.0.0.1]:45491->[127.0.0.1]:162]: .1.3.6.1.2.1.1.3.0 = Timeticks: (112068399) 12 days, 23:18:03.99   .1.3.6.1.6.3.1.1.4.1.0 = OID: .1.3.6.1.4.1.9.9.41.2     .1.3.6.1.4.1.9.9.41.1.2.3.1.3.4435 = INTEGER: 4 .1.3.6.1.4.1.9.9.41.1.2.3.1.2.4435 = STRING: “LINEPROTO”.1.3.6.1.4.1.9.9.41.1.2.3.1.4.4435 = STRING: “UPDOWN”    .1.3.6.1.4.1.9.9.41.1.2.3.1.5.4435 = STRING: “Line protocol on Interface GigabitEthernet1/0/13, changed state to down”
May  8 13:33:54 ps-beta64 trapper-processor: Received SNMP trap with OID: .1.3.6.1.4.1.9.9.41.2
May  8 13:33:54 ps-beta64 trapper-processor: SNMP trap matches handler: cisco-syslog
May  8 13:33:54 ps-beta64 trapper-processor: Trap from: op5-system
May  8 13:33:54 ps-beta64 trapper-processor: Resulting host: op5-system
May  8 13:33:54 ps-beta64 trapper-processor: Trap severity is: 4
May  8 13:33:54 ps-beta64 trapper-processor: Severity to state: 2
May  8 13:33:54 ps-beta64 trapper-processor: Trap type is: UPDOWN
May  8 13:33:54 ps-beta64 trapper-processor: Result service is: Interface linkstatus
May  8 13:33:54 ps-beta64 trapper-processor: Trap message is: Line protocol on Interface GigabitEthernet1/0/13, changed state to down
May  8 13:33:54 ps-beta64 trapper-processor: Tag matching: GigabitEthernet1/0/13
May  8 13:33:54 ps-beta64 trapper-processor: SNMP trap handler executed.
May  8 13:33:54 ps-beta64 trapper-processor: Context is {}

Below with comments:

trapper-processor: SNMP trap matches handler: cisco-syslog

• Handler matched

trapper-processor: Trap from: op5-system

•  Trap originator (resolved FQDN)

trapper-processor: Map to hostname: op5-system

•  Handler removed domain info

trapper-processor: Map to service: SNMP Traps and Notifications

•  Destination service in Monitor

trapper-processor: Trap severity is: 4

•  Trap severity set by device / MIB

trapper-processor: Severity to state: 2

•  This we translated to op5 Monitor severity 2 (DOWN)

• If we take a look in op5 Monitor log files /opt/monitor/var/nagios.log you will see the result submitted by trapper to Monitor and the service will be updated with the actual status.

[1331841880] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;op5-system;SNMP Traps and Notifications;1;duplex mismatch discovered on FastEthernet0/7 (not full duplex), with op5-system.op5.com GigabitEthernet0/1 (full duplex).

Note: If you see a message below this line saying something similar to “host could not be found/host missing/unknown host” or “service missing/unknown” the problem is most likely caused by the hostname resolved by trapper is not configured in op5 Monitor or it could be configured using a different name.

Remark

When all is verified and works as expected be sure to comment out the rows starting with “log(” in the handlers to reduce the logging to messages.
Simply add “–log(” to comment out those lines and update your handler:

# /opt/trapper/bin/traped update cisco-syslog < /opt/trapper/share/addons/cisco-syslog/cisco-syslog.lua

REV 1, 2012-05-09

.

Prerequisites

Choose a suitable PNP Graph, you need the URL for the PNP graph that you want to show in the widget.

1. Navigate to the graphs page of the service check that you want to add.
2. Right-click on the graph with the time interval that you wish to use and copy the image URL.
   Please note: Internet Explorer is not able to handle the special type of URL for the image.
3. Open a text editor such as Notepad, and add square brackets [ ] around the URL

Remove the “&start=1332313814&end=1332328214″ from the URL, otherwise only a fixed time interval is displayed. The URL should look like the following:

[https://<ip-to-monitor>/monitor/op5/pnp/image?host=<host>&srv=<service-check>&view=0&source=0]

.

.

Create a NagVis Map with a PNP Graph

1. Navigate to NagVis.
2. In the box “Create map” type something meaningful.
3. Click the “Create” button.

Add the PNP Graph

1. Choose menu option Map –> Add Icon –> Service
2. Click somewhere on the map
3. host_name: choose the host
4. service_description: choose the service you want to use
5. view_type: choose “gadget”
6. gadget_url: choose “>>Manual input…”
• Paste the URL with the brackets around it
7. Click the “Save” button
8. Drag the PNP graph to an appropriate to the upper left corner

Remove the Background

You can remove the background if you wish to be able to slim down the size of the map and the widget.

1. Choose menu option Map –> Map Options
2. map_image: choose ”>>Manual input…” and delete any text
3. Click the “Save” button

Optional: Include More than One PNP Graph

Just follow the steps above and add another PNP graph.

.

.

Optional: Add the NagVis Map in a Widget in the Tactical Overview

1. Navigate to the Tactical Overview
2. Collapse and move the NagVis widget down to the three column field.
3. Click the “Edit this widget” icon
4. Map: choose the new map you created earlier
5. Height (px): Adjust the value in and press enter

Note that since Monitor 5.6, you are able to display more than one widget of the same kind.

JMX exposes a set of ‘Managed bean’ (MBean) wich represents a resource running in the Java Virtual Machine.

The JMX implementation of a java application server typically exposes resource usage statistics (memory, threads used etc) and lots of other statistics/metrics. Apart from generic information the application server vendor also provide MBeans specific for the application server in question.

Functionality

The check_jmx plugin enables you to monitor the values of any MBean attribute made available through JMX.

Prerequisites

The JMX agent need to be enabled at the application server that is being monitored. The agent must be configured to allow remote connections over RMI ((Java) Remote Method Invocation). Refer to the application server documentation for details on how to set this up.

It is also possible to run the checks in this how-to with a username and password to increase security, this how-to will not cover that. Please refer to your application servers manual how to set that up.

Installation

The check_jmx plugin is included in the op5-plugins package and is located in /opt/plugins. Metadata/checkcommand is installed in /opt/plugins/metadata/check_jmx.metadata.

You will also need java installed in your op5 Monitor. Information regarding that can be found through the CentOS community.

Usage

The plugin consist of a shell script wrapper (check_jmx) and a java jar file (check_jmx.jar). When running the plugin the shell script should be invoked, the jar file should not be used directly. The plugin consist of a shell script wrapper (check_jmx) and a java jar file (check_jmx.jar). When running the plugin the shell script should be invoked, the jar file should not be used directly.

# ./check_jmx -U <jmx-url> -O <Object name>  -A <Attribute name>  -K <Attribute key>

Examples

You can test the different checks from command-line to verify that they works before you implement them into op5 Monitor. check the ‘used’ key of attribute ‘HeapMemoryUsage’ in the object:  ‘java.lang:type=Memory’

# cd /opt/plugins
# ./check_jmx -U service:jmx:rmi:///jndi/rmi://'app-server':'1090'/jmxrmi -O java.lang:type=Memory -A HeapMemoryUsage -K "used"

Check the ‘ThreadCount’ attribute in the object  ‘java.lang:type=Threading’

# ./check_jmx -U service:jmx:rmi:///jndi/rmi://'app-server':'1090'/jmxrmi -O java.lang:type=Threading -A ThreadCount -K ""

Check available connections in the connection-pool in the object ‘jboss.jca:name=JmsXA,service=ManagedConnectionPool’ with the attribute ‘AvailableConnectionCount’

# ./check_jmx -U service:jmx:rmi:///jndi/rmi://'app-server':'1090'/jmxrmi -O jboss.jca:name=JmsXA,service=ManagedConnectionPool -A AvailableConnectionCount

Check Commands

Add the required check-commands, if they don’t already exist in your configuration (‘Configure’ -> ‘Commands’ -> ‘Check Command Import’):

Adding Services

Add the required services, (‘Configure’ -> ‘Host: ‘ -> ‘Go’ -> ‘Services for host ‘ -> ‘Add new service’ -> ‘Go’):

Add the following services (Arguments are just examples, you need to adjust them to suite your environment).

Other

This is just an example of some parameters that you can monitor with check_jmx, for more detailed information, please refer to the developers site. We  recommend that you also monitor the server that is running JBoss at a lower level, i.e on operating system level with for example NRPE to get more detailed information about the underlying operating system. More information: http://www.op5.com/agents/nagios-remote-plugin-executor-nrpe/

References

The developers site: http://snippets.syabru.ch/nagios-jmx-plugin/

JMX4Perl How-to: http://www.op5.com/how-to/howto-monitor-application-server-op5-monitor-jmx4perl/

* From wikipedia: (http://en.wikipedia.org/wiki/JMX)

Through the plugin we can check the following parameters on the host and virtual servers running in the XEN environment.

Session specific parameters:

• list hosts
• pool(s) state
• VMs state

Host specific parameters:

• cpu (total, per core)
• memory
• disk I/O
• network I/O
• VM(s) running on this host
• time difference

VM specific parameters:

• cpu (total, core)
• memory(allocated, ballooned, internal)
• disk I/O
• network I/O

Prerequisites

• Make sure you have the latest op5 plugin package installed. To verify this simply do a “yum update” when logged in to op5 Monitor via SSH.
  Note: The plugin will be public available soon through “yum update”, but If you want to use it before that send a request mail to our support team at support@op5.com
• Create a common user on your hosts. It will be used by the plugin to communicate with the XEN API on your hosts.
• Add the master host in your cluster environment to op5 Monitor. All checks in this how-to will ask the master host.
  Note: If you need to monitor VMs that is not running on the master host, also add the host that the VM is running on to the op5 Monitor and add the VM checks to that host.

Adding the services

Add the required services that you need, (‘Configure’ -> ‘Host: ‘ -> ‘Go’ -> ‘Services for host ‘ -> ‘Add new service’ -> ‘Go’):

Please note that these arguments are just examples, you need to adjust them to suite your environment.

Services for cluster, global

Services for the hosts

Services for VMs

Save your configuration.

Here is an example of how these checks will look like in production.

Remarks

This plugin is still under development. More checks will be added. Please send your feedback on op5 users mailing list.

All checks have been tested on Citrix XenServer cluster v5.5 and 6.0.

You can see this plugin in use on our demo site.

REV 1, 2012-02-15

Host specific parameters:

• storage pool list
• storage pool volume usage
• VM running

VM specific parameters:

• cpu
• memory
• disk I/O
• network I/O

Prerequisites

• libvirt drivers need to be installed on both the op5 Monitor server and on the target KVM host(s) and running.
• The plugin support several transport protocols. In these guideline we will explain how to use SSH and TLS, the most common.
• If you want use SSH, you need to setup a password-less communication for the monitor user on the op5 monitor server and the root user on the target KVM host (libvirt is usually running as root).
• If you want use TLS for a more secure communication then you will need to generate client and server certificates. Please follow the libvirt.org how-to for that. Be careful and follow all the steps in that how-to before you continue. Notice that the KVM host server is the server and the op5 Monitor server is the client for the TLS communication.
• All servers are found in DNS.
• Update op5 Monitor to get the latest plugin pack.

Check commands

SSH as transport protocol

If you use SSH, import the required check-commands in your configuration (‘Configure’ -> ‘Commands’ -> ‘Check Command Import -> check_libvirt_kvm*’). After the import you will have the following check commands:

Commands for guest VM’s

Commands for KVM host server

Note: $ARG1$ macro in the command_line refer to the user you will use to connect to the KVM host server, in these case root, the $HOSTADDRESS$ refer to the KVM host and the $ARG2$ refer to the guest VM-name.

TTL as transport protocol

If you prefer user TLS, then you can add yourself the above check command to your configuration, you need only replace qemu+ssh with qemu+tls, (‘Configure’ -> ‘Commands’ -> ‘Add new command‘ -> ‘Go’).

Adding the services

Some services example following.

Add the required services as your needs, (‘Configure’ -> ‘Host: ‘ -> ‘Go’ -> ‘Services for host ‘ -> ‘Add new service’ -> ‘Go’):

Arguments are just examples, you need to adjust them to suite your environment.

Services for guest VM

Services for KVM host server

* Note: No warning or critical arguments are used in these examples. The plugin does however support thresholds.

These check_command has been successfully tested on CentOS/RHEL v.5.5 and 6.x with KVM 2.x. It should even work fine in other KVM environment.

More information about libvirt can be found at: www.libvirt.org

REV 2, 20120416

In the distributed monitoring solution:

• All configuration is done on the Master system
• All new configuration is distributed to the pollers
• Each poller is responsible for its own host group (Site)
• The Master has all the status information

Prerequisites

There are a few things you need to take care of before you can start setting up a distributed monitoring solution. You need to make sure:

1. You have at least two op5 Monitor servers of the same architecture up and running.
2. op5 Monitor version 5.2 or higher is installed and running on both machines.
3. Opened up the following TCP ports for communication between the servers
   • 15551, op5 Monitor back end communication port
   • 22, ssh for the configuration sync
4. If you need a secure connection between the master and the cloud poller, then follow the guidelines in this how-to: Secure communication with Cloud poller.
5. Both servers are found in DNS.
6. Make sure that the host group that the poller will be responsible for, is added to the master configuration and that at least one host is added to that host group.

The configuration

Setting up the new distributed monitoring solution

This distributed configuration will have one master and two poller: master01, poller01, poller02. The poller01 will be monitoring the hostgroup gbg and poller02 the hostgroup sth.

During the setup we will use the command:

mon

The mon command is used to make life a bit easier when it comes to setting up a load balanced solution. To get more detailed information about the command mon just execute like this:

mon –help

Adding the poller01

1. Log in to the master over ssh, as root.
2. Add the new poller to the configuration with the following command:
   • mon node add poller01 type=poller hostgroup=gbg
3. Create and add ssh keys to and from the second peer by as root user:
   • mon sshkey push –all
   • mon sshkey fetch –all
4. Add master01 as master at poller01:
   • mon node ctrl –type=poller — mon node add master01 type=master
5. Set up the configuration sync:
   • dir=/opt/monitor/etc/oconf
   • conf=/opt/monitor/etc/nagios.cfg
   • mon node ctrl — sed -i /^cfg_file=/d $conf
   • mon node ctrl — sed -i /^log_file=/acfg_dir=$dir $conf
   • mon node ctrl — mkdir -m 775 $dir
   • mon node ctrl — chown monitor:apache $dir
6. To make sure you have an empty configuration on poller01:
   • mon node ctrl — mon oconf hash
     This will give you an hash looking like this (“da 39” -hash):
   • da39a3ee5e6b4b0d3255bfef95601890afd80709
7. Now push the configuration to the poller:
   • mon oconf push
8. Restart and push the logs from master01 from poller01:
   • mon restart; sleep 3; mon oconf push

Adding the poller02

1. Log in to the master over ssh, as root.
2. Add the new poller to the configuration with the following command:
   • mon node add poller02 type=poller hostgroup=sth
3. Create and add ssh keys for the root user:
   • mon sshkey push poller02
   • mon sshkey fetch poller02
4. Add master01 as master at poller02:
   • mon node ctrl poller02 — mon node add master01 type=master
5. Set up the configuration sync:
   • dir=/opt/monitor/etc/oconf
   • conf=/opt/monitor/etc/nagios.cfg
   • mon node ctrl poller02 — sed -i /^cfg_file=/d $conf
   • mon node ctrl poller02 — sed -i /^log_file=/acfg_dir=$dir $conf
   • mon node ctrl poller02 — mkdir -m 775 $dir
   • mon node ctrl poller02 — chown monitor:apache $dir
6. To make sure you have an empty configuration on poller01:
   • mon node ctrl poller02 — mon oconf hash
     This will give you an hash looking like this (“da 39” -hash):
   • da39a3ee5e6b4b0d3255bfef95601890afd80709
7. Now push the configuration to the poller:
   • mon oconf push
8. Restart and push the logs from master01 from poller02:
   • mon restart; sleep 3; mon oconf push

Now do you have an op5 Monitor distributed monitor solution!

Adding a new host group to a poller

You might want to add an other host group to a poller. You need to edit the merlin.conf file to do that. It is not possible to do with any command as it is today.

To add a new host group to poller01

1. Open up and edit /opt/monitor/op5/merlin/merlin.conf at master.
2. Add a new host group in the hostgroup line like this:
   • hostgroup = gbg,citrix_servers
   • Remember to not put any space between the hostgroup name and comma.
3. Restart monitor on the pollers
   • mon restart
4. Send over the new configuration to the poller
   • mon oconf push

Removing a poller

In this instruction we will remove a poller called: poller01. The poller will be removed from the master configuration and all distributed configuration on the poller will also be removed.

To remove a poller

1. Log in to the master over ssh, as root.
2. Deactivate and remove all distributed setup on the poller host.
   • mon node ctrl poller01 — mon node remove master01
3. Restart monitor on the poller.
   • mon node ctrl poller01 — mon restart
4. Remove the poller from the master configuration.
   • mon node remove poller01
5. Restart monitor on the master.
   • mon restart

More information

For more information and a more complex example, please take a look at the how-to in the git repository of the open source project Merlin.

REV 2, 2011-11-16

Plugin check_ipmi_sensor

The check_ipmi_sensor plugins is a Open Source plugin which basically is a wrapper around a tool called FreeIPMI (see below). You can read more about FreeIPMI at the creator, Thomas Krenn’s German homepage.

Plugin details

The plugin supports IPMI v1.5 and IPMI v2.0. It can check IPMI sensors locally or via ‘Serial over LAN’ connection. In order for remote monitoring to be possible, the target (monitored system) need to be configured to accept remote connections. The exact configuration procedure is hardware (motherboard/Bios) dependant.

How to Enable IMPI Monitoring

The following is an example on how-to enable IPMI , please note that it can differ for your hardware.

On Dell PowerEdge servers (1950 and R410 at least) the following steps are needed in order to enable ‘Serial over LAN’.

1. On Boot, press Ctrl-E when prompted.
2. Set IPMI Enabled
3. Set a static IP address and gateway.
4. Set a username and a password.
5. Reboot

Note: these steps are not necessary on the op5 Monitor server, only on the systems we want to monitor.

Sensor groups that can be monitored

• TEMPERATURE
• VOLTAGE
• CURRENT
• FAN
• PHYSICAL_SECURITY
• PLATFORM_SECURITY_VIOLATION_ATTEMPT
• PROCESSOR
• POWER_SUPPLY
• POWER_UNIT
• MEMORY
• DRIVE_SLOT
• SYSTEM_FIRMWARE_PROGRESS
  EVENT_LOGGING_DISABLED
• SYSTEM_EVENT
• CRITICAL_INTERRUPT
• MODULE_BOARD
• SLOT_CONNECTOR
• WATCHDOG2

Note: the availability of the sensor groups is system dependant.

Prerequisites

• Install the op5 monitor community plugin package, ”yum install plugins-community-2.8.0” or later.
• Install the FreeIPMI package on the op5 monitor server, ”yum install freeipmi”
• Enable and configure IPMI as describe above.

Check Commands

Add the required check-commands in your configuration as your needs (‘Configure’ -> ‘Commands’ -> ‘Check Command Import -> check_libvirt_kvm*’).

Some check commands example following:

Adding the services

Below are some examples of services you can add.

Add the required services, (‘Configure’ -> ‘Host: ‘ -> ‘Go’ -> ‘Services for host ‘ -> ‘Add new service’ -> ‘Go’):

Arguments are just examples, you need to adjust them to suite your environment.

Note*: You can instead add arguments(ARGs) USER11(root) and USER12(password) to the file /opt/monitor/etc/resource.cfg. Don’t forget to reload the Monitor service.