Understand Log Events

In OpenTelemetry, a log event is a log record that has the event_name OTLP field set or carries, as fallback, the otel.event.name attribute.

Notable Types of Log Events in Dash0

• Deployment Events: Events named dash0.deployment, sent once per deployment to mark that a service version was deployed to an environment. Send them from CI/CD pipelines via the Dash0 CLI or GitHub Action, or from Terraform via the dash0_deployment_event action. See the Event Registry for the full catalog of Dash0-defined events.
• Service Events: Log events that also carry a service.name attribute, together with, optionally, a service.namespace attribute. These can overlap with Kubernetes Events and other log events.
• Kubernetes Events: The Dash0 Operator for Kubernetes (v0.92.1+) automatically collects Kubernetes events from monitored namespaces and ingests them as log events.

Sending Events

Any structured log record with an otel.event.name attribute is a log event

Via a Structured Logger

To emit a log event through a structured logger that you're already using, include otel.event.name as a field in the log record. An OTel log bridge will carry it through as an attribute, and Dash0 will recognize the record as a log event.

Using Pino with pino-opentelemetry-transport, as an example:

123456789101112
import pino from 'pino';

const logger = pino({
  transport: {
    target: 'pino-opentelemetry-transport',
  },
});

logger.info({
  'otel.event.name': 'user.login',
  'user.id': '42',
}, 'User logged in');

Via the OpenTelemetry Collector

Dash0 provides enhanced support for Kubernetes events collected via the k8seventsreceiver component of the OpenTelemetry Collector.

These events are automatically transformed upon ingestion to match via resource centricity with the rest of Kubernetes resources.

Kubernetes Events can be accessed via a specialised events view and are automatically collected by the Dash0 Operator v0.92.0 and above.

Users of the OpenTelemetry Operator and otel-collector-contrib can enable Kubernetes event collection with the following snippet:

12
receivers:
  k8s_events:

Via the Dash0 CLI and GitHub Action

You can also create log events directly from the Dash0 CLI or via the send-log-event GitHub action based on the CLI. This is the recommended way to emit deployment events from a CI/CD pipeline at release time.

The dash0 logs send command sends an OTLP log record, and setting --event-name turns it into a log event:

123456
dash0 logs send "Deployment completed" \
    --event-name dash0.deployment \
    --severity-number 9 \
    --resource-attribute service.name=checkout-api \
    --resource-attribute deployment.environment.name=production \
    --log-attribute deployment.status=succeeded

This requires an otlp-url and a static auth_-prefixed auth-token, either from the active CLI profile or passed as flags. As with the Terraform action below, the Dash0 OTLP/HTTP ingress endpoint does not accept OAuth access tokens.

Run the command once per deployment outcome, since one event carries one deployment.status: a started marker before the deployment, and a succeeded or failed marker after. Unlike the Terraform action, the CLI can emit that failed marker too, from a pipeline step that runs only on failure. See the command reference for the full list of flags, and the send-log-event GitHub action for the equivalent workflow step.

Via Terraform

The Dash0 Terraform provider offers the dash0_deployment_event action for sending deployment events as part of a Terraform run. Attach it to a resource with a lifecycle action_trigger block so it fires when Terraform creates or updates that resource, or invoke it on its own with terraform apply -invoke.

1234567891011121314151617181920
action "dash0_deployment_event" "release" {
  config {
    service_name                = "checkout-api"
    service_version             = var.image_tag
    deployment_environment_name = "production"
    deployment_status           = "succeeded"
    dataset                     = "production"
  }
}

resource "kubernetes_deployment" "checkout_api" {
  # ... deployment configuration ...

  lifecycle {
    action_trigger {
      events  = [after_create, after_update]
      actions = [action.dash0_deployment_event.release]
    }
  }
}

Work with Log Events

Log events in Dash0 are queryable, alertable, and visualizable using the same tools available for any log record. You can explore them in the dedicated Events View, build check rules to alert on event patterns, and overlay them as dashboard annotations to correlate spikes or anomalies with specific occurrences like deployments or restarts.

Query Events

In Dash0, events can be accessed like any other log record, and there is a specialised Events View.

Log events are a special form of log record. All analysis methods that work on logs in Dash0 also work for log events.

Create Check Rules based on Log Events

Since log events are a special form of log record, check rules on log events can be created using the same flow as for any other log record.

The fastest way to create a check rule from the Events view is to click Create check rule above the Severity Chart. This opens the check rule editor with the current event query pre-filled as the rule expression, letting you set up alerting on event patterns — such as spikes of a specific event type — without building the query from scratch.

See the Create Check Rules Manually documentation for full details.

Add Log Events as Dashboard Annotations

Annotations overlay log events onto the timelines of dashboard chart panels, visually correlating metric spikes or anomalies with specific events such as a deployment or a container restart.

See the Add Annotations documentation for more information on how to use log events as annotations.