E-mail
|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (2)
View Page History
...
{section} 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).
# 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:
{code}
{code}
...{code}
h4. 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:
{code}
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!
}
{code}
h4. Define ActiveMQ check as service of a Petals node
{tip}See [petalsesbsnapshot:Monitoring Petals ESB with Nagios] to configure Nagios to monitor Petals ESB{tip}
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:
{code}
# 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-size
check_command check_munin_rrd!activemq traffic!500!1000
use generic-munin-service
}
{code}
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.
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:
{code}
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!
}
{code}
h4. Define ActiveMQ check as service of a Petals node
{tip}See [petalsesbsnapshot:Monitoring Petals ESB with Nagios] to configure Nagios to monitor Petals ESB{tip}
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:
{code}
# 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-size
check_command check_munin_rrd!activemq traffic!500!1000
use generic-munin-service
}
{code}
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.
h3. Screenshots
...