---
title: Syslog Source
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: Docs > Observability Pipelines > Sources > Syslog Source
---

# Syslog Source

{% callout %}
# Important note for users on the following Datadog sites: app.ddog-gov.com

{% alert level="danger" %}
This product is not supported for your selected [Datadog site](https://docs.datadoghq.com/getting_started/site). ().
{% /alert %}

{% /callout %}
Available for:
{% icon name="icon-logs" /%}
 Logs 
## Overview{% #overview %}

Use Observability Pipelines' rsyslog or syslog-ng to receive logs sent to rsyslog or syslog-ng.

You can also forward third-party log to syslog and then send them to the Observability Pipelines Worker.

## Prerequisites{% #prerequisites %}

To use Observability Pipelines' Syslog source, your applications must be sending data in one of the following formats: [RFC 6587](https://datatracker.ietf.org/doc/html/rfc6587), [RFC 5424](https://datatracker.ietf.org/doc/html/rfc5424), [RFC 3164](https://datatracker.ietf.org/doc/html/rfc3164). You also need to have the following information available:

1. The bind address that your Observability Pipelines Worker (OPW) will listen on to receive logs from your applications. For example, `0.0.0.0:8088`. Later on, you configure your applications to send logs to this address.
1. The appropriate TLS certificates and the password you used to create your private key if your forwarders are globally configured to enable SSL.

## Setup{% #setup %}

Set up this source when you [set up a pipeline](https://docs.datadoghq.com/observability_pipelines/configuration/set_up_pipelines/). You can set up a pipeline in the [UI](https://app.datadoghq.com/observability-pipelines), using the [API](https://docs.datadoghq.com/api/latest/observability-pipelines/), or with [Terraform](https://registry.terraform.io/providers/datadog/datadog/latest/docs/resources/observability_pipeline). The instructions in this section are for setting up the source in the UI.

To configure your Syslog source:

{% alert level="danger" %}
Only enter the identifiers for the syslog address and, if applicable, the TLS key pass. Do not enter the actual values.
{% /alert %}

1. Enter the identifier for your syslog address. If you leave it blank, the default is used.
1. In the **Socket Type** dropdown menu, select the communication protocol you want to use: **TCP** or **UDP**.

### Optional TLS settings{% #optional-tls-settings %}

Toggle the switch to **Enable TLS**.

- If you are using Secrets Management, enter the identifier for the key pass. See Set secrets for the default used if the field is left blank.
- The following certificate and key files are required:
  - `Server Certificate Path`: The path to the certificate file that has been signed by your Certificate Authority (CA) root file in DER, PEM, or CRT (X.509).
  - `CA Certificate Path`: The path to the certificate file that is your Certificate Authority (CA) root file in DER, PEM, or CRT (X.509).
  - `Private Key Path`: The path to the `.key` private key file that belongs to your Server Certificate Path in DER, PEM, or CRT (PKCS #8) format.
  - **Notes**:
    - The configuration data directory `/var/lib/observability-pipelines-worker/config/` is automatically appended to the file paths. See [Advanced Worker Configurations](https://docs.datadoghq.com/observability_pipelines/configuration/install_the_worker/advanced_worker_configurations/) for more information.
    - The file must be readable by the `observability-pipelines-worker` group and user.

## Set secrets{% #set-secrets %}

These are the defaults used for secret identifiers and environment variables.

**Note**: If you enter secret identifiers and then choose to use environment variables, the environment variable is the identifier entered and prepended with `DD_OP`. For example, if you entered `PASSWORD_1` for a password identifier, the environment variable for that password is `DD_OP_PASSWORD_1`.

{% tab title="Secrets Management" %}

- rsyslog or syslog-ng address identifier:
  - References the bind address, such `0.0.0.0:9997`, on which the Observability Pipelines Worker listens to receive logs from the Syslog forwarder.
  - The default identifier is `SOURCE_SYSLOG_ADDRESS`.
- rsyslog or syslog-ng TLS passphrase identifier (when TLS is enabled):
  - The default identifier is `SOURCE_SYSLOG_KEY_PASS`.

{% /tab %}

{% tab title="Environment Variables" %}

- rsyslog or syslog-ng address:
  - The Observability Pipelines Worker listens on this bind address to receive logs from the Syslog forwarder. For example, `0.0.0.0:9997`.
  - The default environment variable is `DD_OP_SOURCE_SYSLOG_ADDRESS`.
- rsyslog or syslog-ng TLS passphrase (when enabled):
  - The default environment variable is `DD_OP_SOURCE_SYSLOG_KEY_PASS`.

{% /tab %}

## Send logs to the Observability Pipelines Worker over syslog{% #send-logs-to-the-observability-pipelines-worker-over-syslog %}

### rsyslog{% #rsyslog %}

To send rsyslog logs to the Observability Pipelines Worker, update your rsyslog config file:

```
ruleset(name="infiles") {
action(type="omfwd" protocol="tcp" target="<OPW_HOST>" port="<OPW_PORT>")
}
```

`<OPW_HOST>` is the IP/URL of the host (or load balancer) associated with the Observability Pipelines Worker.

- For CloudFormation installs, the `LoadBalancerDNS` CloudFormation output has the correct URL to use.
- For Kubernetes installs, the internal DNS record of the Observability Pipelines Worker service can be used, for example `opw-observability-pipelines-worker.default.svc.cluster.local`.

### syslog-ng{% #syslog-ng %}

To send syslog-ng logs to the Observability Pipelines Worker, update your syslog-ng config file:

```
destination obs_pipelines {
  http(
      url("<OPW_HOST>")
      method("POST")
      body("﹤${PRI}>1 ${ISODATE} ${HOST:--} ${PROGRAM:--} ${PID:--} ${MSGID:--} ${SDATA:--} $MSG\n")
  );
};
```

`<OPW_HOST>` is the IP/URL of the host (or load balancer) associated with the Observability Pipelines Worker.

- For CloudFormation installs, the `LoadBalancerDNS` CloudFormation output has the correct URL to use.
- For Kubernetes installs, the internal DNS record of the Observability Pipelines Worker service can be used, for example `opw-observability-pipelines-worker.default.svc.cluster.local`.

## Forward third-party logs to the Observability Pipelines Worker{% #forward-third-party-logs-to-the-observability-pipelines-worker %}

Syslog is a widely used logging protocol for sending network logs to a central server. Many network devices support syslog output, so you can forward third-party logs to the Observability Pipelines's syslog source for processing and routing. Examples of these third-party services include:

### Fortinet{% #fortinet %}

- [Configure log forwarding](https://help.fortinet.com/fa/faz50hlp/56/5-6-1/FMG-FAZ/2400_System_Settings/1600_Log%20Forwarding/0400_Configuring.htm)
- [Configuring syslog settings](https://help.fortinet.com/fadc/4-5-1/olh/Content/FortiADC/handbook/log_remote.htm)

### Palo Alto Networks{% #palo-alto-networks %}

- [Configure log forwarding](https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-admin/monitoring/configure-log-forwarding)
- [Forward traffic logs to a syslog server](https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClRxCAK)