These docs are for Cribl Edge 4.1 and are no longer actively maintained.

See the latest version (4.13).

Splunk HEC

Cribl Edge supports receiving data over HTTP/S using the Splunk HEC (HTTP Event Collector).

Type: Push | TLS Support: YES | Event Breaker Support: YES

This Source supports gzip-compressed inbound data when the Content‑Encoding: gzip connection header is set.

Configuring Cribl Edge to Receive Data over Splunk HEC

​

From the top nav, click Manage, then select a Fleet to configure. Next, you have two options:

To configure via the graphical QuickConnect UI, click Routing > QuickConnect (Stream) or Collect (Edge). Next, click Add Source at left. From the resulting drawer’s tiles, select [Push > ] Splunk > HEC. Next, click either Add Destination or (if displayed) Select Existing. The resulting drawer will provide the options below.

Or, to configure via the Routing UI, click Data > Sources (Stream) or More > Sources (Edge). From the resulting page’s tiles or left nav, select [Push > ] Splunk > HEC. Next, click New Source to open a New Source modal that provides the options below.

Cribl Edge ships with a Splunk HEC Source preconfigured to listen on Port 8088. You can clone or directly modify this Source to further configure it, and then enable it.

General Settings

​

Input ID: Enter a unique name to identify this Splunk HEC Source definition.

Address: Enter the hostname/IP on which to listen for HTTP(S) data. E.g.: localhost or 0.0.0.0. Supports IPv4 and IPv6 addresses.

Port: Enter the port number.

Splunk HEC endpoint: Absolute path on which to listen for the Splunk HTTP Event Collector API requests. Defaults to /services/collector.

This single endpoint supports JSON events via /event, raw events via /raw, and Splunk S2S events via /s2s. See the examples below. The Source will automatically detect where to forward the request.

Optional Settings

​

Allowed Indexes: List the values allowed in the HEC event index field. Allows wildcards. Leave blank to skip validation.

Splunk HEC acks: Whether to enable Splunk HEC acknowledgments. Defaults to No. Some senders might require HEC acks to be enabled. As a result, they might keep TCP connections open while waiting for an ack; this behavior can exhaust available file descriptors. Cribl does not maintain a comprehensive list of senders that require acks – please refer to your sender’s documentation.

Tags: Optionally, add tags that you can use for filtering and grouping in Cribl Edge. Use a tab or hard return between (arbitrary) tag names.

TLS Settings (Server Side)

​

Enabled defaults to No. When toggled to Yes:

Certificate name: Name of the predefined certificate.

Private key path: Server path containing the private key (in PEM format) to use. Path can reference $ENV_VARS.

Passphrase: Passphrase to use to decrypt private key.

Certificate path: Server path containing certificates (in PEM format) to use. Path can reference $ENV_VARS.

CA certificate path: Server path containing CA certificates (in PEM format) to use. Path can reference $ENV_VARS.

Authenticate client (mutual auth): Require clients to present their certificates. Used to perform mutual authentication using SSL certs. Defaults to No. When toggled to Yes:

• Validate client certs: Reject certificates that are not authorized by a CA in the CA certificate path, or by another trusted CA (e.g., the system’s CA). Defaults to No.

• Common name: Regex matching subject common names in peer certificates allowed to connect. Defaults to .*. Matches on the substring after CN=. As needed, escape regex tokens to match literal characters. E.g., to match the subject CN=worker.cribl.local, you would enter: worker\.cribl\.local.

Minimum TLS version: Optionally, select the minimum TLS version to accept from connections.

Maximum TLS version: Optionally, select the maximum TLS version to accept from connections.

Persistent Queue Settings

​

In this section, you can optionally specify persistent queue storage, using the following controls. This will buffer and preserve incoming events when a downstream Destination is down, or exhibiting backpressure.

On Cribl-managed Cribl.Cloud Workers (with an Enterprise plan), this tab exposes only the Enable Persistent Queue toggle. If enabled, PQ is automatically configured in Always On mode, with a maximum queue size of 1 GB disk space allocated per Worker Process.

