OpenShift logs to Splunk: OpenShift Logging, OpenTelemetry, or Collectord

Three ways to get OpenShift logs into Splunk

Red Hat OpenShift Logging forwards logs to Splunk out of the box: the ClusterLogForwarder has had a Splunk output since Logging 5.6, and since Logging 6.0 Vector is its only collector. The Splunk Distribution of the OpenTelemetry Collector lists OpenShift as a supported distribution. And Collectord, our agent, forwards logs, metrics, events and objects to Splunk and ships the Monitoring OpenShift app with them. Splunk Connect for Kubernetes, the fourth option for years, reached End of Support on January 1, 2024, and its repository was archived in June 2026 - if it still runs on your clusters, this page is your migration map too.

All three get container logs into an index. The difference is what happens before the logs leave the node - routing, filtering, masking, throttling, and who controls each of them - and what you can do in Splunk once they arrive. This page compares the three on exactly that, row by row.

Side-by-side comparison

Need tracing too? Collectord does not collect distributed traces. Run the OpenTelemetry Collector alongside it and route traces to Splunk Observability Cloud or any OTLP backend. The two coexist cleanly, and so do Collectord and OpenShift Logging - see running them side by side below.

Where OpenShift Logging is the right choice

Credit where due. OpenShift Logging comes with the subscription, Red Hat supports it, and for some jobs it is the better tool:

• You forward to more than Splunk. One ClusterLogForwarder can send the same logs to Splunk, Loki, CloudWatch, Kafka or an OTLP endpoint. Collectord speaks Splunk, Elasticsearch, OpenSearch and syslog, not the rest.
• Audit logs with server-side trimming. The kubeAPIAudit filter drops unwanted audit events and shrinks the rest before they leave the cluster. Collectord forwards the audit log as it is, and you trim in Splunk or with a blacklist.
• You already have the dashboards. If your team built its own Splunk content for your log format and never needs metrics or events, OpenShift Logging delivers the logs and asks for nothing more.
• Tenant-owned forwarders. A team that wants its own ClusterLogForwarder under RBAC, with its own collector, gets exactly that.

Everything else on this page is about the job OpenShift Logging stops at: the logs arrive, and then you build.

What you actually get with Collectord

A complete Splunk app for OpenShift

OpenShift Logging and the OpenTelemetry Collector deliver data into indexes and stop there. You are left to build dashboards, write alerts, and answer “is etcd healthy?” or “which project is over its quota?” in SPL, from scratch. Red Hat ships no Splunk content for ClusterLogForwarder data, and neither Splunkbase nor Red Hat’s catalog has any.

Collectord ships Monitoring OpenShift, a full Splunk app built for the objects an OpenShift administrator thinks in:

• Projects and workloads: every project with its DaemonSets, Deployments, DeploymentConfigs, BuildConfigs, builds and pods; one view per workload kind with its pods and events
• Events: Event Timeline, Event Overview, Workload Failures, Scheduling and Node Health, Recurring Problems - the triage views redesigned in 26.04
• Control plane: API server, etcd (eight dedicated alerts), kubelet, scheduler, controller, from the DaemonSet on the control-plane nodes
• Audit and security: the OpenShift API audit log by user and project, privileged containers and capabilities, pod security posture, sshd, sudo and exec access, network connections and traffic
• Capacity and quotas: allocatable resources, project usage, ResourceQuotas and ClusterResourceQuotas, CPU throttling, storage, disk and GPU
• Alerts: 37 pre-configured, with recommended severity, suppression and dispatch

→ Every dashboard in the app · Alert reference

Self-service routing via annotations

Need a project’s logs in a separate index? An app team to mask PII without filing a ticket? A noisy debug container silenced? Add an annotation. The platform team configures Collectord once; everything else is self-service, on the object the team already owns:

1oc annotate namespaces payments collectord.io/index=openshift_payments

The same works on a DeploymentConfig or a pod, for the index, source and sourcetype, for multiline patterns, for field extraction, and for the pipes that mask or hash sensitive data before it leaves the node. A cluster-wide Configuration resource sets the defaults, and force: true on it makes a policy - mandatory masking, a compliance index - win over any annotation. With OpenShift Logging the equivalent is a ClusterLogForwarder change by a cluster admin, or a forwarder per team with its own DaemonSet.

