Docs » Configure application receivers » Configure application receivers for monitoring » Nagios

Nagios 🔗

Description 🔗

The Splunk Distribution of OpenTelemetry Collector provides this integration as a wrapper to run existing Nagios status check scripts through the Splunk Distribution of OpenTelemetry Collector, which acts as the Nagios Remote Plugin Executor (NRPE) or the Simple Network Management Protocol (SNMP) exec directive.

Use this integration to run the script set in the command parameter and send the state of the check, depending on the exit code of the command. This integration is similar to the telegraf/exec monitor configured with dataFormat:nagios integration, with the following exceptions:

  • Does not retrieve perfdata metrics. This integration only retrieves the state of the script for alerting purposes.

  • Overrides the state if the exit code == 0, but the output string starts with warn, crit, or unkn (not case-sensitive).

This monitor is available on Kubernetes, Linux, and Windows.

Benefits 🔗

This integration adds more context to the status check state by using events. In addition to the state metric, this integration sends an event that includes the output and the error caught from the command execution.

Using this integration should make troubleshooting more efficient and let you to remain in Observability Cloud without connecting to your Linux or Windows machine in case of an abnormal state to understand what is happening. Using this integration also lets you create a dashboard that is familiar to Nagios users.

Note: The last sent event is cached into memory and compared to new events to avoid repeatedly sending the same event for each collection interval. Restarting the OTel Collector erases its cache, so the most recently sent event is sent again upon restart. If your check always “normally” produces a different output for each run, for example, the uptime check, you can use the FilterStdOut: true parameter to ignore it in comparison. {: .note}

After you’ve configured the integration, you can:

  • View metrics using the built-in dashboard. For information about dashboards, see View dashboards in Observability Cloud.

  • View a data-driven visualization of the physical servers, virtual machines, AWS instances, and other resources in your environment that are visible to Infrastructure Monitoring. For information about navigators, see Splunk Infrastructure Monitoring navigators.

  • Access Metric Finder and search for metrics sent by the monitor. For information about Metric Finder, see Use the Metric Finder.

Installation 🔗

Follow these steps to deploy the integration:

  1. Deploy the Splunk Distribution of OpenTelemetry Collector to your host or container platform:

  2. Configure the monitor, as described in the next section.

  3. Restart the Splunk Distribution of OpenTelemetry Collector.

Configuration 🔗

This monitor is available in the Smart Agent Receiver, which is part of the Splunk Distribution of OpenTelemetry Collector. The Smart Agent Receiver lets you use existing Smart Agent monitors as OpenTelemetry Collector metric receivers.

Using this monitor assumes that you have a configured environment with a functional Smart Agent release bundle on your system, which is already provided for x86_64/amd64 Splunk Distribution of OpenTelemetry Collector installation paths.

To activate this monitor in the Splunk Distribution of OpenTelemetry Collector, add the following to your configuration file:

receivers:
  smartagent/nagios:
    type: nagios
    ... # Additional config

To complete the integration, include the monitor in a metrics pipeline. To do this, add the monitor to the service > pipelines > metrics > receivers section of your configuration file. For example:

service:
  pipelines:
    metrics:
      receivers: [smartagent/nagios]

Event-sending functionality 🔗

This monitor includes event-sending functionality to let you post your own custom events to Observability Cloud. For example, you can send your own custom event when you deploy a new version of your software or update other parts of your infrastructure. You can then view these events in the Observability Cloud user interface (UI).

Monitors with event-sending functionality should be made members of a logs pipeline that utilizes a SignalFx exporter to make the event submission requests. Use a Resource Detection processor to ensure that host identity and other useful information is made available as event dimensions.

For example:

service:
  pipelines:
    logs:
      receivers:
        - smartagent/<receiver>
# Adds the Resource Detection processor to the logs pipeline.        
      processors:
        - resourcedetection
      exporters:
        - signalfx

Configuration settings 🔗

The following table shows the configuration options for this monitor:

Option Required Type Description
command yes string The command to exec with any arguments like: "LC_ALL=\"en_US.utf8\" /usr/lib/nagios/plugins/check_ntp_time -H pool.ntp.typhon.net -w 0.5 -c 1"
service yes string Corresponds to the nagios service column and allows to aggregate all instances of the same service (when calling the same check script with different arguments)
timeout no integer The max execution time allowed in seconds before sending SIGKILL (default: 9)
ignoreStdOut no bool If false and change is detected on stdout compared to the last event it will send a new one (default: false)
ignoreStdErr no bool If false and change is detected on stderr compared to the last event it will send a new one (default: false)

Metrics 🔗

The following metrics are available for this integration:

Troubleshooting 🔗

If you are not able to see your data in Splunk Observability Cloud:

  • Ask questions and get answers through community support at Splunk Answers.

  • If you have a support contract, file a case using the Splunk Support Portal. See Support and Services.

  • To get professional help with optimizing your Splunk software investment, see Splunk Services.