OpenShift Logging 6 changes the Splunk source contract after a 5.x upgrade

Red Hat has documented a migration edge case in which an upgrade from OpenShift Logging 5.x to 6.x changes the source values arriving at Splunk. The verified solution, updated Sept. 19, says events no longer inherit the default source configured on the Splunk HTTP Event Collector token. Instead, Splunk can show sources such as openshiftAPI, kubeAPI, or namespace_name_podName_containerName.

What changed

This is a metadata-contract change, not simply a forwarding outage. Events can continue reaching Splunk while landing under different source values. That distinction matters because saved searches, dashboards, alerts, role filters and retention rules may select data by source even when operators usually navigate by index or sourcetype.

Red Hat lists OpenShift Container Platform 4.16 and later with OpenShift Logging 6.x as the affected environment. Its public description also says that setting a static source containing a colon—http:my_source, for example—in ClusterLogForwarder fails schema validation. The remediation details are subscriber-only, so teams should not infer an escaping syntax from the rejected value.

What to validate

Before the migration, capture representative Splunk events from application, infrastructure and audit inputs. Record their index, sourcetype and source, then inventory any knowledge objects that filter on those fields. Include scheduled searches, alert rules, dashboards, data-model constraints and retention or routing configuration maintained outside OpenShift.

After moving to Logging 6, send a small known sample from each input class and compare the resulting metadata. A useful acceptance test proves both delivery and discoverability: the expected event count arrives, existing operational searches still find it, and downstream policies do not silently split one logical stream across new source names.

If a unified source is required, validate the intended ClusterLogForwarder value against the live API before rollout. A value rejected by admission will not become valid merely because Splunk accepts the same string.

Migration checklist

1. Export the existing ClusterLogForwarder and Splunk HEC configuration.
2. Inventory queries and policies that constrain source.
3. Establish pre-upgrade event samples and counts for all three log classes.
4. Upgrade a non-production path first and inspect the actual Splunk metadata.
5. Update searches, dashboards and retention rules—or configure a supported static source—before production cutover.
6. Keep the old and new queries side by side during the validation window.

The important control is to test metadata semantics, not only whether the HEC endpoint returns success.