Integrating Bindplane Into Your Splunk Environment: Adding Journald

Originally published August 2023. Updated August 2026.

Part 2 of 2: Additional Sources & Destinations

It can often be challenging to collect data into a monitoring environment that does not natively support that data source. Bindplane can help solve this problem. The Bindplane (BDOT) collector is based on OpenTelemetry, and is as freeform as possible. You can bring in data from disparate sources that the Splunk Universal Forwarder does not easily support.

Prerequisites

The environment built in Part 1

Additional Data Sources

For this post I will use the systemd journal as an additional source. That data could be routed through the Splunk UF, but it is easier to collect it directly, since system logs in Splunk often require creating custom source types or installing a community app.

New Source in Bindplane

In Bindplane, add a new Journald source to your configuration. The following configuration values need to be set:

Priority: info
Start At: beginning

Setting “Start At” to beginning reads the journal the host already has, so data appears as soon as the rollout lands. That is what you want while following along. On a production fleet set it to end instead, or every collector you deploy re-ingests weeks of history on its first start.

Save the source and click Start Rollout to apply it to the collector.

Choosing What to Keep

Journald solves the parsing problem and hands you a different one. It gives you structure for free, and a lot of it. Across a single host's journal you will see dozens of distinct field names, most of them systemd internals. __CURSOR alone is a ninety character string that nothing downstream will ever query.

Deleting the noise field by field does not scale, because the field set varies by which unit wrote the record. Selecting what you want does. One Transform processor rebuilds the body with only the fields worth indexing:

1set(body, {"entry_type": "LinuxSystemMessages",
2           "message": body["MESSAGE"],
3           "hostname": body["_HOSTNAME"],
4           "process_name": body["SYSLOG_IDENTIFIER"],
5           "pid": body["_PID"]})
6  where IsString(body["MESSAGE"])

This is also where entry_type gets set, for consistency with the Splunk source metadata. I extract that field on the Splunk side for easy searches.

The result is a five field record: entry_type, hostname, message, pid, and process_name. The timestamp needs no field of its own, because the Journald source sets it on the record from the journal entry.

Data Flowing

The pipeline graph now shows both sources feeding both destinations.

The reduction figure on the Journald branch is the field trimming at work. Dropping the systemd internals removes a large fraction of every record before it reaches either destination.

In Splunk, the records look like this.

The same search in Google Cloud Logging looks like this.

Conclusion

Using a Bindplane collector to collect log data, virtually any logs can be sent to Splunk. Sending these logs to Google Cloud Logging or any other supported platform can also satisfy different use cases. It can also be used when moving from Splunk to another platform or vice versa, allowing you to, for a time, send data to both platforms. This aids transition by overlapping the two platforms and allowing you to make sure the new platform's capabilities match or exceed the ones you are leaving.

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