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.
• Node and network audit. OpenShift Logging also forwards the nodes’ auditd log and the OVN network audit log. Collectord reads the audit logs of the Kubernetes, OpenShift and OAuth API servers and the OAuth server, not those two.

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 delivers data into indexes and stops there, and for Splunk Enterprise or Cloud the OpenTelemetry Collector comes with community apps at most. 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; the Workload page shows any one of them 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 (ten alert templates), kubelet, scheduler, controller, scraped by the DaemonSet on the nodes that run them
• 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: 117 templates in the Alert Catalog, scoped to clusters and projects, 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, a template that reads a pod or namespace label lets teams pick an index, but filtering, masking and multiline stay in the ClusterLogForwarder a cluster admin owns, or in 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. Reading anything else means setting the operator to Unmanaged, which Red Hat does not support. Collectord reads application logs on emptyDir, hostPath and persistentVolumeClaim volumes once the pod names the volume in an annotation, 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 for amd64 on registry.connect.redhat.com, and FIPS 140 validated images for amd64 and arm64 from our own registry, 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 one DaemonSet, 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, every Collectord product, up to 384 vCPUs
• Self-service or annual licensing - per vCPU, priced openly
• Offline (air-gapped) licensing - on Business and Enterprise contracts from 4,000 vCPUs, and as an offline evaluation license on request

→ 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. Kubernetes events reach it only through the Event Router, a separate deployment that writes them to its log. Metrics 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, set only together with payloadKey. The template lives in the ClusterLogForwarder, which a cluster admin owns; it can read a pod or namespace label, so teams can choose an index by labelling. With Collectord the annotation also carries filtering, masking and multiline settings.

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.11 or later 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 the Red Hat build of OpenTelemetry? It is the collector Red Hat supports with the OpenShift subscription, and it has no Splunk HEC exporter: Red Hat points to OTLP instead. Splunk’s Splunk Connect for OTLP add-on accepts OTLP logs, metrics and traces, so this collector, and OpenShift Logging’s OTLP output (generally available since Logging 6.5), can reach Splunk Enterprise or Cloud that way. Neither comes with Splunk dashboards or alerts for the data.

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.