Edge Delta Splunk HEC Destination

Configure the Edge Delta Splunk destination to send telemetry data using the Splunk output node with optional TLS, compression, and token passthrough settings.

  8 minute read  

Overview

The Splunk destination node sends items to a Splunk destination. It sends raw bytes generated by marshaling items as JSON.

This node requires Edge Delta agent version v0.1.57 or higher.

Configure Splunk

See Send Data to Splunk.

Configure Edge Delta

Next, you configure the Edge Delta agent to forward data to the Splunk endpoint.

Example Configuration

- name: my_splunk
  type: splunk_output
  index: my_index
  endpoint: <REDACTED>
  token: <REDACTED>

Required Parameters

name

A descriptive name for the node. This is the name that will appear in pipeline builder and you can reference this node in the YAML using the name. It must be unique across all nodes. It is a YAML list element so it begins with a - and a space followed by the string. It is a required parameter for all nodes.

nodes:
  - name: <node name>
    type: <node type>

type: splunk_output

The type parameter specifies the type of node being configured. It is specified as a string from a closed list of node types. It is a required parameter.

nodes:
  - name: <node name>
    type: <node type>

endpoint

The endpoint parameter is the full Splunk HEC URI. It is specified as a string and is required.

- name: my_splunk
  type: splunk_output
  endpoint: <REDACTED>
  token: <REDACTED>

index

The index parameter defines which index the node should flush data into. It is specified as a string. As of v2.5.0, this parameter is optional and can be left empty to use the default index configured in Splunk HEC.

- name: my_splunk
  type: splunk_output
  endpoint: <REDACTED>
  token: <REDACTED>
  index: <index>

token

The token parameter provides the Splunk HEC token. It is written as a string and is required.

- name: my_splunk
  type: splunk_output
  endpoint: <REDACTED>
  token: <REDACTED>

Optional Parameters

token_expression

Minimum Agent Version: v2.5.0

The token_expression parameter allows you to dynamically override the Splunk HEC token using an OTTL expression. This advanced parameter enables token passthrough scenarios where tokens captured by the Splunk HEC input node can be used to forward data to Splunk with the same authentication context. It is specified as a string containing an OTTL expression and is optional.

When configured, this expression is evaluated for each data item, and if it returns a valid token value, that token will be used instead of the static token configured in the token parameter. A common use case is to reference resource["splunk_token"] which contains the token captured by the Splunk HEC input node when attributes_from_header includes Authorization.

- name: my_splunk
  type: splunk_output
  endpoint: <REDACTED>
  token: <DEFAULT_TOKEN>
  token_expression: resource["splunk_token"]

Token Passthrough Example:

nodes:
  # Splunk HEC input captures the original token
  - name: splunk_in
    type: splunk_hec_input
    port: 8088
    read_timeout: 30s
    attributes_from_headers:
      - Authorization  # Captures token to resource.splunk_token

  # Splunk output uses the captured token
  - name: splunk_out
    type: splunk_output
    endpoint: https://splunk.example.com:8088/services/collector
    token: default-fallback-token
    override_token_expression: resource["splunk_token"]
    index: forwarded_events

links:
  - from: splunk_in
    to: splunk_out

In this configuration:

  1. The Splunk HEC input captures the authorization token from incoming requests
  2. The token is stored in resource.splunk_token on each data item
  3. The Splunk output evaluates the override_token_expression for each item
  4. If a token exists in resource["splunk_token"], it’s used for authentication
  5. If no token is found, the static token parameter value is used as fallback

compression

Minimum Agent Version: v2.7.0

The compression parameter specifies the compression format to use when sending data to Splunk. Compression reduces bandwidth usage and improves transfer efficiency. It is specified as a string from a closed list and is optional. The default value is gzip.

Available compression options:

  • gzip - Compress data using gzip format (default, recommended)
  • uncompressed - Send data without compression
- name: my_splunk
  type: splunk_output
  endpoint: <REDACTED>
  token: <REDACTED>
  compression: gzip

When to use compression:

  • Use gzip (default): Recommended for most scenarios to reduce network bandwidth and improve throughput, especially when sending large volumes of data over WAN connections or to cloud-hosted Splunk instances.
  • Use uncompressed: Only when troubleshooting data transfer issues or when network inspection/debugging requires uncompressed traffic. Note that this may significantly increase bandwidth usage.

tls

Configure TLS settings for secure connections to this destination. TLS is optional and typically used when connecting to endpoints that require encrypted transport (HTTPS) or mutual TLS.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      <tls options>

Enable TLS

Enables TLS encryption for outbound connections to the destination endpoint. When enabled, all communication with the destination will be encrypted using TLS/SSL. This should be enabled when connecting to HTTPS endpoints or any service that requires encrypted transport. (YAML parameter: enabled)

