Monitorowanie rozproszonego akceleratora dla magazynu w chmurze (podgląd)

Rozproszony akcelerator do przechowywania w chmurze (DACS) udostępnia metryki formatu Prometheus z każdego serwera pamięci podręcznej. Używaj tych metryk do monitorowania połączeń, pojemności pamięci podręcznej, opóźnień i ilości żądań, rozmiarów żądań oraz obciążenia sieci systemu operacyjnego.

Punkt końcowy metryki

Zanim zaczniesz, zainstaluj DACS i poczekaj, aż pody cache-server będą gotowe. Zastąp <cache-namespace> w poleceniach i konfiguracji przestrzenią nazw, która zawiera te pody.

Każdy moduł serwera pamięci podręcznej udostępnia metryki na porcie 9096 na ścieżce /metrics . Pobieraj metryki z każdego poda serwera pamięci podręcznej, aby system monitoringu rejestrował stan i liczniki dla każdego serwera.

Wypisz pody cache-server i potwierdź port metryk:

kubectl get pods \
  --namespace <cache-namespace> \
  --selector app=cacheserver \
  --output wide

kubectl get pods \
  --namespace <cache-namespace> \
  --selector app=cacheserver \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .spec.containers[*].ports[*]}{.containerPort}{" "}{end}{"\n"}{end}'

Zweryfikuj lokalnie jeden punkt końcowy:

CACHE_POD=$(kubectl get pods \
  --namespace <cache-namespace> \
  --selector app=cacheserver \
  -o jsonpath='{.items[0].metadata.name}')

kubectl port-forward \
  --namespace <cache-namespace> \
  pod/$CACHE_POD \
  9096:9096

W innym terminalu pobierz metryki:

curl --fail --silent --show-error http://localhost:9096/metrics

Zatrzymaj polecenie przekierowania portów, gdy skończysz sprawdzać endpoint.

Skonfiguruj swój pipeline metryk

Skonfiguruj swój kolektor kompatybilny z Prometheus, aby wykrywał pody serwera pamięci podręcznej w przestrzeni nazw DACS i scrapował port 9096 pod adresem /metrics. Kolekcjoner potrzebuje dostępu sieciowego do adresów IP podu na porcie 9096 oraz uwierzytelnionego dostępu do API Kubernetes. Nadaj jej uprawnienia get, list oraz watch dla podów w przestrzeni nazw DACS. Dla kolektora wewnątrzklastrowego przypisz rolę z tymi uprawnieniami do jej konta usługi.

Poniższa konfiguracja Prometheus jest przykładem kolektora wewnątrzklastrowego. Ogranicza to odkrywanie Kubernetes do przestrzeni nazw DACS. Zamień <cache-namespace> na swoją przestrzeń nazw.

scrape_configs:
  - job_name: dacs-cache-server
    scrape_interval: 30s
    metrics_path: /metrics
    kubernetes_sd_configs:
      - role: pod
        namespaces:
          names:
            - <cache-namespace>
    relabel_configs:
      - source_labels: [__meta_kubernetes_namespace]
        action: keep
        regex: <cache-namespace>
      - source_labels: [__meta_kubernetes_pod_label_app]
        action: keep
        regex: cacheserver
      - source_labels: [__meta_kubernetes_pod_phase]
        action: keep
        regex: Running
      - source_labels: [__meta_kubernetes_pod_container_port_number]
        action: keep
        regex: "9096"
      - source_labels: [__meta_kubernetes_pod_name]
        target_label: pod
      - source_labels: [__meta_kubernetes_namespace]
        target_label: namespace

Jeśli Twój potok korzysta z operatora Prometheus, stwórz PodMonitor lub równoważny zasób, który wybiera app=cacheserver, przestrzeń nazw DACS oraz port metryk. Użyj etykiet i nazw portów z zainstalowanej wersji podglądowej.

Po skonfigurowaniu scrapingu sprawdź, czy twój system metryk ma jeden aktywny cel dla każdego poda serwera cache. Zachowaj etykiety pod, instance i namespace, aby móc zidentyfikować pojedynczy serwer pamięci podręcznej w złym stanie lub przeciążony.

Referencja metryk

Serwer cache udostępnia następujące rodziny metryk:

Rodziny metryk histogramowych udostępniają standardowe szeregi czasowe _bucket, _sum oraz _count. Wartości liczników resetują się po ponownym uruchomieniu procesu serwera pamięci podręcznej. Używaj rate() lub increase() zamiast porównywać surowe wartości liczników w różnych restartach.

Użyj nazw metryk udostępnianych przez zainstalowaną kompilację preview, w tym cache_server_request_counter oraz jednostkę opóźnienia _ms. Narzędzia lintujące konwencje nazewnictwa Prometheusa mogą ostrzegać przed tymi nazwami, mimo że Prometheus może je zbierać i odpytywać.

Przykładowe zapytania PromQL

Poniższe przykłady zakładają, że Twój pipeline metryk zachowuje etykiety namespace i pod. W przypadku przestrzeni roboczej ze współdzielonymi metrykami dołącz także unikalną etykietę cluster do próbek każdego klastra. Agregacje zachowują wszystkie trzy etykiety, dzięki czemu kapsuły o identycznej nazwie nie są łączone między przestrzeniami nazw czy klastrami. Jeśli Twój kolekcjoner używa innej etykiety klastra, zastąp ją tą nazwą. Bez etykiety klastra używaj źródła danych ograniczonego do jednego klastra.

