--- title: Nagios description: Send Nagios service flaps, host alerts, and more to your Datadog event stream. breadcrumbs: Docs > Integrations > Nagios --- # Nagios Supported OS Integration version3.4.0 {% callout %} # Important note for users on the following Datadog sites: us2.ddog-gov.com {% alert level="info" %} To find out if this integration is available in your organization, see your [Datadog Integrations](https://app.datadoghq.com/integrations) page or ask your organization administrator. To initiate an exception request to enable this integration for your organization, email [support@ddog-gov.com](mailto:support@ddog-gov.com). {% /alert %} {% /callout %} ## Overview{% #overview %} Send events from your Nagios-monitored infrastructure to Datadog for richer alerting and to help correlate Nagios events with metrics from your Datadog-monitored infrastructure. This check watches your Nagios server's logs and sends events to Datadog for the following: - Service flaps - Host state changes - Passive service checks - Host and service downtimes This check can also send Nagios performance data as metrics to Datadog. **Minimum Agent version:** 6.0.0 ## Setup{% #setup %} ### Installation{% #installation %} The Nagios check is included in the [Datadog Agent](https://app.datadoghq.com/account/settings/agent/latest) package, so you don't need to install anything else on your Nagios servers. ### Configuration{% #configuration %} Follow the instructions below to configure this check for an Agent running on a host. For containerized environments, see the Containerized section. {% tab title="Host" %} #### Host{% #host %} To configure this check for an Agent running on a host: 1. Edit the `nagios.d/conf.yaml` file in the `conf.d/` folder at the root of your [Agent's configuration directory](https://docs.datadoghq.com/agent/guide/agent-configuration-files.md#agent-configuration-directory). See the [sample nagios.d/conf.yaml](https://github.com/DataDog/integrations-core/blob/master/nagios/datadog_checks/nagios/data/conf.yaml.example) for all available configuration options. 1. [Restart the Agent](https://docs.datadoghq.com/agent/guide/agent-commands.md#start-stop-and-restart-the-agent) to start sending Nagios events and (optionally) performance data metrics to Datadog. **Note**: The Nagios check can potentially emit [custom metrics](https://docs.datadoghq.com/developers/metrics/custom_metrics.md), which may impact your [billing](https://docs.datadoghq.com/account_management/billing/custom_metrics.md). {% /tab %} {% tab title="Containerized" %} #### Containerized{% #containerized %} For containerized environments, see the [Autodiscovery Integration Templates](https://docs.datadoghq.com/agent/kubernetes/integrations.md) for guidance on applying the parameters below. | Parameter | Value | | -------------------- | -------------------------------------------- | | `` | `nagios` | | `` | blank or `{}` | | `` | `{"nagios_conf": "/etc/nagios3/nagios.cfg"}` | **Note**: The containerized Agent should be able to access the `/etc/nagios3/nagios.cfg` file to enable the Datadog-Nagios integration. {% /tab %} ### Validation{% #validation %} [Run the Agent's status subcommand](https://docs.datadoghq.com/agent/guide/agent-commands.md#agent-status-and-information) and look for `nagios` under the Checks section. ## Data Collected{% #data-collected %} ### Metrics{% #metrics %} | | | | | **nagios.current\_users.users**(gauge) | Number of current user*Shown as user* | | **nagios.disk\_space**(gauge) | Disk space*Shown as mebibyte* | | **nagios.host.pl**(gauge) | Packet loss*Shown as percent* | | **nagios.host.rta**(gauge) | Round trip time between Nagios and client*Shown as millisecond* | | **nagios.http.size**(gauge) | HTTP response size*Shown as byte* | | **nagios.http.time**(gauge) | HTTP response time*Shown as second* | | **nagios.ping.pl**(gauge) | Packet loss*Shown as percent* | | **nagios.ping.rta**(gauge) | Round trip time between Nagios and client*Shown as millisecond* | | **nagios.swap\_usage.swap**(gauge) | Memory swap usage*Shown as mebibyte* | ### Log collection{% #log-collection %} 1. Collecting logs is disabled by default in the Datadog Agent, enable it in your `datadog.yaml` file: ```yaml logs_enabled: true ``` 1. Add this configuration block to your `nagios.d/conf.yaml` file to start collecting your Nagios logs: ```yaml logs: - type: file path: /opt/nagios/var/log/nagios.log source: nagios ``` Change the `path` parameter value based on your environment, see `log_file` value in your nagios configuration file. See the [sample nagios.d/conf.yaml](https://github.com/DataDog/integrations-core/blob/master/nagios/datadog_checks/nagios/data/conf.yaml.example) for all available configuration options. 1. [Restart the Agent](https://docs.datadoghq.com/agent/guide/agent-commands.md#start-stop-and-restart-the-agent). ### Events{% #events %} The check watches the Nagios events log for log lines containing these strings, emitting an event for each line: - SERVICE FLAPPING ALERT - ACKNOWLEDGE_SVC_PROBLEM - SERVICE ALERT - HOST ALERT - ACKNOWLEDGE_HOST_PROBLEM - SERVICE NOTIFICATION - HOST DOWNTIME ALERT - PROCESS_SERVICE_CHECK_RESULT - SERVICE DOWNTIME ALERT ### Service Checks{% #service-checks %} The Nagios check does not include any service checks. ## Trigger on-call pages{% #trigger-on-call-pages %} Configure Nagios notification commands to forward notifications to the Datadog events intake, which routes them to [Datadog On-Call](https://docs.datadoghq.com/service_management/on-call.md) using an `oncall_team` query parameter. Datadog deduplicates and auto-resolves events that share an `aggregation_key`, so a Nagios `RECOVERY` resolves the page created by its corresponding `PROBLEM` automatically. ### Map Nagios events to on-call pages{% #map-nagios-events-to-on-call-pages %} | Nagios state | Event `category` | Alert `status` | On-Call effect | | ------------------ | ---------------- | -------------- | ------------------------------------------------- | | `CRITICAL`, `DOWN` | `alert` | `error` | Pages the configured On-Call team | | `WARNING` | `alert` | `warn` | Pages the configured On-Call team | | `OK`, `UP` | `alert` | `ok` | Resolves the page with the same `aggregation_key` | | `UNKNOWN` | `alert` | `warn` | Pages the configured On-Call team | ### Setup{% #setup-1 %} The script depends on `curl` and `python3`. Both are commonly available on Nagios hosts. Keep the Datadog API key out of `commands.cfg`. Set `DD_API_KEY` as an environment variable exported by the Nagios service, or load it from a Nagios resource file with restricted permissions. #### Create the notification script{% #create-the-notification-script %} Create `/usr/local/nagios/libexec/notify_datadog_oncall.sh`: ```bash #!/bin/bash set -u DD_API_KEY="${DD_API_KEY:-}" DD_SITE="${DD_SITE:-datadoghq.com}" # for example, datadoghq.eu, us3.datadoghq.com NAGIOS_HOST="${1}" SERVICEDESC="${2}" STATE="${3}" # CRITICAL, WARNING, OK, UNKNOWN, UP, DOWN ONCALL_TEAM="${4}" # Datadog On-Call team handle, for example, "ops" OUTPUT="${5}" case "$STATE" in CRITICAL|DOWN) STATUS="error" ;; WARNING) STATUS="warn" ;; OK|UP) STATUS="ok" ;; *) STATUS="warn" ;; esac TITLE_JSON=$(printf 'Nagios: %s / %s is %s' "$NAGIOS_HOST" "$SERVICEDESC" "$STATE" \ | python3 -c 'import json,sys; print(json.dumps(sys.stdin.read()))') MESSAGE_JSON=$(printf '%s' "$OUTPUT" \ | python3 -c 'import json,sys; print(json.dumps(sys.stdin.read()))') PAYLOAD=$(cat <&2 cat "$RESPONSE_FILE" >&2 exit 1 fi ``` Make the script executable: ```shell sudo chmod 755 /usr/local/nagios/libexec/notify_datadog_oncall.sh ``` #### Define the Nagios commands{% #define-the-nagios-commands %} Add to `commands.cfg`. Use separate commands for service and host notifications so the correct Nagios macros are passed: ``` define command { command_name notify-datadog-oncall-service command_line /usr/local/nagios/libexec/notify_datadog_oncall.sh "$HOSTALIAS$" "$SERVICEDESC$" "$SERVICESTATE$" "$_CONTACTONCALL_TEAM$" "$SERVICEOUTPUT$" } define command { command_name notify-datadog-oncall-host command_line /usr/local/nagios/libexec/notify_datadog_oncall.sh "$HOSTALIAS$" "Host" "$HOSTSTATE$" "$_CONTACTONCALL_TEAM$" "$HOSTOUTPUT$" } ``` #### Create contacts with the On-Call team handle{% #create-contacts-with-the-on-call-team-handle %} The custom variable `_oncall_team` maps to the Datadog On-Call team handle `@oncall-`. Set it to exactly the team handle configured in [Datadog On-Call](https://docs.datadoghq.com/service_management/on-call.md), without the `@oncall-` prefix. Add contacts to `contacts.cfg`: ``` define contact { contact_name datadog-ops alias Ops Team On-Call service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-datadog-oncall-service host_notification_commands notify-datadog-oncall-host _oncall_team ops } ``` #### Assign the contact to services or hosts{% #assign-the-contact-to-services-or-hosts %} ``` define service { use generic-service host_name webserver-01 service_description HTTP_Service check_command check_http contacts datadog-ops notification_options w,u,c,r } ``` #### Reload Nagios{% #reload-nagios %} ```shell sudo systemctl reload nagios ``` Verify pages appear under **On-Call > Pages** in Datadog. ## Troubleshooting{% #troubleshooting %} Need help? Contact [Datadog support](https://docs.datadoghq.com/help/). ## Further Reading{% #further-reading %} - [Monitoring Nagios alerts, simplified](https://www.datadoghq.com/blog/nagios-monitoring)