Aller au contenu principal
Dernière mise à jour le

Exportation OpenTelemetry

info

Bêta

Cette fonctionnalité est en Bêta. Les administrateurs du Workspace peuvent contrôler l'accès à cette fonctionnalité à partir de la page Previews . Consultez Gérer les aperçus Databricks.

L'intégration OpenTelemetry envoie les **métriques** et les **logs** de Lakebase Postgres vers toute destination qui accepte les données en utilisant le protocole OpenTelemetry (OTLP). Vous pouvez utiliser Grafana Cloud, New Relic, l'ingestion OTLP Datadog, Honeycomb, ou un autre backend compatible OTLP.

Cette page décrit le fonctionnement de l'intégration dans les projets Lakebase Autoscaling, comment elle se rapporte à votre Workspace Databricks et à l'application Lakebase, et comment configurer et vérifier l'exportation.

Comment cela fonctionne​

Lakebase exécute un collecteur OpenTelemetry géré pour votre projet. Le collecteur collecte les métriques de compute, reçoit les logs de vos computes et les transmet à l' endpoint OTLP que vous configurez. Les données reflètent les Branch et les computes de votre projet : les métriques et les Logs sont associés aux computes actifs qui desservent vos Endpoint.

remarque

Si la Monter en charge to zero suspend un compute, celui-ci n'émet pas de métriques ou de Logs tant qu'il ne s'exécute pas à nouveau. Vous pouvez voir des lacunes pendant les périodes d'inactivité. Pour envoyer des données après la configuration, assurez-vous que les computes sont actifs — par exemple, en exécutant une query depuis l'éditeur SQL ou votre application.

Métriques​

Les métriques exportées incluent :

  • Métriques hôte / compute — Utilisation du processeur et de la mémoire pour le compute.
  • SQL et métriques de base de données — Nombre de connexions, taille de la base de données, délai de réplication, activité des lignes et statistiques de base de données associées. Ces noms de métriques sont exportés avec un préfixe lakebase_ (par exemple, lakebase_connection_counts).

Ensemble, ils correspondent à ce que vous voyez dans le tableau de bord des métriques dans le produit, exporté au format OTLP.

Noms des métriques exportées​

Le collecteur géré ne transmet que les métriques qui correspondent à ses règles de récupération et de filtrage. Les métriques **hôtes** conservent leurs noms d'origine de style Prometheus. Les métriques **PostgreSQL** ont un lakebase_ préfixe ** ** lors de l'exportation. Votre backend d'observabilité peut encore ajouter ou modifier des suffixes (par exemple _total) lorsqu'il convertit OTLP dans un autre format.

Catégorie

