Monitoring the Petals SE ASE

In this version of the Petals ASE, the monitoring is based mainly on the ActiveMQ monitoring.

The following indicators are interesting:

number of requests processed with fault in the persistence area: a fast increase of this value should show:
- the target service provider or its backend are overloaded or down,
- a DoD of the ASE service provider client
number of retried requests: an increase of this value should show:
- the target service provider or its backend are overloaded or down,
- the ASE service provider client doesn't respect the SLA

Table of contents

Monitoring the Petals SE ASE

Monitoring with basic tools

JVisualVM
Command line tools of ActiveMQ

Monitoring with Nagios
Monitoring with Cacti
Monitoring with Munin

Pre-requisites
Configuration
Integrating Munin with Naggios using Naggios active checks

Installation of the Nagios plugin for Munin
Nagios commands definition to interact with a Munin agent
Nagios template service to interact with a Munin agent
Define ActiveMQ check as service of a Petals node

Screenshots

Munin screenshots

Queue size sample
Traffic sample

Nagios screenshots

Contributors

No contributors found for: authors on selected page(s)

Monitoring with basic tools

The command-lines and configuration files mentionned in following sub-chapters are available on Ubuntu 11.10

JVisualVM

As ActiveMQ is provided with a JMX API, it is very easy to connect the JVisualVM to the ActiveMQ's JVM. See http://activemq.apache.org/jmx.html.

Don't forget to install into JVisualVM its plugin VisualVM-MBeans previously.

Command line tools of ActiveMQ

ActiveMQ is provided with a command-line tools to get statistics: activemq-admin

For example, use the following command to get the number of the requests waiting to be sent to the target service provider:

activemq-admin query --objname Type=Queue,Destination=testQueue --view QueueSize | grep QueueSize

Monitoring with Nagios

Several options are available to monitor ActiveMQ using Naggios:

Integrating Munin with Naggios, sending messages from Munin to Naggios: http://munin-monitoring.org/wiki/HowToContactNagios
Integrating Munin with Naggios, using Naggios active checks: http://exchange.nagios.org/directory/Plugins/Uncategorized/Operating-Systems/Linux/check_munin_rrd/details
Integrating ActiveMQ with Naggios, using ActiveMQ's command-line tools: TODO
Integrating ActiveMQ with Naggios, using ActiveMQ's JMX API: TODO

Monitoring with Cacti

Solution based on an article of R.I.Pienaar

Monitoring with Munin

A plugin ActiveMQ for Munin exists: http://munin-activemq.sourceforge.net. It is very easy to install it on a Debian-based system using the Debian package. Don't forget to install Munin previously.
The downloaded package can be installed with the followinf command:

sudo dpkg -i munin-java-activemq-plugins_0.0.4_i386.deb

Pre-requisites

The plugin ActiveMQ for Munin requires a remote JMX connection to the ActiveMQ server, so you needs to configure your ActiveMQ to enable the JMX connector:

<beans ... >
  <broker xmlns="http://activemq.apache.org/schema/core" ... >
    ...
    <managementContext>
      <managementContext createConnector="true"/>
    </managementContext>
    ...
  </broker>
  ...
</beans>

Configuration

Edit the file /etc/munin/plugin-conf.d/activemq_ to add the queues to monitor in parameter env.DESTINATIONS of the section ?activemq*. :

[activemq_*]
## The hostname to connect to.
## Default: localhost
#env.JMX_HOST localhost

## The port where the JMX server is listening
## Default: 1099
#env.JMX_PORT 1099

## The username required to authenticate to the JMX server.
## When enabling JMX for a plain ActiveMQ install, no authentication is needed.
## The default username for JMX run by ServiceMix is 'smx'
## Default:
#env.JMX_USER smx

## The password required to authenticate to the JMX server.
## The default password for JMX run by ServiceMix is 'smx'
## Default:
#env.JMX_PASS smx

## Space separated list of destinations to create graphs for.
## Default:
env.DESTINATIONS Queue:foo Queue:bar

## You can override certain configuration variables for specific plugins
#[activemq_traffic]
#env.DESTINATIONS Topic:MyTopic Queue:foo

Integrating Munin with Naggios using Naggios active checks

This chapter is based on information available here

