Collect Kubernetes pod logs

Overview

The osuite-k8s Helm chart is the supported way to collect pod logs from a Kubernetes cluster. Its node collector tails each pod’s log files with the OpenTelemetry Collector filelog receiver, enriches every record with workload identity through the k8sattributes processor, and forwards the logs to Osuite over OTLP.

Note

Pod logs are collected by the filelog receiver and enriched by k8sattributes. The k8sobjects receiver collects Kubernetes events, not pod logs — see Kubernetes events.

Prerequisites

• A Kubernetes cluster with kubectl and Helm.
• The osuite-k8s chart installed, or ready to install — see the Kubernetes overview.
• An Osuite ingest token.

Enable collection

Container-log collection is off by default. Turn it on under otel_daemon.containerlogs. With namespaces empty, the chart collects logs from every namespace, pod, and severity level:

otel_daemon:
  containerlogs:
    enabled: true
    namespaces: []

To scope collection down, add one entry per namespace. Each entry names a namespace and optionally narrows it by pod name and severity:

Field	Effect	Omitted
name	Namespace to collect from.	— (required per entry)
include	Pod-name regexes; a pod is kept only if it matches at least one.	All pods in the namespace
exclude	Pod-name regexes; a matching pod is dropped. Exclude wins over include.	Nothing excluded
levels	Severity values to keep — ERROR, WARN, or INFO.	All severity levels

Caution

The namespaces list is a whitelist. Once it is non-empty, logs from any namespace not listed are dropped. List every namespace you want to keep collecting.

Values example

A complete values.yaml that enables collection, scopes it to the production namespace, and keeps only errors and warnings from the API and web pods:

common:
  osuite_ingest_endpoint: ingest.<region>.osuite.io:443
  osuite_ingest_key: <your-ingest-token>
  insecure: false

environment: production

otel_daemon:
  containerlogs:
    enabled: true
    namespaces:
      - name: "production"
        include: ["^api-.*", "^web-.*"]
        exclude: [".*-debug-.*"]
        levels: ["ERROR", "WARN"]

Apply it with a helm upgrade:

helm upgrade osuite-k8s osuite/osuite-k8s \
  --namespace osuite \
  --values values.yaml

Parsing and enrichment

• Workload identity — k8sattributes attaches k8s.namespace.name, k8s.pod.name, and the owning deployment, statefulset, or daemonset. service.name is derived from that workload, so logs line up with the same service in APM.
• Severity — the chart derives severity_text from the log body (ERROR, WARN, or INFO), defaulting to INFO for stdout and ERROR for stderr when no level keyword is present. Use only those three values in levels.
• Environment — the top-level environment value is attached as service.environment.

For the full field reference and more filter examples, see Container logs. To wire the same filelog + k8sattributes path by hand without Helm, see Kubernetes monitoring with a manual collector. Running plain Docker instead of Kubernetes? See Docker container logs.

Verify in Osuite

What you should see

Within a minute of the upgrade, logs from the collected pods appear in the Logs Explorer, grouped under their owning service and tagged with k8s.namespace.name and k8s.pod.name. Filtering by severity returns only the levels you allowed.

Troubleshooting

• A namespace you expected is missing — once namespaces is non-empty it becomes a whitelist; confirm the namespace is listed by exact name.
• A pod matched by include is still dropped — check exclude; an exclude match always wins over an include match.
• A severity filter drops everything — confirm the values are among ERROR, WARN, and INFO; no other severity is produced.

No data in Osuite after a few minutes? Work through these checks.

• Endpoint — confirm the exporter targets exactly ingest.<region>.osuite.io:443 for your region, over TLS.
• Token — confirm the ingest header carries a valid <your-ingest-token> and has not been rotated.
• Pipeline — confirm the signal you expect (traces, logs, or metrics) is wired into an active pipeline with the otlp/osuite exporter attached.
• Export errors — check the application or Collector logs for OTLP export failures (auth, DNS, TLS, connection refused).
• Network — confirm the host has outbound access to the ingest endpoint on port 443.
• Timing — allow up to a minute for the first data to appear before assuming a failure.

Still stuck? Ask the Investigation Agent or contact support.