Suivre et exporter les métriques de santé des Endpoint de mise en service vers Prometheus et Datadog
Cet article fournit un aperçu des mesures de santé des Endpoint de service et montre comment utiliser l'API d'exportation des mesures pour exporter les mesures des Endpoint vers Prometheus et Datadog.
Les métriques de santé des Endpoint mesurent l'infrastructure et des métriques telles que la latence, le taux de requêtes, le taux d'erreur, l'utilisation du CPU, l'utilisation de la mémoire, etc. Ceci vous indique comment votre infrastructure de service se comporte.
Exigences
-
Accès en lecture à l'Endpoint souhaité et un jeton d'accès personnel (PAT) qui peut être généré dans les **paramètres** de l'interface utilisateur Databricks pour accéder à l'Endpoint.
-
Un endpoint de service de modèle existant. Vous pouvez valider cela en vérifiant l'état de l'endpoint avec ce qui suit :
Bashcurl -n -X GET -H "Authorization: Bearer [PAT]" https://[DATABRICKS_HOST]/api/2.0/serving-endpoints/[ENDPOINT_NAME] -
Validez l'API d'exportation des métriques :
Bashcurl -n -X GET -H "Authorization: Bearer [PAT]" https://[DATABRICKS_HOST]/api/2.0/serving-endpoints/[ENDPOINT_NAME]/metrics
Définitions des métriques d'Endpoint de service
Métriques | Description |
|---|---|
Latence (ms) | Capture les temps de latence aller-retour médians (P50) et au 99e centile (P99) au sein de Databricks. Cela n'inclut pas les latences supplémentaires liées à Databricks, comme l'authentification et la limitation du débit. |
Taux de demandes (par seconde) | Mesure le nombre de requêtes traitées par seconde. Ce taux est calculé en totalisant le nombre de requêtes en une minute, puis en le divisant par 60 (le nombre de secondes dans une minute). |
Taux d'erreur de requête (par seconde) | Suit le taux de réponses d'erreur HTTP 4xx et 5xx par seconde. Semblable au taux de requête, il est calculé en agrégeant le nombre total de requêtes infructueuses en une minute et en divisant par 60. |
Utilisation du CPU (%) | Affiche le pourcentage d'utilisation moyenne du CPU pour tous les réplicas de serveurs. Dans le contexte de l'infrastructure Databricks, une réplique fait référence aux nœuds de machines virtuelles. En fonction de vos paramètres de concurrence configurés, Databricks crée plusieurs réplicas pour gérer efficacement le trafic du modèle. |
Utilisation de la mémoire (%) | Affiche le pourcentage moyen d'utilisation de la mémoire sur tous les réplicas de serveur. |
Simultanéité provisionnée | La concurrence provisionnée est le nombre maximal de requêtes parallèles que le système peut gérer. La simultanéité provisionnée s'adapte dynamiquement dans les limites minimales et maximales de la plage de montée en charge du compute, variant en fonction du trafic entrant. |
Utilisation du GPU (%) | Représente l'utilisation moyenne du GPU, telle que rapportée par l'exportateur NVIDIA DCGM. Si le type d'instance a plusieurs GPU, chacun est suivi séparément (par exemple, |
Utilisation de la mémoire GPU (%) | Indique le pourcentage moyen de mémoire de tampon d'images utilisée sur chaque GPU, basé sur les données de l'exportateur NVIDIA DCGM. Comme pour l'utilisation du GPU, cette métrique est moyennée sur les répliques et échantillonnée chaque minute. Il est le plus fiable dans des conditions de charge constantes. Consultez cette métrique dans l'interface utilisateur de service, dans la tab Metrics de votre Endpoint de service. |
Intégration de Prometheus
Quel que soit le type de déploiement que vous avez dans votre environnement de production, la configuration du scraping doit être similaire.
Les conseils de cette section suivent la documentation Prometheus pour start un service Prometheus localement à l'aide de Docker.
-
Rédigez un fichier de configuration
yamlet nommez-leprometheus.yml. Voici un exemple :YAMLglobal:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: 'prometheus'
metrics_path: '/api/2.0/serving-endpoints/[ENDPOINT_NAME]/metrics'
scheme: 'https'
authorization:
type: 'Bearer'
credentials: '[PAT_TOKEN]'
static_configs:
- targets: ['dbc-741cfa95-12d1.dev.databricks.com'] -
Start Prometheus localement avec la commande suivante :
Bashdocker run \
-p 9090:9090 \
-v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus -
Accédez à
http://localhost:9090pour vérifier si votre service Prometheus local est opérationnel. -
Vérifier l'état du scraper Prometheus et déboguer les erreurs depuis :
http://localhost:9090/targets?search= -
Une fois que la cible est entièrement opérationnelle, vous pouvez interroger les métriques fournies, comme
cpu_usage_percentageoumem_usage_percentage, dans l'UI.
Intégration Datadog
Datadog dispose de divers agents qui peuvent être déployés dans différents environnements.
À des fins de démonstration, ce qui suit lance un agent Mac OS localement qui scrape l'endpoint des métriques de votre hôte Databricks. La configuration pour l'utilisation d'autres agents suit un modèle similaire.
La configuration préliminaire pour cet exemple est basée sur la Free Edition.
Datadog propose également une intégration Databricks qui connecte Datadog à vos endpoints de service de modèle pour surveiller les métriques d'endpoint sans code. Consultez la documentation Datadog pour savoir comment connecter votre configuration de service de modèle à Datadog.
-
Enregistrez un compte Datadog.
-
Installez l’intégration OpenMetrics dans votre tableau de bord du compte, afin que Datadog puisse accepter et traiter les données OpenMetrics.
-
Suivez la documentation Datadog pour que votre agent Datadog soit opérationnel. Pour cet exemple, utilisez l'option package DMG pour que tout soit installé, y compris
launchctletdatadog-agent. -
Repérez votre configuration OpenMetrics. Pour cet exemple, la configuration se trouve à
~/.datadog-agent/conf.d/openmetrics.d/conf.yaml.default. Le fichier de configurationyamlsuivant est un exemple.YAML
instances:
- openmetrics_endpoint: https://[DATABRICKS_HOST]/api/2.0/serving-endpoints/[ENDPOINT_NAME]/metrics
metrics:
- cpu_usage_percentage:
name: cpu_usage_percentage
type: gauge
- mem_usage_percentage:
name: mem_usage_percentage
type: gauge
- provisioned_concurrent_requests_total:
name: provisioned_concurrent_requests_total
type: gauge
- request_4xx_count_total:
name: request_4xx_count_total
type: gauge
- request_5xx_count_total:
name: request_5xx_count_total
type: gauge
- request_count_total:
name: request_count_total
type: gauge
- request_latency_ms:
name: request_latency_ms
type: histogram
tag_by_endpoint: false
send_distribution_buckets: true
headers:
Authorization: Bearer [PAT]
Content-Type: application/openmetrics-text -
Start l'agent Datadog à l'aide de
launchctl start com.datadoghq.agent. -
Chaque fois que vous devez apporter des modifications à votre configuration, vous devez redémarrer l'agent pour qu'elles soient prises en compte.
Bashlaunchctl stop com.datadoghq.agent
launchctl start com.datadoghq.agent -
Vérifiez l'état de l'agent avec
datadog-agent health. -
Vérifiez l'état de l'agent avec
datadog-agent status. Vous devriez voir une réponse similaire à ce qui suit. Sinon, déboguez avec le message d'erreur. Des problèmes potentiels peuvent être dus à un jeton PAT expiré ou à une URL incorrecte.Bashopenmetrics (2.2.2)
-------------------
Instance ID: openmetrics: xxxxxxxxxxxxxxxx [OK]
Configuration Source: file:/opt/datadog-agent/etc/conf.d/openmetrics.d/conf.yaml.default
Total Runs: 1
Metric Samples: Last Run: 2, Total: 2
Events: Last Run: 0, Total: 0
Service Checks: Last Run: 1, Total: 1
Average Execution Time : 274ms
Last Execution Date : 2022-09-21 23:00:41 PDT / 2022-09-22 06:00:41 UTC (xxxxxxxx)
Last Successful Execution Date : 2022-09-21 23:00:41 PDT / 2022-09-22 06:00:41 UTC (xxxxxxx) -
Le statut de l'agent peut également être consulté à partir de l'interface utilisateur à l'adresse :http://127.0.0.1:5002/.
Si votre agent est entièrement opérationnel, vous pouvez revenir à votre tableau de bord Datadog pour interroger les métriques. Vous pouvez également créer une surveillance ou une alerte basée sur les données de métriques :https://app.datadoghq.com/monitors/create/metric.