The OpsRamp Kubernetes 2.0 Agent automatically classifies the severity of every pod log entry and assigning a level like Info, Error, or Fatal before the log is sent to the OpsRamp platform. You can then use that classification to filter out low-value logs (like routine Info messages) so only logs above a chosen severity threshold reach the platform.

This page explains how the agent determines a log’s severity, and how to configure filtering based on it.

Prerequisites

• Log Management is enabled for your client.
• Pod log collection is enabled, see Configuring Pod Log Collection.
• Agent version 22.0 or later.

How the Agent classifies log severity

The agent evaluates each pod log entry using three detection methods, applied in order. As soon as one method finds a match, classification stops and the agent does not continue checking the remaining methods.

1. Klog prefix detection

Kubernetes system components (kube-apiserver, kube-scheduler, kubelet, etcd, and others) use the klog logging library, which prefixes each line with a single character and a timestamp:

I0607 12:30:45.123456  12345 controller.go:100] Starting reconciliation
E0607 12:30:46.654321  12345 controller.go:150] Failed to reconcile resource

The agent detects the following klog prefixes:

Example: W0607 14:22:03.456789 54321 handler.go:200] Deprecated API version called is classified as Warn, because it starts with the W prefix followed by digits.

2. Keyword-based detection

If a log entry doesn’t match a klog prefix, the agent scans the log body for severity keywords, using word-boundary matching. This means, the keyword must stand alone (surrounded by non-alphanumeric characters, or the start/end of the line), not be embedded inside another word.

Matching is case-insensitive. For example, error inside myerrorhandler does not match (it’s embedded in another word), but [ERROR] or error: does match (it’s a standalone token).

Example: 2026-07-07 10:15:30 ERROR [main] com.app.Service - Connection refused is classified as Error, because ERROR is detected as a standalone keyword.

3. stdout/stderr stream fallback

If neither a klog prefix nor a keyword is found, the agent falls back to the container’s output stream:

Example: connection pool exhausted, retrying in 5s written to stderr, with no matching keyword, is classified as Error — purely because of the stream it came from.

This fallback also applies to empty or missing log bodies: an empty message on stderr is classified as Error, and on stdout as Info.

Severity level ordering

The full severity hierarchy, from highest to lowest:

Emergency = Alert = Critical = Fatal > Error > Warn > Notice = Info > Verbose = Debug > Trace > Unspecified/Unknown

Levels joined by = share the same priority tier for filtering purposes, for example, filtering at Fatal also keeps Emergency, Alert, and Critical logs, since they’re all in the same tier.

Configuring log-level filter

Set the log_level field under pods in the opsramp-logs-user-config ConfigMap to your desired threshold:

kubectl edit configmap opsramp-logs-user-config -n <agent-installed-namespace>

pods:
  enable: true
  log_level: "Warn"

This example keeps logs classified as Warn or higher (Warn, Error, Fatal, Critical, Alert, Emergency) and drops everything below Warn (Notice, Info, Verbose, Debug, Trace, Unspecified/Unknown).

Note: log_level accepts only string values and is case-insensitive. Valid values are: Emergency, Alert, Critical, Fatal, Error, Warn, Notice, Info, Verbose, Debug, Trace, Unspecified. The default is Unspecified, which applies no filtering and sends all logs.

What gets kept at each filter level

Examples