Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Zerobus Ingest OTLP is a native OpenTelemetry Protocol (OTLP) endpoint built into the Zerobus Ingest service. It lets you push traces, logs, and metrics directly into Unity Catalog Delta tables using standard OpenTelemetry SDKs and collectors, without needing custom libraries.
To configure your OTLP client to send data to Zerobus Ingest, see Configure OpenTelemetry (OTLP) clients to send data to Unity Catalog.
Azure Databricks bills OTLP ingestion as Zerobus Ingest usage. For pricing and how to monitor your spend, see Cost.
Concepts
The following concepts are useful for understanding how Zerobus Ingest OTLP works.
OTLP compatibility
Zerobus Ingest OTLP implements the standard OTLP Collector services as defined by the OpenTelemetry specification, over both gRPC and HTTP (Protobuf). Any OTLP-compatible exporter, such as an OpenTelemetry SDK, the OpenTelemetry Collector, or another instrumentation library, can send data to this endpoint.
Supported signals
Zerobus Ingest OTLP exposes one service per telemetry signal type. Each signal is available over both OTLP/gRPC and OTLP/HTTP (Protobuf):
| Signal | gRPC service path | HTTP path |
|---|---|---|
| Traces: Distributed trace spans with full support for events, links, and status. | /opentelemetry.proto.collector.trace.v1.TraceService/Export |
/v1/traces |
Logs: Log records with severity, body, and correlation to traces via trace_id and span_id. |
/opentelemetry.proto.collector.logs.v1.LogsService/Export |
/v1/logs |
| Metrics: All five OTLP metric types: Gauge, Sum, Histogram, ExponentialHistogram, and Summary. | /opentelemetry.proto.collector.metrics.v1.MetricsService/Export |
/v1/metrics |
Partial success
Zerobus Ingest OTLP supports partial success as defined by the OTLP specification. If a request contains a mix of valid and invalid records, the valid records are ingested and the invalid records are rejected. The response includes the count of rejected records (rejected_spans, rejected_log_records, or rejected_data_points) and an error_message describing why.
Compression
Gzip compression is supported on all three OTLP services, over both gRPC and HTTP. For gRPC, set the grpc-encoding header to gzip. For HTTP, set the Content-Encoding header to gzip. Alternatively, configure your OTLP exporter to use gzip compression.
Limitations
- Only the Protobuf encoding of OTLP/HTTP is supported. OTLP/HTTP with a JSON body is not supported, and requests with a
Content-Typeofapplication/jsonare rejected. - Each request targets one table, specified using the
x-databricks-zerobus-table-nameheader. To ingest traces, logs, and metrics, configure separate exporters pointing to different tables. - Tables must be created in advance with the correct schema. Zerobus Ingest does not create or modify tables.
- The default quota is 10,000 requests per second. If you require a higher quota, contact your Databricks representative.
- Some OTLP numeric fields can lose precision or overflow when mapped to Delta types. See Numeric precision and signed types.
- For a full list of Zerobus Ingest limitations, see Zerobus Ingest connector quotas.
Additional resources
- Configure OpenTelemetry (OTLP) clients to send data to Unity Catalog — Python examples and OpenTelemetry Collector configuration.
- OpenTelemetry table reference for Zerobus Ingest — Table schemas and data mapping reference.
- Query OpenTelemetry data — Example SQL queries for spans, logs, and metrics.
- Zerobus Ingest connector quotas