24. Core features
• Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.)
• Monitoring of host resources (processor load, disk usage, etc.)
• Simple plugin design that allows users to easily develop their own service
checks
• Parallelized service checks
• Ability to define network host hierarchy using "parent" hosts, allowing
detection of and distinction between hosts that are down and those that
are unreachable
• Contact notifications when service or host problems occur and get resolved
(via email, pager, or user-defined method)
• Ability to define event handlers to be run during service or host events for
proactive problem resolution
• Automatic log file rotation
• Support for implementing redundant monitoring hosts
• Web interface for viewing current network status, notification and problem
history, log file, etc.
24
26. Object Definitions
• Host definitions
• Host group definitions
• Service definitions
• Service group definitions
• Contact definitions
• Contact group definitions
• Time period definitions
• Command definitions
• …
26
27. Nagios plugins
• HTTP, POP3, IMAP, FTP, SSH, DHCP
• CPU Load, Disk Usage, Memory Usage,
Current Users
• Unix/Linux, Windows, and Netware Servers
• Routers and Switches
• …
• Java applications
• …
27
31. check_jmx4perl plugin
Nagios plugin for monitoring Java applications. It uses
an agent based approach for accessing JMX exposed
information remotely.
(Official documentation)
31
37. Puppet is IT automation software that helps system
administrators manage infrastructure throughout its
lifecycle, from provisioning and configuration to
orchestration and reporting
37
38. Resource is our all
• A user account
• A specific file
• A directory of files
• A software package
• A running service
• A scheduled cron job
• An invocation of a shell command, when certain
conditions are met
• …
38
42. Putting all together
42
• Define monitoring parameters
• Expose them via JMX mechanism
• Add Jolokia facet to app
• Enable check_jmx4perl plugin in Nagios
• Write Nagios checks
• Deploy
• …
• Be happy and have some beer with your team
Main Configuration File
The main configuration file contains a number of directives that affect how the Nagios daemon operates. This config file is read by both the Nagios daemon and the CGIs. This is where you're going to want to get started in your configuration adventures.
Documentation for the main configuration file can be found here.
Resource File(s)
Resource files can be used to store user-defined macros. The main point of having resource files is to use them to store sensitive configuration information (like passwords), without making them available to the CGIs.
You can specify one or more optional resource files by using the resource_file directive in your main configuration file.
Object Definition Files
Object definition files are used to define hosts, services, hostgroups, contacts, contactgroups, commands, etc. This is where you define all the things you want monitor and how you want to monitor them.
You can specify one or more object definition files by using the cfg_file and/or cfg_dir directives in your main configuration file.
An introduction to object definitions, and how they relate to each other, can be found here.
CGI Configuration File
The CGI configuration file contains a number of directives that affect the operation of the CGIs. It also contains a reference the main configuration file, so the CGIs know how you've configured Nagios and where your object defintions are stored.
Which plugin?
Jolokia is a JMX-HTTP bridge giving an alternative to JSR-160 connectors.
It is an agent based approach with support for many platforms.
In addition to basic JMX operations it enhances JMX remoting with unique features like bulk requests and fine grained security policies.
The agent exports on the frontside a JSON based protocol over HTTP that gets bridged to invocation of local JMX MBeans.
It lives outside the JSR-160 space and hence requires a different setup.
Various techniques are available for exporting its protocol via HTTP.
The most prominent being to put the agent into a servlet container.
Most of the time this happens for political reasons, where it is simply not allowed to deploy an extra piece of software or where doing so requires a lengthy approval process.
Another reason could be that the target server already exports JMX via JSR-160 and you want to avoid the extra step of deploying the agent.
This syntax is called a resource declaration.
In Puppet, every resource is an instance of a resource type and is identified by a title; it has a number of attributes (which are defined by the type), and each attribute has a value.
Manifests don’t get used directly when Puppet syncs resources. Instead, the flow of a Puppet run goes a little like this…
Before being applied, manifests get compiled into a document called a “catalog,” which only contains resources and hints about the order to sync them in.