AI Log Severity Inference

Dash0's Log AI feature brings advanced intelligence to log analysis by identifying and inferring log severity levels. This AI-driven capability improves the quality of log data by ensuring consistent and accurate severity classification across your entire application ecosystem.

How It Works

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

  1. Analyzes log message structure using language models and semantic heuristics
  2. Extracts severity-related text from the log message content
  3. Infers the appropriate severity level based on the extracted information
  4. 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:

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

Performance

To ensure the performance of the log severity extraction we evaluate every new release on a combination of public log datasets and our own logs.

Then, when ingesting logs, we constantly monitor how often model succeeds to identify a matching log format.

MetricDescriptionEvaluationAt ingestion time
Success RateHow often the log format is identified98%~90%
AccuracyWhen a log format is identified, how often the extracted severity is correct100%(no ground truth)

Current Limitations

Resource Attribute Dependency

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

The host.name attribute can also be used, as long as it is not too volitile (e.g.: an IP address or generic EC2 instance hostname).

5. Services

For service resources, Dash0 constructs an identifier using:

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

Last updated: June 2, 2025