Nagios Data

Topics marked with * relate to HQ Enterprise-only features.

HQ's Nagios ^(R)-integration functionality comes standard. When a platform has Nagios installed on it and HQ auto-discovers it, HQ automatically imports Nagios data into HQ. Users can monitor Nagios data in HQ and define alerts in order to be alerted when scripts start exiting inappropriately. All the Nagios-related data and screens are available only, of course, if HQ discovers Nagios on the system.

NRPE and NSCA Checks Not Supported HQ's Nagios integration does not support NRPE and NSCA checks, wherein the script runs remotely and the status is collected via one of these Nagios add-ons.

• How HQ maps to Nagios

• Viewing Nagios data in HQ

• Managing resource availability with Nagios-data alerts

Feedback is welcome. Click Add Comment at the bottom of the page.

How HQ Maps to Nagios

HQ maps elements of Nagios' flat hierarchy to its vertically organized inventory model. HQ treats Nagios scripts as services and, for the Nagios master server, HQ creates a platform that contains those services. (The services are grouped in an autogroup. Users can generally ignore this grouping when evaluating Nagios data.) The Nagios daemon (technically, a representation of it) gets mapped to a server in HQ. The exit status of a Nagios script is presented in the HQ metric named "Return Code."

The Nagios dependency trees are not mapped to any existing HQ function.

back to top

Viewing Nagios Data in HQ

Nagios data is displayed in two places in the UI:

• The "Nagios Availability" screen (accessible via the masthead menu Resources > Nagios Availability) provides the same information as Nagios' "Service Details" screen, an overview of the current status of the monitored services and hosts.

• The Monitoring pages for the Nagios resources allow users to spot trends in the "Return Code" metric and correlate it with the event log (which is positioned just below the "Return Code" graph and the times match up between the two).

To view all Nagios-host availability data:

• In the masthead menu, select Resources > Nagios Availability and proceed to the "Nagios Availability" screen.

This menu item is available only when HQ has detected Nagios on the network.

To view imported Nagios data:

1. In the masthead, click Browse under "Resources."

1. In the "Browse Resources" screen, find and click the platform that has Nagios installed on it.

1. In the "Current Health" screen, click the Nagios server (listed as <localhostname>.<localdomainname> Nagios), at the left, under "Deployed Servers Health."

1. Still on the "Current Health" screen, but now looking at the Nagios server, click the Nagios service (listed as "Nagios Plugin"), at the left, under "Services."

1. On the tab, the "Return Code" metric reflects the imported Nagios data.

Consult the help for the "Current Health" screen for more instructions on working in this screen.

Ignore the "Availability" metric: it will always be true.

back to top

Managing Resource Availability with Nagios-Data Alerts

Users can define alerts to fire based on the "Return Code" metric (known in HQ as a "metric threshold" alert). This way, users can be alerted when (and only when) a script exits with an unacceptable value (see the list of possible exit values). These alerts should be defined for specific Nagios scripts (treated in HQ as services), not at the platform level. Because each Nagios service's name contains the hostname, users can tell which host had the unacceptable return code/exit status and triggered the alert.

back to top

Return to the Monitoring Overview.