Ingerir dados OpenTelemetry com Zerobus Ingest

O Zerobus Ingest OTLP é um endpoint nativo do Protocolo OpenTelemetry (OTLP) integrado no serviço Zerobus Ingest . Permite-lhe enviar traces, logs e métricas diretamente para as tabelas Delta do Unity Catalog usando SDKs e colecionadores padrão do OpenTelemetry, sem necessidade de bibliotecas personalizadas.

Para configurar o seu cliente OTLP para enviar dados para o Zerobus Ingest, consulte Configurar clientes OpenTelemetry (OTLP) para enviar dados para o Catálogo Unity.

Azure Databricks fatura a ingestão OTLP como Zerobus Ingest usage. Para preços e como monitorizar os seus gastos, consulte Custo.

Conceitos

Os seguintes conceitos são úteis para compreender como funciona o OTLP do Zerobus Ingest.

Compatibilidade OTLP

O Zerobus Ingest OTLP implementa os serviços padrão do OTLP Collector, conforme definidos pela especificação OpenTelemetry, através de gRPC e de HTTP (Protobuf). Qualquer exportador compatível com OTLP, como um SDK OpenTelemetry, o OpenTelemetry Collector ou outra biblioteca de instrumentação, pode enviar dados para este endpoint.

Sinais suportados

Zerobus Ingest OTLP expõe um serviço por tipo de sinal de telemetria. Cada sinal está disponível tanto em OTLP/gRPC como em OTLP/HTTP (Protobuf):

Sinal Caminho de serviço gRPC Caminho HTTP
Traces: Segmentos de traços distribuídos com suporte total para eventos, links e estado. /opentelemetry.proto.collector.trace.v1.TraceService/Export /v1/traces
Registos: Registos com gravidade, conteúdo e correlação com rastreios via trace_id e span_id. /opentelemetry.proto.collector.logs.v1.LogsService/Export /v1/logs
Métricas: Todos os cinco tipos de métricas OTLP: Gauge, Sum, Histogram, ExponentialHistogram e Summary. /opentelemetry.proto.collector.metrics.v1.MetricsService/Export /v1/metrics

Sucesso parcial

O Zerobus Ingest OTLP suporta sucesso parcial conforme definido pela especificação OTLP. Se um pedido contiver uma mistura de registos válidos e inválidos, os registos válidos são ingeridos e os registos inválidos são rejeitados. A resposta inclui a contagem de registos rejeitados (rejected_spans, rejected_log_records, ou rejected_data_points) e uma descrição error_message do motivo.

Compressão

A compressão gzip é suportada nos três serviços OTLP, tanto em gRPC como em HTTP. Para gRPC, defina o grpc-encoding cabeçalho para gzip. Para HTTP, defina o Content-Encoding cabeçalho para gzip. Alternativamente, configura o teu exportador OTLP para usar compressão gzip.

Limitações

  • Apenas a codificação Protobuf do OTLP/HTTP é suportada. O OTLP/HTTP com corpo JSON não é suportado, e os pedidos com um Content-Type de application/json são rejeitados.
  • Cada pedido tem como alvo uma tabela, especificada usando o x-databricks-zerobus-table-name cabeçalho. Para ingerir traços, registos e métricas, configure exportadores separados apontando para tabelas diferentes.
  • As tabelas devem ser criadas antecipadamente com o esquema correto. O Zerobus Ingest não cria nem modifica tabelas.
  • A quota padrão é de 10.000 pedidos por segundo. Se precisar de uma quota mais elevada, contacte o seu representante Databricks.
  • Alguns campos numéricos OTLP podem perder precisão ou transbordar quando mapeados para tipos Delta. Veja Precisão numérica e tipos com sinal.
  • Para a lista completa das quotas de ingestão do Zerobus, consulte quotas de ingestão do Zerobus.

Recursos adicionais