Intégrer les données OpenTelemetry grâce à Zerobus Ingest

Zerobus Ingest OTLP est un point de terminaison OTLP (OpenTelemetry Protocol) natif intégré au service Zerobus Ingest. Vous permet d’envoyer directement des traces, logs et métriques vers des tables Delta de Unity Catalog à l’aide des SDK et collecteurs OpenTelemetry standard, sans avoir besoin de bibliothèques personnalisées.

Pour configurer votre client OTLP pour envoyer des données à Zerobus Ingest, consultez Configurer des clients OpenTelemetry (OTLP) pour envoyer des données au catalogue Unity.

Azure Databricks facture l’ingestion OTLP en tant que consommation Zerobus Ingest. Pour les tarifs et la façon de surveiller vos dépenses, consultez Coût.

Les concepts

Les concepts suivants sont utiles pour comprendre le fonctionnement de Zerobus Ingest OTLP.

Compatibilité OTLP

Zerobus Ingest OTLP implémente les services standard OTLP Collector tels que définis par la spécification OpenTelemetry, à la fois sur gRPC et HTTP (Protobuf). Tout exportateur compatible OTLP, tel qu’un SDK OpenTelemetry, le collecteur OpenTelemetry ou une autre bibliothèque d’instrumentation, peut envoyer des données à ce point de terminaison.

Signaux pris en charge

L’OTLP Zerobus Ingest expose un service par type de signal de télémétrie. Chaque signal est disponible à la fois via OTLP/gRPC et OTLP/HTTP (Protobuf) :

Signal Chemin du service gRPC Chemin HTTP
Traces : étendues de trace distribuées avec prise en charge complète des événements, des liens et de l’état. /opentelemetry.proto.collector.trace.v1.TraceService/Export /v1/traces
Journaux : enregistrements de journal avec gravité, contenu et corrélation avec les traces via trace_id et span_id. /opentelemetry.proto.collector.logs.v1.LogsService/Export /v1/logs
Métriques : tous les cinq types de métriques OTLP : Jauge, Somme, Histogramme, ExponentielHistogramme et Résumé. /opentelemetry.proto.collector.metrics.v1.MetricsService/Export /v1/metrics

Réussite partielle

Zerobus Ingest OTLP prend en charge la réussite partielle telle que définie par la spécification OTLP. Si une demande contient un mélange d’enregistrements valides et non valides, les enregistrements valides sont ingérés et les enregistrements non valides sont rejetés. La réponse inclut le nombre d’enregistrements rejetés (rejected_spans, rejected_log_recordsou rejected_data_points) et une error_message description de la raison.

Compression

La compression gzip est prise en charge sur les trois services OTLP, à la fois sur gRPC et HTTP. Pour gRPC, réglez l’en-tête grpc-encoding sur gzip. Pour HTTP, on règle l’en-tête Content-Encoding sur gzip. Sinon, configurez votre exportateur OTLP pour utiliser la compression gzip.

Limites

  • Seul le codage Protobuf d’OTLP/HTTP est pris en charge. OTLP/HTTP avec un corps JSON n’est pas pris en charge, et les requêtes avec un Content-Type de application/json sont rejetées.
  • Chaque requête cible une table, spécifiée à l’aide de l’en-tête x-databricks-zerobus-table-name . Pour ingérer des traces, des logs et des métriques, configurez des exportateurs distincts qui pointent vers différentes tables.
  • Les tables doivent être créées à l’avance avec le schéma approprié. La fonctionnalité Zerobus Ingest ne crée ni ne modifie les tables.
  • Le quota par défaut est de 10 000 requêtes par seconde. Si vous avez besoin d’un quota plus élevé, contactez votre représentant Databricks.
  • Certains champs numériques OTLP peuvent perdre en précision ou déborder lorsqu’ils sont mappés aux types Delta. Voir Précision numérique et types signés.
  • Pour la liste complète des quotas d’ingestion de Zerobus, voir quotas d’ingestion de Zerobus.

Ressources supplémentaires

  • Last updated on