Pozwól na co najmniej dwa skanowania przed oceną rate() lub increase(). Na bezczynnym serwerze kwantyl opóźnienia i średni rozmiar żądania mogą zwrócić NaN, ponieważ w oknie zapytań nie zaobserwowano żadnych żądań. Sam ten stan nie wskazuje na niepowodzenie scrapowania. Sprawdź metrykę up elementu docelowego osobno.

Aktywne połączenia według serwera pamięci podręcznej

cache_server_active_connections

Częstotliwość żądań według serwera cache

sum by (cluster, namespace, pod) (rate(cache_server_request_counter[5m]))

W wydaniu 0.1.0, cache_server_request_counter zawiera request_type i status etykiety. Uwzględnij te etykiety w agregacji, aby podzielić przesyłania, pobrania i niepowodzenia. Sprawdź etykiety udostępniane przez zainstalowaną wersję.

Udane pobrania przez pamięć podręczną

Aby sprawdzić aktywność pobierania z serwera pamięci podręcznej podczas powtarzających się odczytów, przefiltruj udane żądania pobierania i agreguj spośród wszystkich podów serwera należących do wybranego zasobu pamięci podręcznej:

sum by (cluster, namespace) (
  increase(cache_server_request_counter{
    cluster="<cluster>",
    namespace="<cache-namespace>",
    pod=~"<cache-server-pod-regex>",
    request_type="Download",
    status="Success"
  }[5m])
)

Zastąp symbole zastępcze klastra, przestrzeni nazw i wyrażenia regularnego poda. Dopasuj tylko pody serwera należące do zasobu pamięci podręcznej, a nie do innych pamięci podręcznych we współdzielonej przestrzeni nazw. W przypadku źródła danych z pojedynczym klastrem bez etykiety cluster należy pominąć ten selektor. Wartości etykiet Download i Success są zależne od wielkości liter.

Wykonaj pomiar bazowy przed odczytami i wykonaj co najmniej dwa zeskrobania. increase() szacuje aktywność w całym oknie czasowym i uwzględnia resety liczników; nie jest to dokładna różnica wartości surowych liczników. Brak serii nie jest dowodem na brak aktywności. Sprawdź stan pobierania metryk i udostępniane etykiety przed interpretacją wyniku.

Skoreluj wzrost z metrykami dotyczącymi trafienia w cache klienta i izoluj ruch niepowiązany podczas walidacji. Ten licznik nie jest współczynnikiem trafień pamięci podręcznej, a sam skuteczny lub szybszy odczyt aplikacji nie dowodzi użycia pamięci podręcznej. Wypełnianie danych jest asynchroniczne, więc natychmiastowe, powtarzające się odczyty mogą nadal nie zwracać wyników. Zobacz Zweryfikuj ścieżkę żądania DACS.

Opóźnienie pomyślnych żądań (P95) (milisekundy)

histogram_quantile(
  0.95,
  sum by (le, cluster, namespace, pod) (
    rate(cache_server_successful_request_latency_ms_bucket[5m])
  )
)

Średni rozmiar żądania pobrania

sum by (cluster, namespace, pod) (rate(cache_server_download_request_size_bytes_sum[5m]))
/
sum by (cluster, namespace, pod) (rate(cache_server_download_request_size_bytes_count[5m]))

Przepełnienia kolejki

sum by (cluster, namespace, pod) (increase(cache_server_accept_queue_overflows_total[5m]))

Porzucenia w kolejce SYN i podczas nasłuchiwania

sum by (cluster, namespace, pod) (
  increase(cache_server_listen_drops_total[5m])
  + increase(cache_server_syn_queue_full_drops_total[5m])
)

Zalecane powiadomienia

Twórz alerty odzwierciedlające bazowy poziom obciążenia i rozmiar VM serwera pamięci podręcznej. Rozważ co najmniej alerty dla:

• Obiekt docelowy skanowania DACS jest niedostępny lub go brakuje.
• Utrzymujące się dodatnie wzrosty w cache_server_accept_queue_overflows_total.
• Trwałe niezerowe wzrosty wartości cache_server_listen_drops_total lub cache_server_syn_queue_full_drops_total.
• Wzrosty pogrupowane według errno.
• Opóźnienie pomyślnych żądań na poziomie P95 lub P99 powyżej celu dla obciążenia.
• Aktywne połączenia zbliżające się do przetestowanej pojemności rozmiaru maszyny wirtualnej serwera pamięci podręcznej.
• Nieoczekiwane zmiany rozmiaru lub nierównowaga pamięci podręcznej między podami serwera pamięci podręcznej.
• Nietypowo wysoka liczba ogólnosystemowo przydzielonych deskryptorów plików. Pamiętaj, że cache_server_open_fds nie jest liczbą opisów plików na proces.

Ustal punkt odniesienia dla oczekiwanej równoległości przed ustaleniem stałych progów. Skoreluj metryki obciążenia sieci z częstotliwością żądań, rozmiarem żądania, opóźnieniami, użyciem procesora węzła, pamięcią węzła oraz metrykami żądań i bajtów usługi Azure Blob.

Następne kroki

• Zarządzanie rozproszonym akceleratorem dla pamięci masowej w chmurze.
• Rozwiązywanie problemów z rozproszonym akceleratorem do przechowywania w chmurze.