Default: false

When to use: Enable when the destination requires HTTPS or secure connections. Always enable for production systems handling sensitive data, connections over untrusted networks, or when compliance requirements mandate encryption in transit.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      enabled: true

Ignore Certificate Check

Disables TLS certificate verification, allowing connections to servers with self-signed, expired, or invalid certificates. This bypasses security checks that verify the server’s identity and certificate validity. (YAML parameter: ignore_certificate_check)

Default: false

When to use: Only use in development or testing environments with self-signed certificates. NEVER enable in production—this makes your connection vulnerable to man-in-the-middle attacks. For production with self-signed certificates, use ca_file or ca_path to explicitly trust specific certificates instead.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      ignore_certificate_check: true  # Only for testing!

CA Certificate File

Specifies the absolute path to a CA (Certificate Authority) certificate file used to verify the destination server’s certificate. This allows you to trust specific CAs beyond the system’s default trusted CAs, which is essential when connecting to servers using self-signed certificates or private CAs. (YAML parameter: ca_file)

When to use: Required when connecting to servers with certificates signed by a private/internal CA, or when you want to restrict trust to specific CAs only. Choose either ca_file (single CA certificate) or ca_path (directory of CA certificates), not both.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      ca_file: /certs/ca.pem

CA Certificate Path

Specifies a directory path containing one or more CA certificate files for verifying the destination server’s certificate. Use this when you need to trust multiple CAs or when managing CA certificates across multiple files. All certificate files in the directory will be loaded. (YAML parameter: ca_path)

When to use: Alternative to ca_file when you have multiple CA certificates to trust. Useful for environments with multiple private CAs or when you need to rotate CA certificates without modifying configuration. Choose either ca_file or ca_path, not both.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      ca_path: /certs/ca-certificates/

Certificate File

Path to the client certificate file (public key) used for mutual TLS (mTLS) authentication with the destination server. This certificate identifies the client to the server and must match the private key. The certificate should be in PEM format. (YAML parameter: crt_file)

When to use: Required only when the destination server requires mutual TLS authentication, where both client and server present certificates. Must be used together with key_file. Not needed for standard client TLS connections where only the server presents a certificate.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      crt_file: /certs/client-cert.pem
      key_file: /certs/client-key.pem

Private Key File

Path to the private key file corresponding to the client certificate. This key must match the public key in the certificate file and is used during the TLS handshake to prove ownership of the certificate. Keep this file secure with restricted permissions. (YAML parameter: key_file)

When to use: Required for mutual TLS authentication. Must be used together with crt_file. If the key file is encrypted with a password, also specify key_password. Only needed when the destination server requires client certificate authentication.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      crt_file: /certs/client-cert.pem
      key_file: /certs/client-key.pem
      key_password: <password>  # Only if key is encrypted

Private Key Password

Password (passphrase) used to decrypt an encrypted private key file. Only needed if your private key file is password-protected. If your key file is unencrypted, omit this parameter. (YAML parameter: key_password)

When to use: Optional. Only required if key_file is encrypted/password-protected. For enhanced security, use encrypted keys in production environments. If you receive “bad decrypt” or “incorrect password” errors, verify the password matches the key file encryption.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      crt_file: /certs/client-cert.pem
      key_file: /certs/encrypted-client-key.pem
      key_password: mySecurePassword123

Minimum TLS Version

Minimum TLS protocol version to use when connecting to the destination server. This enforces a baseline security level by refusing to connect if the server doesn’t support this version or higher. (YAML parameter: min_version)

Available versions:

  • TLSv1_0 - Deprecated, not recommended (security vulnerabilities)
  • TLSv1_1 - Deprecated, not recommended (security vulnerabilities)
  • TLSv1_2 - Recommended minimum for production (default)
  • TLSv1_3 - Most secure, use when destination supports it

Default: TLSv1_2

When to use: Set to TLSv1_2 or higher for production deployments. Only use TLSv1_0 or TLSv1_1 if connecting to legacy servers that don’t support newer versions, and be aware of the security risks. TLS 1.0 and 1.1 are officially deprecated.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      min_version: TLSv1_2

Maximum TLS Version

Maximum TLS protocol version to use when connecting to the destination server. This is typically used to restrict newer TLS versions if compatibility issues arise with specific server implementations. (YAML parameter: max_version)

Available versions:

  • TLSv1_0
  • TLSv1_1
  • TLSv1_2
  • TLSv1_3

When to use: Usually left unset to allow the most secure version available. Only set this if you encounter specific compatibility issues with TLS 1.3 on the destination server, or for testing purposes. In most cases, you should allow the latest TLS version.

YAML Configuration Example:

nodes:
  - name: <node name>
    type: <destination type>
    tls:
      max_version: TLSv1_3