Technology1 min read

Make Kubernetes logs easier to correlate with traces using the log normalizer operator

By · Published by Everything Blog

In short

The log normalizer operator automatically deploys a native sidecar into designated pods to intercept and structure inconsistent standard output and standard error streams. It handles diverse inputs, such as JSON, Zap console formats, and klog, while reassembling broken multiline entries. Normalizing data at the source enables correlation engines like Korrel8r to reliably connect container logs to their associated distributed traces. Output can be monitored via standard Kubernetes logging mechanisms or transmitted over OTLP directly to an OpenTelemetry collector.

Key points

  • Deploying pod-level normalizer sidecars eliminates the need to alter application source c…: Deploying pod-level normalizer sidecars eliminates the need to alter application source code or maintain custom logging libraries.
  • Standardizing disparate log outputs facilitates seamless trace-to-log correlation in tool…: Standardizing disparate log outputs facilitates seamless trace-to-log correlation in tools such as Korrel8r.
  • Transmitting normalized records through OTLP relieves centralized OpenTelemetry collector…: Transmitting normalized records through OTLP relieves centralized OpenTelemetry collectors from managing complicated parsing rules.

Sources checked by our analysis pipeline: 1

The log normalizer operator for Red Hat OpenShift injects a sidecar into selected pods, captures application output without requiring application code changes, detects the input format, reassembles multiline entries, and emits a consistent structured record. The normalized record remains available through kubectl logs

and can also be exported to an OpenTelemetry collector over OTLP.

Modern Kubernetes applications rarely produce logs in a consistent format. A single namespace can contain JSON and structured logs from a service, golang logfmt from a component, klog from Kubernetes libraries, Zap console output from an operator, and plain-text stack traces from a Python or Java dependency. That variety becomes a practical observability problem when an engineer just wants know what logs were produced by a trace. Tools like Korrel8r can navigate between related observability signals, but correlation depends on signals sharing useful identifiers and queryable resource information. If every component uses different field names, or if the trace and Kubernetes identity are missing from the log record, there is little for a correlation tool to match. The log normalizer operator addresses this problem at the…

Technology