Ingest OpenTelemetry data with Zerobus Ingest
Zerobus Ingest OTLP est un endpoint natif OpenTelemetry Protocol (OTLP) intégré au service Zerobus Ingest. Il vous permet de pousser les traces, les logs et les métriques directement dans les tables Delta Unity Catalog en utilisant les SDK et collecteurs OpenTelemetry standards, sans avoir besoin de bibliothèques personnalisées.
Pour configurer votre client OTLP afin d'envoyer des données à Zerobus Ingest, consultez Configurer les clients OpenTelemetry (OTLP) pour envoyer des données à Unity Catalog.
Databricks facture l’ingestion OTLP en tant qu’utilisation de Zerobus Ingest. Pour connaître les tarifs et savoir comment surveiller vos dépenses, consultez Coût.
Concepts
Les concepts suivants sont utiles pour comprendre comment fonctionne Zerobus Ingest OTLP.
Compatibilité OTLP
Zerobus Ingest OTLP implémente les services standard OTLP Collector tels que définis par la spécification OpenTelemetry, via gRPC et HTTP (Protobuf). Tout exportateur compatible OTLP, tel qu'un SDK OpenTelemetry, l'OpenTelemetry Collector ou une autre bibliothèque d'instrumentation, peut envoyer des données vers cet endpoint.
Signaux pris en charge
Zerobus Ingest OTLP expose un service par type de signal de télémétrie. Chaque signal est disponible via OTLP/gRPC et OTLP/HTTP (Protobuf) :
Signal | chemin de service gRPC | Chemin HTTP |
|---|---|---|
Traces : Portées de trace distribuées avec prise en charge complète des événements, des Link et du statut. |
|
|
**Logs** : Enregistrez les logs avec la gravité, le corps et la corrélation aux traces via |
|
|
Métriques : Les cinq types de métriques OTLP : Gauge, Sum, Histogram, ExponentialHistogram et Summary. |
|
|
Succès partiel
Zerobus Ingest OTLP prend en charge la réussite partielle telle que définie par la spécification OTLP. Si une requête 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_records ou rejected_data_points) et un error_message décrivant la raison.
Compression
La compression gzip est prise en charge sur les trois services OTLP, via gRPC et HTTP. Pour gRPC, définissez l’en-tête grpc-encoding sur gzip. Pour HTTP, définissez l’en-tête Content-Encoding sur gzip. Alternativement, configurez votre exportateur OTLP pour utiliser la compression gzip.
Limitations
- Seul l'encodage 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-Typedeapplication/jsonsont 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 les traces, les logs et les métriques, configurez des exportateurs séparés pointant vers différentes tables. - Les tables doivent être créées à l'avance avec le bon schéma. Zerobus Ingest ne crée ni ne modifie de tables.
- Le quota default est de 10 000 requêtes par seconde. Si vous avez besoin d'un quota plus élevé, veuillez contacter votre représentant Databricks.
- Certains champs numériques OTLP peuvent perdre en précision ou déborder lorsqu’ils sont mappés vers des types Delta. Voir Précision numérique et types signés.
- Pour une liste complète des limitations de Zerobus Ingest, voir Quotas du connecteur Zerobus Ingest.
Ressources supplémentaires
- Configurer les clients OpenTelemetry (OTLP) pour envoyer des données à Unity Catalog — exemples Python et configuration d'OpenTelemetry Collector.
- Référence de table OpenTelemetry pour Zerobus Ingest : Référence des schémas de table et du mappage des données.
- Requête des données OpenTelemetry — Exemples de requêtes SQL pour les portées, les logs et les métriques.
- Quotas du connecteur Zerobus Ingest