Noms inclus (tels qu'envoyés vers OTLP)

Hôte / compute

Séries dont les noms correspondent à host_load*, host_cpu_seconds* et host_memory* (expression régulière ^host_(load|cpu_seconds|memory).+). Quelques exemples : host_cpu_seconds_total (temps CPU par mode, par exemple idle vs non-idle), host_memory_total_bytes, host_memory_available_bytes, et host_memory_cached_bytes. Des séries correspondantes supplémentaires peuvent apparaître si le compute les expose.

Connexions

lakebase_connection_counts (les étiquettes incluent datname et la session state, par exemple active).

Taille et limites des bases de données

lakebase_db_total_size, lakebase_max_cluster_size et lakebase_pg_stats_userdb. La série lakebase_pg_stats_userdb utilise une étiquette kind pour la statistique (par exemple, la taille de la base de données, le nombre de lignes, les interblocages) — voir les mêmes dimensions que le tableau de bord des métriques intégré au produit.

Réplication

lakebase_replication_delay_bytes, lakebase_replication_delay_seconds, et toute autre série dont le nom d'origine correspondait à replication_delay_*.

Cache de fichiers local (LFC)

Chaque série dont le nom d'origine start par lakebase_lfc_*. Les exemples incluent lakebase_lfc_hits, lakebase_lfc_misses, lakebase_lfc_cache_size_limit et lakebase_lfc_approximate_working_set_size_windows.

Catégorie

Noms inclus (tels qu'envoyés vers OTLP)

Hôte / compute

Séries dont les noms correspondent à host_load*, host_cpu_seconds* et host_memory* (expression régulière ^host_(load|cpu_seconds|memory).+). Quelques exemples : host_cpu_seconds_total (temps CPU par mode, par exemple idle vs non-idle), host_memory_total_bytes, host_memory_available_bytes, et host_memory_cached_bytes. Des séries correspondantes supplémentaires peuvent apparaître si le compute les expose.

Connexions

lakebase_connection_counts (les étiquettes incluent datname et la session state, par exemple active).

Taille et limites des bases de données

lakebase_db_total_size, lakebase_max_cluster_size et lakebase_pg_stats_userdb. La série lakebase_pg_stats_userdb utilise une étiquette kind pour la statistique (par exemple, la taille de la base de données, le nombre de lignes, les interblocages) — voir les mêmes dimensions que le tableau de bord des métriques intégré au produit.

Réplication

lakebase_replication_delay_bytes, lakebase_replication_delay_seconds, et toute autre série dont le nom d'origine correspondait à replication_delay_*.

Cache de fichiers local (LFC)

Chaque série dont le nom d'origine start par lakebase_lfc_*. Les exemples incluent lakebase_lfc_hits, lakebase_lfc_misses, lakebase_lfc_cache_size_limit et lakebase_lfc_approximate_working_set_size_windows.

Logs​

Lorsqu’ils sont activés, les Logs (erreurs, avertissements, événements liés à la connexion et messages similaires) sont transférés vers votre pipeline de Logs OTLP. Votre attribut de ressource service.name configuré identifie le service logique pour les logs dans le backend.

Prérequis​

  • Un projet Lakebase et l'accès à l'application Lakebase depuis votre workspace Databricks. Voir Démarrer avec Lakebase Postgres.
  • Un backend d'observabilité compatible OTLP pris en charge et son **URL de base**, ainsi que les **informations d'identification** (clé API, jeton d'authentification ou authentification de base).
  • Chemin réseau depuis l'infrastructure gérée par Databricks vers votre endpoint OTLP (par exemple, un endpoint HTTPS public ou un collecteur accessible depuis votre cloud).

Ouvrir la configuration OpenTelemetry​

  1. Ouvrez l' application Lakebase pour votre workspace et sélectionnez votre projet.
  2. Accédez aux paramètres du projet, puis aux intégrations . L’intégration OpenTelemetry est disponible dans la section Intégrations .
  3. Sinon, depuis la page **Monitoring**, sélectionnez **Exporter la télémétrie** pour ouvrir les paramètres du projet où vous configurez OpenTelemetry.

Page des paramètres du projet Lakebase affichant la section Intégrations avec la carte d'intégration OpenTelemetry.

Configurez le protocole de connexion, l’endpoint, l’authentification, les substitutions de chemin facultatives et les attributs de ressource dans le formulaire.

Formulaire de configuration OpenTelemetry Lakebase affichant les champs du protocole, de l’endpoint, de l’authentification et des attributs de ressource.

Sélectionner les données à exporter​

Choisissez-en un ou les deux :

  • Métriques — Métriques d'hôte et SQL/base de données comme décrit ci-dessus.
  • Postgres Logs — Log Stream pour l'observabilité et le dépannage.

Configurez la connexion​

  1. Protocole — Pour la plupart des fournisseurs, HTTP (OTLP sur HTTP, généralement sur le port 4318) est recommandé. Utilisez gRPC (généralement le port 4317) si votre backend ou votre réseau l’exige.

  2. URL de l'Endpoint — Saisissez l' URL de base de votre Endpoint d'ingestion OTLP de collecteur ou de fournisseur sans ajouter /v1/metrics ou /v1/logs. Le collecteur ajoute les chemins OTLP standard :

    • /v1/metrics pour les métriques
    • /v1/logs pour les Logs

    Exemples :

    • Grafana Cloud : utilisez l'URL de la passerelle OTLP pour votre pile (souvent https://otlp-gateway-<region>.grafana.net/otlp). Consultez la documentation Grafana Cloud OpenTelemetry pour votre région.
    • **Datadog** : utilisez l'URL d'ingestion OTLP de votre site, comme décrit dans la configuration Datadog OpenTelemetry.
remarque

Si votre plateforme s'attend à des métriques ou des Logs sur des chemins non standards, utilisez les **substitutions d'Endpoint** facultatives dans le formulaire (par exemple, des chemins personnalisés pour les métriques ou les Logs). Ne définissez des remplacements que lorsque la documentation de votre fournisseur l'exige.

  1. Authentification

    • Porteur — Jeton porteur (certains fournisseurs utilisent une licence ou un jeton d'ingestion).
    • De base — Nom d'utilisateur et mot de passe.
    • Clé API — valeur de la clé API ; vous pouvez définir un nom d'en-tête personnalisé si votre backend attend autre chose que le default (certains fournisseurs utilisent des noms d'en-tête spécifiques au fournisseur).

Options avancées​

  • **Métriques Delta** — Certains backends s'attendent à une temporalité Delta au lieu de compteurs cumulatifs. Si votre plateforme l'exige, activez l'option de conversion des métriques cumulatives en temporalité delta.

Configurer les attributs des ressources​

Définissez service.name afin de pouvoir identifier ce projet Lakebase dans votre interface utilisateur d'observabilité. Les métriques sont organisées en Stream logiques tels que compute-host-metrics (métriques d'hôte) etsql-metrics(métriques de base de données), tandis que les Logs Postgres sont associés au nom de service que vous configurez.

Enregistrer et vérifier​

Enregistrez l'intégration. Dans quelques minutes, les données apparaissent dans votre backend.

Configuration spécifique au fournisseur​

Grafana Cloud​

Vous pouvez utiliser l'interface utilisateur de Grafana Cloud pour obtenir l'URL de l'**Endpoint** OTLP et les valeurs d'**authentification**, puis les saisir dans l'intégration OpenTelemetry de Lakebase, comme décrit dans Configurer la connexion.

Connexions (configuration guidée avec des tuiles de connexion)

  1. Connectez-vous au Portail Grafana Cloud.
  2. Dans Grafana, accédez à Connexions , ou développez le menu et choisissez Ajouter une nouvelle connexion .
  3. Recherchez OpenTelemetry (OTLP) . Suivez les étapes à l'écran : choisissez OpenTelemetry SDK , Autre comme langage et infrastructure, et OpenTelemetry Collector comme méthode.
  4. Sur la page Instructions d'instrumentation , créez ou choisissez un jeton à utiliser pour l'exportation Lakebase OpenTelemetry.
  5. Copiez les détails de la connexion fournis par Grafana (OTEL_EXPORTER_OTLP_ENDPOINT et OTEL_EXPORTER_OTLP_HEADERS).

Mapper les valeurs Grafana à Lakebase

  1. Protocole — Utilisez HTTP sauf si Grafana ou votre réseau exige gRPC. La passerelle OTLP de Grafana Cloud utilise couramment OTLP via HTTP.
  2. URL de l'Endpoint – Utilisez uniquement l'URL OTLP de base (la valeur indiquée pour OTEL_EXPORTER_OTLP_ENDPOINT ou l'URL de la passerelle sur la page OpenTelemetry). N'ajoutez pas /v1/metrics ou /v1/logs; Lakebase ajoute ces chemins. Les Hostnames suivent souvent https://otlp-gateway-<region>.grafana.net/otlp; utilisez l'URL exacte de votre pile car la région et le Hostname varient.
  3. Authentification — Utilisez la méthode documentée par Grafana pour votre token : De base si Grafana fournit un nom d'utilisateur et un mot de passe (par exemple, un ID d'instance et un token), Porteur pour un token porteur, ou API Key avec un nom d'en-tête personnalisé si Grafana spécifie un en-tête non default. Pour l’authentification Basic, Grafana peut fournir une valeur encodée en base64 que vous devez décoder avant de l’utiliser.

Pour les libellés d'interface utilisateur, les formats de jetons et les directives d'architecture actuels, veuillez consulter Envoyer des données à l'endpoint OTLP de Grafana Cloud dans la documentation Grafana Cloud.

remarque

La navigation Grafana Cloud et les noms des tuiles peuvent changer entre les versions. Si un contrôle est nommé différemment dans votre portail, utilisez la recherche intégrée au produit ou la documentation Grafana liée pour trouver l'OTLP endpoint et l' authentification pour votre pile.

Une fois les données dans Grafana Cloud, utilisez Explore et Loki pour vérifier que vous recevez les métriques et les Logs.

Datadog​

Vous pouvez envoyer les métriques et les logs Lakebase à Datadog à l'aide de son endpoint d'ingestion OTLP. Datadog fonctionne mieux avec la **temporalité Delta** pour les compteurs et les histogrammes. Activez l'option **métriques Delta** dans la configuration OpenTelemetry de Lakebase.

Trouvez votre Endpoint Datadog OTLP

L'URL de l'Endpoint OTLP dépend de votre site Datadog. Valeurs courantes :

Site Datadog

OTLP Endpoint (HTTP)

US1 (datadoghq.com)

https://otlp.datadoghq.com

US3 (us3.datadoghq.com)

https://otlp.us3.datadoghq.com

US5 (us5.datadoghq.com)

https://otlp.us5.datadoghq.com

UE1 (datadoghq.eu)

https://otlp.datadoghq.eu

AP1 (ap1.datadoghq.com)

https://otlp.ap1.datadoghq.com

Site Datadog

OTLP Endpoint (HTTP)

US1 (datadoghq.com)

https://otlp.datadoghq.com

US3 (us3.datadoghq.com)

https://otlp.us3.datadoghq.com

US5 (us5.datadoghq.com)

https://otlp.us5.datadoghq.com

UE1 (datadoghq.eu)

https://otlp.datadoghq.eu

AP1 (ap1.datadoghq.com)

https://otlp.ap1.datadoghq.com

Pour les autres sites Datadog, consultez Datadog OTLP ingest dans la documentation Datadog.

Mapper les valeurs Datadog à Lakebase

  1. Protocole — Utilisez HTTP (OTLP sur HTTP sur le port 4318). Datadog prend également en charge gRPC (port 4317) si cela est requis par votre configuration réseau.
  2. URL de l'Endpoint — Saisissez l'URL OTLP de base de votre site Datadog (voir tableau ci-dessus). N'ajoutez pas /v1/metrics ou /v1/logs; Lakebase ajoute automatiquement ces chemins.
  3. Authentification — Utilisez l'authentification par clé API . Saisissez votre clé API Datadog comme valeur et définissez le nom de l'en-tête sur DD-API-KEY.
  4. Delta metrics — Activez les Delta metrics sous Options avancées. Datadog s'attend à une temporalité delta pour les compteurs et les histogrammes. Sans ce paramètre, les compteurs cumulatifs peuvent produire des calculs de taux incorrects ou des comptes en double dans Datadog.

Une fois les données arrivées dans Datadog, utilisez **Metrics Explorer** pour rechercher les métriques lakebase_ et **Logs** pour vérifier que les Logs arrivent avec votre configuré.service.name

remarque

Datadog applique ses propres conventions de nommage lorsqu'il ingère des données OTLP. Par exemple, il peut ajouter .count ou .sum aux métriques d'histogramme, ou convertir les points en traits de soulignement. Voir Datadog OTLP metric mapping pour plus de détails sur la façon dont les noms de métriques sont transformés.

Dépannage​

  • Aucune donnée — Confirmez l'URL OTLP, le protocole et les identifiants. Confirmez que le compute n'est pas dimensionné à zéro. Exécutez une query de test pour activer le compute.
  • HTTP 404 lors de l'exportation — Signifie souvent que le backend n'accepte pas l'OTLP à {base}/v1/metrics {base}/v1/logsou. Confirmer les documents du fournisseur ou utiliser des remplacements de chemin si votre plateforme utilise des chemins non standard.
  • Erreurs de validation lors de l'enregistrement — Le produit peut tester l'accessibilité de l'endpoint OTLP. Si la validation échoue, vérifiez les exigences du pare-feu et de TLS, vérifiez les URL des régions et confirmez que le backend prend en charge OTLP HTTP ou gRPC tel que sélectionné.

Pour les métriques intégrées au produit sans exportation externe, consultez le tableau de bord des métriques. Pour les outils client uniquement qui se connectent via Postgres, consultez les outils de monitoring externes.

Étapes suivantes​

  • **Surveillez les projets Lakebase** : Suivez les performances, l'utilisation des ressources et l'analyse des query avec des outils intégrés et externes. Consultez Monitor.
  • Afficher les métriques : Vérifiez le processeur, la mémoire, les connexions et les statistiques de la base de données dans le tableau de bord des métriques intégré au produit. Consultez Tableau de bord des métriques.
  • Connectez les outils de monitoring externes : Surveillez votre base de données avec pgAdmin ou PgHero à l'aide de protocoles Postgres standards. Voir les outils de monitoring externes.
Sur cette page