Installation of the Nagios plugin for Munin

On your Nagios host:

Download the Perl script check_munin_rdd.pl into the Nagios plugins directory (under Ubuntu: /usr/lib/nagios/plugins),
Check that the owner file and permissions are the same as other ones (root, and 755). Fix them if needed.

Nagios commands definition to interact with a Munin agent

A specific Nagios command to interact with Munin agent must be defined on your Nagios host:

create the file munin.cfg in the directory /etc/nagios-plugins/config (except for Ubuntu, adapt the directory name to your operating system).
check that the owner file and permissions are the same as other ones (root, and 644). Fix them if needed.

edit the previous file with the following content:

define command{
     command_name check_munin
     command_line /usr/lib/nagios/plugins/check_munin_rrd.pl -H $HOSTALIAS$ -M $ARG1$ -w $ARG2$ -c $ARG3$
     }

Nagios template service to interact with a Munin agent

A specific template service to interact with Munin agent must be defined on your Nagios host:

create the file generic-munin-service.cfg in the directory /etc/nagios3/conf.d (except for Ubuntu, adapt the directory name to your operating system).
check that the owner file and permissions are the same as other ones (root, and 644). Fix them if needed.

edit the previous file with the following content:

define service{
       name                            generic-munin-service ; The 'name' of this service template
       active_checks_enabled           1       ; Active service checks are enabled
       passive_checks_enabled          0       ; Passive service checks are enabled/accepted
       parallelize_check               1       ; Active service checks should be parallelized (disabling this can lead to major performance problems)
       obsess_over_service             1       ; We should obsess over this service (if necessary)
       check_freshness                 0       ; Default is to NOT check service 'freshness'
       notifications_enabled           1       ; Service notifications are enabled
       event_handler_enabled           1       ; Service event handler is enabled
       flap_detection_enabled          1       ; Flap detection is enabled 
       failure_prediction_enabled      1       ; Failure prediction is enabled
       process_perf_data               1       ; Process performance data
       retain_status_information       1       ; Retain status information across program restarts
       retain_nonstatus_information    1       ; Retain non-status information across program restarts
       notification_interval           0       ; Only send notifications on status change by default.
       is_volatile                     0
       check_period                    24x7
       normal_check_interval           5       ; This directive is used to define the number of "time units" to wait before scheduling the next "regular" check of the service.
       retry_check_interval            3       ; This directive is used to define the number of "time units" to wait before scheduling a re-check of the service.
       max_check_attempts              2       ; This directive is used to define the number of times that Nagios will retry the service check command if it returns any state other than an OK state. Setting this value to 1 will cause Nagios to generate an alert without retrying the service check again.
       notification_period             24x7
       notification_options            w,u,c,r
       contact_groups                  admins
       register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL SERVICE, JUST A TEMPLATE!
       }

Define ActiveMQ check as service of a Petals node

See Monitoring Petals ESB with Nagios to configure Nagios to monitor Petals ESB

In main use-cases, the ActiveMQ server is collocated with the Petals ESB node running the SE ASE. So, it is a good practice to define ActiveMQ as a service of the Petals node running the SE ASE:

edit the Nagios configuration file of your Petals ESB node (for example: /etc/nagios3/conf.d/petals-esb-host-node1.cfg, following the monitoring Petals ESB sample),

and add the following content:

# Define a service to check the queue size of an ActiveMQ queue used by the SE ASE
define service{
       host_name                       petals-esb-node-1
       service_description             se-ase-queue-size
       check_command                   check_munin_rrd!activemq size!10!50
       use                             generic-munin-service
     }

# Define a service to check the traffic of an ActiveMQ queue used by the SE ASE
define service{
       host_name                       petals-esb-node-1
       service_description             se-ase-queue-traffic
       check_command                   check_munin_rrd!activemq traffic!500!1000
       use                             generic-munin-service
     }

In our example:

in nominal running, we should not have more than 10 pending messages. Over 50 pending messages, an error is thrown.
and according to our volumetric estimations, we should not have more than 500 messages per 5 min. We accept up to twice our estimation: 1000 messages per 5 min.

Wiki

All versions of Petals ESB

Helpful links

Petals SE-ASE 1.0.x