Observability
This page explains how observability works in DIAL: what the platform emits, how telemetry flows from components to your backends, and the two distinct observability planes you operate. It is for DevOps and platform engineers who want to understand the model before configuring tracing, metrics, logging, or analytics. No setup instructions are here — each how-to in this section covers one task.
OpenTelemetry as the common layer
DIAL standardizes on OpenTelemetry (OTEL), a vendor-agnostic specification for traces, metrics, and logs. Components export telemetry over the OTLP protocol to a collector, which forwards it to whatever backend you run. Because the wire format is standard, you choose the backend — Prometheus, Jaeger, Grafana, and similar tools all consume the same data without DIAL locking you to one vendor.
OTEL gives DIAL three signal types:
- Traces — the path of a request as it moves across components, with parent and child spans.
- Metrics — numeric time series such as request counts, latency, and JVM or system resource usage.
- Logs — structured event records, optionally correlated with traces.
Two observability planes
DIAL observability splits into two planes that you configure and operate independently. Keeping them separate is the key to reasoning about the platform.
Runtime health answers "is the platform healthy?" It is the OTEL plane: components emit traces, metrics, and logs over OTLP, and a collector forwards them to your chosen backend. Prometheus metrics travel a separate, independent path — components also expose a Prometheus-format /metrics endpoint that Prometheus scrapes directly, without going through the collector. Use it for latency, error rates, resource pressure, and request flow.
Usage analytics answers "how is the platform being used, and what does it cost?" It is a separate pipeline: DIAL Core's request logs reach blob storage through a log sink you configure, and DIAL Analytics ingests them into ClickHouse. It records token counts, cost, latency, and ratings per request, and serves them to DIAL Admin and to BI tools such as Grafana. The optional Enrichment Runner adds derived values, and DIAL Log Parser converts the same logs to Parquet for offline analysis.
The two planes share only one link: the OpenTelemetry trace_id and core_span_id that DIAL Analytics stores with each usage row, so a usage entry can be traced back to its request spans.
What each component emits
| Component | OTLP (traces, metrics, logs) | Prometheus metrics | How it is instrumented |
|---|---|---|---|
| DIAL Core | Yes (JVM and HTTP metrics, structured logs, and spans carrying trace_id, core_span_id, core_parent_span_id, and an execution_path call stack) | Yes | OpenTelemetry Java agent attached at the JVM level |
| DIAL Chat | Yes | Yes | OpenTelemetry Node.js SDK |
| DIAL Admin Frontend | Yes (traces and logs; metrics when configured for OTLP) | Yes, by default | OpenTelemetry Node.js SDK; see Admin telemetry settings |
| DIAL Deployment Manager Backend | Optional; export is off by default | Yes, /actuator/prometheus on port 9464 | Spring Boot OpenTelemetry integration; see Backend observability. Managed workload metrics use a separate API. |
| Adapters and Applications | Yes, including system CPU and memory metrics | Yes | DIAL SDK telemetry (Python) |
| DIAL Analytics | Optional; export is off by default | Yes, /actuator/prometheus on the API port, or on MANAGEMENT_SERVER_PORT when set | Spring Boot OpenTelemetry integration; see Security and observability |
| DIAL Analytics Enrichment Runner | Optional; export is off by default | Yes, /actuator/prometheus on the API port | Spring Boot OpenTelemetry integration; see Security and observability |
Other applications built on the DIAL SDK emit the same OTLP and Prometheus signals as any SDK-based adapter or application.
DIAL Admin's Analytics screens read the usage-analytics plane through DIAL Analytics, with optional enrichment processing. Configure their connection through DIAL Admin analytics settings.
DIAL Core is a Java service. It does not instrument itself in application code — its traces and metrics come from the OpenTelemetry Java agent attached to the JVM. The OTEL environment variables documented in this section configure that agent; how the agent jar is attached is set at the image or JVM level, not in config.json. Confirm the attachment mechanism against your own deployment.
Export to your chosen telemetry backend requires configuration on each component. Admin Frontend initializes its Node.js instrumentation and serves Prometheus metrics by default. The Vector log sidecar prints to standard output until you configure a sink. Each how-to describes what to connect.
For a Kubernetes example that connects both observability planes, follow Observability with Grafana and Prometheus.