Throttling that delays instead of dropping

One chatty container can starve every other workload on the node. OpenShift Logging rate-limits in records per second, per container or per collector pod, and drops what is over the limit. Collectord caps bytes per second per container, and when a container goes over, it pauses reading and catches up once the rate drops:

1metadata:
2  annotations:
3    collectord.io/logs-ThruputPerSecond: 128Kb

Application logs from volumes, without sidecars

Java applications on OpenShift still write to files. OpenShift Logging collects pod logs, the journal and audit files, and the supported way to read anything else is to make your logging instance unmanaged. Collectord auto-discovers application logs on emptyDir, hostPath and persistentVolumeClaim volumes, forwards them with the pod’s metadata, and needs no sidecar for it.

Certified for OpenShift, validated for FIPS

Collectord ships a Red Hat certified image on registry.connect.redhat.com, and FIPS 140 validated images on amd64 and arm64, with an enforced mode (GODEBUG=fips140=only) for the environments that require it.

Multi-tenant ready

Each team can declare its own Splunk destination with a SplunkOutput resource in its project, with the HEC token in a Secret, and one log line can land in a security index and an application index at the same time through per-pod fan-out. No ConfigMap edit, no second DaemonSet.

Running Collectord next to OpenShift Logging

The two do not compete for anything on the node, so you do not have to switch at once. Most teams keep OpenShift Logging for what it does well and let Collectord take the Splunk path:

1. Install Collectord in its own project. A ten-minute install gives you two DaemonSets, one add-on Deployment, and the Monitoring OpenShift app. Use project annotations to scope which pods Collectord forwards first.
2. Reproduce your index routing. Whatever the ClusterLogForwarder’s index templates encode, project annotations or a Configuration resource express in minutes.
3. Verify the dashboards. The app installs into Splunk in minutes; the Overview shows the projects as data arrives.
4. Move project by project. Annotate the project, watch the data flow, then take it out of the ClusterLogForwarder’s Splunk pipeline. Keep the pipeline for destinations Collectord does not serve.
5. Decide what stays. Audit logs to a second destination, or a tenant’s own forwarder, can stay on OpenShift Logging indefinitely.

If you want a hand walking through it, request a demo and we will do a live migration walkthrough on your cluster.

Pricing and trial

Collectord is commercial software with a 30-day free trial - no credit card required.

• 30-day trial - full features, all products, no install limit
• Self-service or annual licensing - per vCPU, priced openly
• Air-gapped licensing - available on request for FIPS and classified environments

→ Start your trial · Pricing · Contact sales

Frequently asked questions

Does OpenShift Logging support Splunk? Yes. The ClusterLogForwarder has had a Splunk HEC output since Logging 5.6, Vector only, and it is a supported output in Logging 6.x. It forwards logs: application, infrastructure and audit. Metrics and events are not part of it.

Can I set the Splunk index per project with the ClusterLogForwarder? Yes, from Logging 6.0 the index is a template over record fields, for example {.kubernetes.namespace_name||"openshift"}. Source and indexed fields arrived in 6.3, the sourcetype in 6.6. The template lives in the ClusterLogForwarder, so a cluster admin owns it; with Collectord the project or the pod carries its own annotation.

Does Red Hat provide Splunk dashboards for ClusterLogForwarder data? No. Red Hat’s documentation describes the HEC event format so you can build searches, dashboards and alerts yourself, and Splunkbase has no app for ClusterLogForwarder data. The Monitoring OpenShift app is built for the data Collectord forwards.

Can Collectord and OpenShift Logging run at the same time? Yes. They are independent: OpenShift Logging can keep forwarding to Loki, CloudWatch or a second Splunk while Collectord forwards to Splunk, and you can move projects over one at a time.

Is Collectord supported on OpenShift? Yes. Collectord ships a Red Hat certified image, runs on OpenShift 4.x with a SecurityContextConstraints object of its own, and the Monitoring OpenShift app is on Splunkbase. See the installation guide for the current requirements.

What about Splunk Connect for Kubernetes on OpenShift? It reached End of Support on January 1, 2024, and its repository was archived in June 2026. Migrate: the Splunk Connect for Kubernetes comparison covers the path step by step, and it applies to OpenShift unchanged.