Śledzenie i eksportowanie metryk kondycji punktu końcowego w usłudze Prometheus i Datadog
Ten artykuł zawiera omówienie obsługi metryk kondycji punktu końcowego i pokazuje, jak używać interfejsu API eksportu metryk do eksportowania metryk punktu końcowego do rozwiązania Prometheus i Datadog.
Metryki kondycji punktu końcowego mierzy infrastrukturę i metryki, takie jak opóźnienie, szybkość żądań, szybkość błędów, użycie procesora CPU, użycie pamięci itp. Informuje to, jak działa infrastruktura obsługująca.
Wymagania
Dostęp do odczytu do żądanego punktu końcowego i osobistego tokenu dostępu (PAT), który można wygenerować w obszarze Ustawienia w interfejsie użytkownika interfejsu użytkownika mozaiki usługi Databricks w celu uzyskania dostępu do punktu końcowego.
Istniejący model obsługujący punkt końcowy. Możesz to sprawdzić, sprawdzając kondycję punktu końcowego, wykonując następujące czynności:
curl -n -X GET -H "Authorization: Bearer [PAT]" https://[DATABRICKS_HOST]/api/2.0/serving-endpoints/[ENDPOINT_NAME]
Zweryfikuj interfejs API metryk eksportu:
curl -n -X GET -H "Authorization: Bearer [PAT]" https://[DATABRICKS_HOST]/api/2.0/serving-endpoints/[ENDPOINT_NAME]/metrics
Obsługa definicji metryk punktu końcowego
Metryczne | opis |
---|---|
Opóźnienie (ms) | Przechwytuje medianę (P50) i 99. percentyl (P99) czas opóźnienia rundy w usłudze Azure Databricks. Nie obejmuje to dodatkowych opóźnień związanych z usługą Databricks, takich jak uwierzytelnianie i ograniczanie szybkości |
Częstotliwość żądań (na sekundę) | Mierzy liczbę przetworzonych żądań na sekundę. Ta stawka jest obliczana przez łączną liczbę żądań w ciągu minuty, a następnie podzielenie przez 60 (liczbę sekund w ciągu minuty). |
Szybkość błędów żądania (na sekundę) | Śledzi szybkość odpowiedzi http 4xx i 5xx na sekundę. Podobnie jak częstotliwość żądań, jest obliczana przez agregowanie całkowitej liczby niepomyślnych żądań w ciągu minuty i podzielenie przez 60. |
Użycie procesora CPU (%) | Przedstawia średni procent wykorzystania procesora CPU we wszystkich replikach serwera. W kontekście infrastruktury usługi Databricks replika odwołuje się do węzłów maszyny wirtualnej. W zależności od skonfigurowanych ustawień współbieżności usługa Databricks tworzy wiele replik w celu efektywnego zarządzania ruchem modelu. |
Użycie pamięci (%) | Przedstawia średni procent wykorzystania pamięci we wszystkich replikach serwera. |
Aprowizowana współbieżność | Aprowizowana współbieżność to maksymalna liczba żądań równoległych, które system może obsłużyć. Aprowizowana współbieżność dynamicznie dostosowuje się w ramach minimalnych i maksymalnych limitów zakresu skalowania obliczeń w poziomie, różniąc się w odpowiedzi na ruch przychodzący. |
Użycie procesora GPU (%) | Reprezentuje średnie wykorzystanie procesora GPU zgłoszone przez eksportera NVIDIA DCGM . Jeśli typ wystąpienia ma wiele procesorów GPU, każdy jest śledzony oddzielnie (na przykład, gpu0 , , gpu1 ..., gpuN ). Wykorzystanie jest średnie we wszystkich replikach serwera i próbkowane raz na minutę.
Uwaga: Rzadkie próbkowanie oznacza, że ta metryka jest najdokładniejsza pod stałym obciążeniem.Wyświetl tę metrykę w interfejsie użytkownika służącym do obsługi na karcie Metryki punktu końcowego. |
Użycie pamięci procesora GPU (%) | Wskazuje średni procent wykorzystania pamięci buforu ramek na poszczególnych procesorach GPU na podstawie danych eksportera NVIDIA DCGM. Podobnie jak w przypadku użycia procesora GPU ta metryka jest średnią w replikach i próbkowana co minutę. Jest najbardziej niezawodny w spójnych warunkach obciążenia. Wyświetl tę metrykę w interfejsie użytkownika służącym do obsługi na karcie Metryki punktu końcowego. |
Integracja rozwiązania Prometheus
Uwaga
Niezależnie od typu wdrożenia w środowisku produkcyjnym konfiguracja złomowania powinna być podobna.
Wskazówki zawarte w tej sekcji są zgodne z dokumentacją rozwiązania Prometheus, aby uruchomić usługę Prometheus lokalnie przy użyciu platformy Docker.
Napisz plik konfiguracji i nadaj
yaml
muprometheus.yml
nazwę . Poniżej przedstawiono przykład:global: 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"]
Uruchom aplikację Prometheus lokalnie za pomocą następującego polecenia:
docker run \ -p 9090:9090 \ -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \ prom/prometheus
Przejdź do adresu ,
http://localhost:9090
aby sprawdzić, czy lokalna usługa Prometheus jest uruchomiona.Sprawdź stan narzędzia do złomowania Rozwiązania Prometheus i błędy debugowania z:
http://localhost:9090/targets?search=
Gdy element docelowy jest w pełni uruchomiony, możesz wykonać zapytanie dotyczące podanych metryk, takich jak
cpu_usage_percentage
lubmem_usage_percentage
, w interfejsie użytkownika.
Integracja usługi Datadog
Uwaga
Wstępna konfiguracja dla tego przykładu jest oparta na bezpłatnej wersji.
Usługa Datadog ma różnych agentów, które można wdrożyć w różnych środowiskach. W celach demonstracyjnych następujące uruchamia agenta systemu Mac OS lokalnie, który zeskropuje punkt końcowy metryk na hoście usługi Databricks. Konfiguracja używania innych agentów powinna mieć podobny wzorzec.
Zarejestruj konto usługi Datadog.
Zainstaluj integrację platformy OpenMetrics na pulpicie nawigacyjnym konta, aby usługa Datadog mogła akceptować i przetwarzać dane openmetrics.
Postępuj zgodnie z dokumentacją Datadog, aby agent Datadog działał. W tym przykładzie użyj opcji pakietu DMG, aby zainstalować wszystkie elementy, w tym
launchctl
idatadog-agent
.Znajdź konfigurację openmetrics. W tym przykładzie konfiguracja jest następująca:
~/.datadog-agent/conf.d/openmetrics.d/conf.yaml.default
. Poniżej przedstawiono przykładowy plik konfiguracjiyaml
.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
Uruchom agenta datadog przy użyciu polecenia
launchctl start com.datadoghq.agent
.Za każdym razem, gdy musisz wprowadzić zmiany w konfiguracji, musisz ponownie uruchomić agenta, aby pobrać zmianę.
launchctl stop com.datadoghq.agent launchctl start com.datadoghq.agent
Sprawdź kondycję agenta za pomocą polecenia
datadog-agent health
.Sprawdź stan agenta za pomocą polecenia
datadog-agent status
. Powinna być widoczna odpowiedź podobna do poniższej. Jeśli nie, debuguj przy użyciu komunikatu o błędzie. Potencjalne problemy mogą być spowodowane wygasłym tokenem pat lub nieprawidłowym adresem URL.openmetrics (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)
Stan agenta można również zobaczyć w interfejsie użytkownika o:http://127.0.0.1:5002/.
Jeśli agent jest w pełni uruchomiony, możesz wrócić do pulpitu nawigacyjnego usługi Datadog, aby wykonać zapytanie o metryki. Możesz również utworzyć monitor lub alert na podstawie danych metryk:https://app.datadoghq.com/monitors/create/metric