Enable Persistent Queue: Defaults to No. When toggled to Yes:

Mode: Select a condition for engaging persistent queues.

• Always On: This default option will always write events to the persistent queue, before forwarding them to Cribl Edge’s data processing engine.
• Smart: This option will engage PQ only when the Source detects backpressure from Cribl Edge’s data processing engine.

Max buffer size: The maximum number of events to hold in memory before reporting backpressure to the Source. Defaults to 1000.

Commit frequency: The number of events to send downstream before committing that Stream has read them. Defaults to 42.

Max file size: The maximum data volume to store in each queue file before closing it and (optionally) applying the configured Compression. Enter a numeral with units of KB, MB, etc. If not specified, Cribl Edge applies the default 1 MB.

Max queue size: The maximum amount of disk space that the queue is allowed to consume, on each Worker Process. Once this limit is reached, Cribl Edge will stop queueing data, and will apply the Queue‑full behavior. Enter a numeral with units of KB, MB, etc. If not specified, the implicit 0 default will enable Cribl Edge to fill all available disk space on the volume.

Queue file path: The location for the persistent queue files. Defaults to $CRIBL_HOME/state/queues. To this field’s specified path, Cribl Edge will append /<worker-id>/inputs/<input-id>.

Compression: Optional codec to compress the persisted data after a file is closed. Defaults to None; Gzip is also available.

As of Cribl Edge 4.1, Source-side PQ’s default Mode changed from Smart to Always on. This option more reliably ensures events’ delivery, and the change does not affect existing Sources’ configurations. However:

• If you create Stream Sources programmatically, and you want to enforce the previous Smart mode, you’ll need to update your existing code.
• If you enable Always on, this can reduce data throughput. As a trade-off for data durability, you might need to either accept slower throughput, or provision more machines/faster disks.
• You can optimize Workers’ startup connections and CPU load at Fleet Settings > Worker Processes.

Processing Settings

​

Event Breakers

​

This section defines event breaking rulesets that will be applied, in order, on the /raw endpoint.

Event Breaker rulesets: A list of event breaking rulesets that will be applied to the input data stream before the data is sent through the Routes. Defaults to System Default Rule.

Event Breaker buffer timeout: How long (in milliseconds) the Event Breaker will wait for new data to be sent to a specific channel, before flushing out the data stream, as-is, to the Routes. Minimum 10 ms, default 10000 (10 sec), maximum 43200000 (12 hours).

Fields

​

In this section, you can add Fields to each event using Eval-like functionality.

Name: Field name.

Value: JavaScript expression to determine field’s value (can be a constant).

Fields specified on the Fields tab will normally override fields of the same name in events. But you can specify that fields in events should override these fields’ values.

In particular, where incoming events have no index field, this Source adds one with the literal value default. You can override this value by using Add Field to specify an index field, and then setting its Value to an expression of the following form: index == 'default' ? 'myIndex' : index

Fields here are evaluated and applied after any fields specified in the Auth Tokens section.

Pre-Processing

​

In this section’s Pipeline drop-down list, you can select a single existing Pipeline to process data from this input before the data is sent through the Routes.

Auth Tokens

​

If empty (the default), the Splunk HEC Source will permit client access without an auth token. To generate and/or configure tokens, click Add Token, which exposes the following fields:

Token: Shared secret to be provided by any client (Authorization: <token>). Click Generate to create a new secret. If empty, unauthenticated access will be permitted.

Description: Optional description for this token.

Fields: Fields to add to events referencing this token. Each field is a Name/Value pair.

Fields specified on the Auth Tokens tab will normally override fields of the same name in events. But you can specify that fields in events should override these fields’ values.

In particular, where incoming events have no index field, this Source adds one with the literal value default. You can override this value by using Add Field to specify an index field, and then setting its Value to an expression of the following form: index == 'default' ? 'myIndex' : index

Fields here are evaluated and applied before any fields specified in the Fields section.

