Integrating Bindplane Into Your Splunk Environment

Originally published August 2023. Updated August 2026.

Part 1 of 2: Connecting The Pieces

Splunk is a popular logging platform, and in Splunk Cloud it handles metrics too. Bindplane sits alongside it rather than replacing it. A Bindplane (BDOT) collector can accept data from a Splunk forwarder and send data into a Splunk indexer, so it works in both directions.

That two-way placement is the useful part. Telemetry signals that Splunk does not natively support can be brought in through Bindplane. The same telemetry data can go to other platforms at the same time.

Prerequisites

Bindplane, and at least one Bindplane collector
A Splunk environment with:
- A Universal Forwarder, sending data into the collector
- A Heavy Forwarder, receiving data from the collector
- An Indexer, receiving data from the Heavy Forwarder

Plan the Architecture

A Splunk Universal Forwarder sends data to the Bindplane collector. The collector sends that data to two places: a Splunk Heavy Forwarder, and Google Cloud Logging. The Heavy Forwarder passes its copy on to the Splunk Indexer.

The Heavy Forwarder is in this path because most Splunk estates already have one, with an HTTP Event Collector endpoint already exposed. If yours does not, point the collector straight at your indexer or at Splunk Cloud instead. The Bindplane side of the configuration is identical either way, and only the hostname changes.

Configuring the Universal Forwarder

By default the Universal Forwarder sends data over TCP in Splunk's proprietary Splunk to Splunk (S2S) protocol. The Bindplane collector does not speak S2S, so the forwarder needs to send raw data instead. Set sendCookedData to false in a tcpout stanza, and make that stanza the defaultGroup.

1[tcpout]
2defaultGroup = bindplane
3
4[tcpout:bindplane]
5server = localhost:8779
6compressed = false
7useACK = false
8sendCookedData = false

Restart the forwarder after saving. It will retry the connection until something is listening on port 8779, which happens when the Bindplane configuration is rolled out later in this post.

Configuring the Heavy Forwarder

The Heavy Forwarder needs an HTTP Event Collector (HEC) data input. This is how the collector sends data back into Splunk.

Create a token under Settings, then Data Inputs, then HTTP Event Collector. Give it a name and point it at the index you want. Here the token is SplunkHECFromBindplane and the index is bindplane.

HEC also has to be enabled globally, which is a separate switch from the token itself. Open Global Settings and set All Tokens to Enabled. Note the HTTP port number, since the Bindplane destination needs it.

Bindplane Configuration

In Bindplane, build a configuration whose source matches the port in the forwarder's tcpout:bindplane stanza, and whose destination matches the HEC input.

The source is TCP Logs, listening on the port the Universal Forwarder is sending to.

The destination is Splunk (HEC). It takes the hostname and port of the HEC endpoint, the token, and the target index.

Add the Google Cloud Logging destination to the same configuration to get the second copy of the data. Save the configuration and click Start Rollout to push it to the collector.

Data Flowing

Once the rollout completes, the pipeline graph shows data moving through the collector to both destinations.

The same data is searchable in Splunk.

It is also being written to Google Cloud Logging, which part 2 looks at more closely.

Conclusion

With the proper configuration in place, data is actively flowing through the Bindplane collector. This integration gives great flexibility in data input and extraction.

In part 2 of this series, additional sources will be implemented into the pipeline, which can be sent into the Splunk ecosystem. Data duplication for Google Cloud Logging will also be examined.

For questions, requests, and suggestions, come find us in the community Slack.