How It Works

Dash0 employs a sophisticated approach to understand and classify log severities:

Analyzes log message structure using language models and semantic heuristics
Extracts severity-related text from the log message content
Infers the appropriate severity level based on the extracted information
Tags the log with the inferred severity for improved filtering and analysis

Accessing Logs with Inferred Severity

To find log messages with AI-inferred severity levels:

Navigate to the Dash0 logging view
Apply the filter: dash0.log.ai.severity_inferred=true
Open any log record in the filtered results
View the "AI Inferred" label next to the severity indicator in the top right corner of the log detail tab

The Log AI system relies on resource attributes as defined in the OpenTelemetry semantic conventions to properly contextualize log messages. Without these attributes, severity inference may not work. For more details on what attributes can be used for contextualization, see the troubleshooting section below.

For Kubernetes Workloads:

Verify that the k8sattributesprocessor is correctly configured in your OpenTelemetry collector. This processor adds Kubernetes metadata to spans, metrics, and logs as resource attributes, which improves inference accuracy.
Reference: k8sattributesprocessor GitHub
Integration guide: OpenTelemetry Kubernetes Operator

For non-Kubernetes resources:

The Dash0 team is actively working to improve inference coverage for these scenarios.

Existing Severity Prioritization

When a log record already has a severity level specified via otel.log.severity.range, AI severity inference will not override this value. This ensures that explicitly defined severities are respected and maintained.

Troubleshooting

Log Contextualization with Resource Attributes

Dash0 applies a set of predefined rules to extract workload identifiers from resources, with the first matching rule to determine the context of a log message. This approach is similar to Dash0's resource equality determination.

Dash0 applies the following rules in order:

1. Vercel Deployments

For Vercel deployments, Dash0 extracts the vercel.project_id and, if available, the service.name.

2. Containers

For container resources, Dash0 uses the container.image.name

3. Kubernetes Resources

For Kubernetes workloads, Dash0 constructs an identifier using:

The Kubernetes namespace name (with simple numeric suffixes removed): k8s.namespace.name
The name of the Kubernetes resource (with numeric and random ID suffixes removed)
The container name, if available: k8s.container.name

The Kubernetes resource can be any of the following:

DaemonSet: k8s.daemonset.name
Deployment: k8s.deployment.name
StatefulSet: k8s.statefulset.name
ReplicaSet: k8s.replicaset.name
CronJob: k8s.cronjob.name
Job: k8s.job.name
Generic Kubernetes object: k8s.object.name
Pod: k8s.pod.name

To ensure consistent identification, Dash0 removes numeric or randomly generated string suffixes, often used in ephemeral resource names such as k8s pod name (e.g., catalogservice-6ddf6f4749-rd6m5 becomes catalogservice).

If none of the above rules match, Dash0 falls back to using the UID of a Kubernetes resource as the workload identifier.

DaemonSet: k8s.daemonset.uid
Deployment: k8s.deployment.uid
StatefulSet: k8s.statefulset.uid
ReplicaSet: k8s.replicaset.uid
CronJob: k8s.cronjob.uid
Job: k8s.job.uid
Generic Kubernetes object: k8s.object.uid
Pod: k8s.pod.uid

4. Host Resources

For host resources, Dash0 uses the os.type as the identifier, but only if none of the process-related attributes are present such as process.command or process.executable.name

5. Services

For service resources, Dash0 constructs an identifier using:

The service namespace (if available): service.namespace
The service name: service.name

AI Log Severity Inference