Advanced Settings

​

Use Universal Forwarder time zone (S2S only): Leave the default toggle set to Yes to have Event Breakers determine the time zone for events based on Universal Forwarder–provided metadata when the time zone can’t be inferred from the raw event.

CORS allowed origins: If you need to enable cross-origin resource sharing with Splunk senders, use this field to specify the HTTP origins to which Cribl Edge should send Access-Control-Allow-* headers. You can enter multiple domains and use wildcards. This and its companion CORS allowed headers option should seldom be needed – see Working with CORS Headers below. Both options are available in Cribl Edge 4.1.2 and later.

CORS allowed headers: List HTTP headers that Cribl Edge will send in a CORS preflight response to your configured (above) CORS allowed origins as Access-Control-Allow-Headers. Enter * to allow all headers.

Enable proxy protocol: Toggle to Yes if the connection is proxied by a device that supports Proxy Protocol v1 or v2. This setting affects how the Source handles the __srcIpPort field.

Capture request headers: Toggle this to Yes to add request headers to events, in the __headers field.

Max active requests: Maximum number of active requests allowed for this Source, per Worker Process. Defaults to 256. Enter 0 for unlimited.

Activity log sample rate: Determines how often request activity is logged at the info level. The default 100 value logs every 100th value; a 1 value would log every request; a 10 value would log every 10th request; etc.

Socket timeout (seconds): How long Cribl Edge should wait before assuming that an inactive socket has timed out. The default 0 value means wait forever.

Request timeout (seconds): How long to wait for an incoming request to complete before aborting it. The default 0 value means wait indefinitely.

Keep-alive timeout (seconds): After the last response is sent, Cribl Edge will wait this long for additional data before closing the socket connection. Defaults to 5 seconds; minimum is 1 second; maximum is 600 seconds (10 minutes).

The longer the Keep‑alive timeout, the more Cribl Edge will reuse connections. The shorter the timeout, the closer Cribl Edge gets to creating a new connection for every request. When request frequency is high, you can use longer timeouts to reduce the number of connections created, which mitigates the associated cost.

Environment: If you’re using GitOps, optionally use this field to specify a single Git branch on which to enable this configuration. If empty, the config will be enabled everywhere.

Connected Destinations

​

Select Send to Routes to enable conditional routing, filtering, and cloning of this Source’s data via the Routing table.

Select QuickConnect to send this Source’s data to one or more Destinations via independent, direct connections.

Internal Fields

​

Cribl Edge uses a set of internal fields to assist in handling of data. These “meta” fields are not part of an event, but they are accessible, and Functions can use them to make processing decisions.

Fields for this Source:

• __headers – Added only when Advanced Settings > Capture request headers is set to Yes.
• __hecToken
• __inputId
• __s2sVersion – value can be either v3 or v4. This field is present only when the Source is receiving S2S-encoded payloads.
• __srcIpPort – See details below.
• __TZ

Universal Forwarder Time Zone

​

The __TZ field uses the universal forwarder time zone to mitigate cases where incoming events have timestamp strings but no time zone information. Event Breakers use the __TZ field to derive time zone information, enabling them to set the _time field correctly. See Using the UF Time Zone for additional information.

Overriding __srcIpPort with Client IP/Port

​

The __srcIpPort field’s value contains the IP address and (optionally) port of the Splunk HEC client sending data to this Source.

When any proxies (including load balancers) lie between the Splunk HEC client and the Source, the last proxy adds an X‑Forwarded‑For header whose value is the IP/port of the original client. With multiple proxies, this header’s value will be an array, whose first item is the original client IP/port.

If X‑Forwarded‑For is present, and Advanced Settings > Enable proxy protocol is set to No, the original client IP/port in this header will override the value of __srcIpPort.

If Enable proxy protocol is set to Yes, the X‑Forwarded‑For header’s contents will not override the __srcIpPort value. (Here, the upstream proxy can convey the client IP/port without using this header.)

Working with CORS Headers

​

