Splunk Heavy or Universal Forwarders (TCP) Source

This product is not supported for your selected Datadog site. ().
Available for:

Logs

Use Observability Pipelines’ Splunk Heavy and Universal Forwards (TCP) source to receive logs sent to your Splunk forwarders. Select and set up this source when you set up a pipeline.

Prerequisites

To use Observability Pipelines’ Splunk TCP source, you have a Splunk Enterprise or Cloud Instance alongside either a Splunk Universal Forwarder or a Splunk Heavy Forwarder routing data to your Splunk instance. You also have the following information available:

  • The bind address that your Observability Pipelines Worker 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.
  • The appropriate TLS certificates and the password you used to create your private key if your forwarders are globally configured to enable SSL.

See Deploy a Universal Forwarder or Deploy a Heavy Forwarder for more information on Splunk forwarders.

Set up the source in the pipeline UI

Select and set up this source when you set up a pipeline. The information below is for the source settings in the pipeline UI.

Only enter the identifiers for the Splunk TCP address and, if applicable, the TLS key pass. Do not enter the actual values.
  • Enter the identifier for your Splunk TCP address. If you leave it blank, the default is used.

Optional settings

Click the toggle to Enable TLS. If you enable TLS, the following certificate and key files are required:

  • Enter the identifier for your Splunk TCP key pass. If you leave it blank, the default is used.
  • Server Certificate Path: The path to the certificate file that has been signed by your Certificate Authority (CA) root file in DER or PEM (X.509).
  • CA Certificate Path: The path to the certificate file that is your Certificate Authority (CA) root file in either DER or PEM (X.509).
  • Private Key Path: The path to the .key private key file that belongs to your Server Certificate Path in DER or PEM (PKCS#8) format.

Set secrets

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

Note: If you enter identifiers for your secrets 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.

    • Splunk TCP address identifier:
      • References the socket address, such as 0.0.0.0:9997 on which the Observability Pipelines Worker listens to receive logs from the Splunk Forwarder.
      • The default identifier is SOURCE_SPLUNK_TCP_ADDRESS.
    • Splunk TCP TLS passphrase identifier (when TLS is enabled):
      • The default identifier is SOURCE_SPLUNK_TCP_KEY_PASS.
    • Splunk TCP address:
      • The Observability Pipelines Worker listens to this socket address to receive logs from the Splunk Forwarder. For example, 0.0.0.0:9997.
      • The default environment variable is DD_OP_SOURCE_SPLUNK_TCP_ADDRESS.
    • Splunk TCP TLS passphrase (when enabled):
      • The default environment variable is DD_OP_SOURCE_SPLUNK_TCP_KEY_PASS.

    Connect Splunk Forwarder to the Observability Pipelines Worker

    To forward your logs to the Worker, add the following configuration to your Splunk Heavy/Universal Forwarder’s etc/system/local/outputs.conf and replace <OPW_HOST> with the IP/URL of the host (or load balancer) associated with the Observability Pipelines Worker:

    [tcpout]
compressed=false
sendCookedData=false
defaultGroup=opw

[tcpout:opw]
server=<OPW_HOST>:8099

    <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.

    At this point, your logs should be going to the Worker, processed by the pipeline, and delivered to the configured destination.