The CORS allowed origins and CORS allowed headers settings are needed only when you want JavaScript code running in a web browser to send events to the Splunk HEC Source. In this (uncommon) scenario, the code in question sends a preflight request that includes CORS (Cross-Origin Resource Sharing) headers, and the Splunk HEC Source includes CORS headers in its response.

If the settings (and thus the CORS headers in the response) are correct, the browser will allow the code in question to complete requests to the Splunk HEC Source – that is, allow the code to read the Source’s responses. (These settings are optional because for some web applications it’s sufficient to send requests without reading responses.)

The CORS header dance begins when the web browser sends a request with a header stating its origin. What happens next depends on how you’ve configured the CORS header settings, as explained in the tables below. (For these examples, we’ll assume an origin of https://mycoolwebapp:3001.)

The web browser’s request might also include an Access-Control-Request-Headers header that lists one or more headers that it wants to use in a subsequent POST request (i.e., the “actual” as opposed to preflight request). The Splunk HEC Source can then respond with an Access-Control-Allow-Headers header if and only if it’s also sending the Access-Control-Allow-Origin header.

Format and Endpoint Examples

​

Splunk HEC to Cribl Edge

​

• Configure Cribl Edge to listen on port 8088 with an auth token of myToken42.
• Send a payload to your Cribl Edge receiver.

Note: Token specification can be either Splunk <token> or <token>.

curl -k http://<myCriblHost>:8088/services/collector/event -H 'Authorization: myToken42' -d '{"event":"this is a sample event ", "host":"myHost", "source":"mySource", "fieldA":"valueA", "fieldB":"valueB"}'

curl -k http://<myCriblHost>:8088/services/collector -H 'Authorization: myToken42' -d '{"event":"this is a sample event ", "host":"myHost", "source":"mySource", "fieldA":"valueA", "fieldB":"valueB"}'

# Multiple Events
curl -k http://<myCriblHost>:8088/services/collector -H 'Authorization: myToken42' -d '{"event":"this is a sample event ", "host":"myHost", "source":"mySource", "fieldA":"valueA", "fieldB":"valueB"}{"event":"this is a sample event 2", "host":"myHost", "source":"mySource", "fieldA":"valueA", "fieldB":"valueB"}'

# Metrics Events
curl -k http://<myCriblHost>:8088/services/collector/event -H 'Authorization: myToken42' -d '{"event":"metric", "host":"myHost", "fields":{"_value":3850,"metric_name":"kernel.entropy_avail"}}'

curl -k http://<myCriblHost>:8088/services/collector/event -H 'Authorization: myToken42' -d '{"host":"myHost", "fields":{"_value":3850,"metric_name":"kernel.entropy_avail"}}'

# Send the auth token as a query parameter, with no additional configuration

curl -k "http://<myCriblHost>:8088/services/collector/event?token=mToken42" -d '{"event":"this is a sample event ", "host":"myHost", "source":"mySource", "fieldA":"valueA", "fieldB":"valueB"}'

curl -k http://<myCriblHost>:8088/services/collector/raw -H 'Authorization: myToken42' -d '<146>Jul 2 08:40:30 tpapigw02 c2b_server_1: APIGW-C2B: timestamp="07.02.2021 08:40:30,968" ip="10.88.157.144" filterType="ChangeMessageFilter"'

Splunk HEC to Cribl Cloud

​

• Navigate to Cribl Cloud’s Splunk HEC Source > Auth Tokens tab.
• Copy your token out of the Token field.
• From the command line, use https, your Cribl.Cloud portal’s Ingest Address and port, and the token’s value. You can find the Ingest Address on the top nav’s Network Settings page, under the Data Sources tab.

curl -k "https://in.main-default-<Your-Org-ID>.cribl.cloud:8088/services/collector" \
    -H "Authorization: <token_value>" \
    -d '{"event": "Goats are better than ponies."}{"event": "Goats are better climbers."}{"event": "Goats are great yoga buddies.", "nested": {"horns": "Two is better than one!"}}'