Verteilten Beschleuniger für Cloudspeicher überwachen (Vorschau)

Der verteilte Beschleuniger für Cloudspeicher (DACS) stellt von jedem Cache-Server Metriken im Prometheus-Format bereit. Verwenden Sie diese Metriken, um Verbindungen, Cache-Kapazität, Anforderungslatenz und -volumen, Anforderungsgrößen sowie die Netzwerkauslastung auf Betriebssystemebene zu überwachen.

Metrikendpunkt

Bevor du anfängst, installiere DACS und warte, bis die Cache-Server-Pods bereit sind. Ersetze <cache-namespace> in den Befehlen und der Konfiguration durch den Namensraum, der diese Pods enthält.

Jeder Cache-Server-Pod stellt Metriken über Port 9096 unter dem Pfad /metrics bereit. Scrapen Sie jeden Cache-Server-Pod, damit Ihr Überwachungssystem den Zustand und die Zählwerte jedes einzelnen Servers erfasst.

Führen Sie die Cache-Server-Pods auf und bestätigen Sie den Metrik-Port:

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}'

Überprüfen Sie einen Endpunkt lokal:

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

Rufen Sie in einem anderen Terminal die Metriken ab:

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

Beenden Sie den Befehl zur Portweiterleitung, sobald Sie die Überprüfung des Endpunkts abgeschlossen haben.

Konfigurieren Sie Ihre Metrik-Pipeline

Konfigurieren Sie Ihren Prometheus-kompatiblen Collector so, dass er Cache-Server-Pods im DACS-Namensraum erkennt und Port 9096 unter /metrics abruft. Der Sammler benötigt Netzwerkzugriff auf die IP-Adressen des Pods über Port 9096 sowie authentifizierten Zugriff auf die Kubernetes-API. Gewähren Sie seiner Identität get, list und watch Berechtigungen für Pods im DACS-Namensraum. Für einen In-Cluster-Sammler binden Sie eine Rolle mit diesen Berechtigungen an sein Dienstkonto.

Die folgende Prometheus-Konfiguration ist ein Beispiel für einen im Cluster ausgeführten Collector. Es beschränkt die Kubernetes-Entdeckung auf den DACS-Namensraum. Ersetzen Sie <cache-namespace> durch Ihren Namensraum.

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

Wenn Ihre Pipeline einen Prometheus-Operator verwendet, erstellen Sie eine PodMonitor oder eine äquivalente Ressource, die app=cacheserver, den DACS-Namensraum und den Metrics-Port auswählt. Verwenden Sie die Labels und Portnamen aus Ihrer installierten Vorschauversion.

Nach der Konfiguration des Scrapings überprüfen Sie, ob Ihr Metriksystem für jeden Cache-Server-Pod ein aktives Ziel hat. Bewahren Sie die instance, namespace und pod Labels auf, damit Sie einen einzelnen ungesunden oder gesättigten Cache-Server identifizieren können.

Metrikenreferenz

Ein Cache-Server stellt folgende Metrikfamilien zur Verfügung:

Histogrammmetrikfamilien stellen die Standardzeitreihen _bucket, _sum und _count bereit. Zählerwerte werden zurückgesetzt, wenn ein Cache-Server-Prozess neu gestartet wird. Verwende increase() oder rate() anstatt rohe Zählerwerte über Neustarts hinweg zu vergleichen.

Verwenden Sie die von Ihrer installierten Vorschauversion bereitgestellten Metrik-Namen, einschließlich cache_server_request_counter und der Latenzeinheit _ms. Prometheus-Namenskonventions-Lint-Tools können vor diesen Namen warnen, obwohl Prometheus sie scrapen und abfragen kann.

Beispiel für PromQL-Abfragen

Die folgenden Beispiele gehen davon aus, dass Ihre Metrik-Pipeline die Labels namespace und pod beibehält. Für einen gemeinsamen Metrik-Arbeitsbereich sollten Sie auch jedem Cluster ein eindeutiges cluster Label anhängen. Die Aggregationen behalten alle drei Labels bei, sodass identisch benannte Pods nicht über Namensräume oder Cluster hinweg kombiniert werden. Wenn dein Sammler ein anderes Cluster-Label verwendet, ersetze diesen Namen. Wenn kein Cluster-Label vorhanden ist, verwenden Sie eine Datenquelle, die auf einen Cluster beschränkt ist.

Lassen Sie mindestens zwei Wischvorgänge zu, bevor Sie rate() oder increase() bewerten. Bei einem inaktiven Server können die Latenzquantile und die durchschnittliche Anfragegröße NaN zurückgeben, da im Abfragefenster keine Anfragen beobachtet wurden. Dieser Zustand allein deutet nicht auf einen Scraping-Fehler hin. Überprüfen Sie die up Zielmetrik separat.

Aktive Verbindungen per Cache-Server

cache_server_active_connections

Anforderungsrate per Cacheserver

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

In der Veröffentlichung 0.1.0 umfasst cache_server_request_counter die Bezeichnungen request_type und status. Fügen Sie diese Labels in die Aggregation ein, um Uploads, Downloads und Fehlschläge aufzuteilen. Überprüfen Sie die Etiketten, die durch Ihre installierte Veröffentlichung sichtbar sind.

Erfolgreiche Downloads über einen Cache hinweg

Um die Download-Aktivität des Cache-Servers während wiederholter Lesevorgänge zu überprüfen, filtern Sie erfolgreiche Download-Anfragen und aggregieren Sie über alle Server-Pods hinweg, die der ausgewählten Cache-Ressource gehören:

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])
)

Ersetzen Sie die Cluster-, Namensraum- und Pod-Regex-Platzhalter. Wähle nur die Server-Pods aus, die deiner Cache-Ressource gehören, nicht andere Caches in einem gemeinsamen Namensraum. Für eine Datenquelle mit nur einem Cluster ohne Label cluster sollten Sie diesen Selektor weglassen. Bei den Label-Werten Success und Download wird zwischen Groß- und Kleinschreibung unterschieden.

Zeichnen Sie vor den Messungen einen Basiswert auf und lassen Sie mindestens zwei Scrapes zu. increase() schätzt die Aktivität über das Fenster und berücksichtigt Counter-Resets; es ist kein exakter Roh-Counter-Unterschied. Das Fehlen einer Zeitreihe ist kein Beweis für keine Aktivität. Überprüfen Sie den Scrape-Status und die offengelegten Labels, bevor Sie das Ergebnis interpretieren.

Korrelieren Sie den Anstieg mit Client-Cache-Hit-Metriken und isolieren Sie nicht zusammenhängenden Datenverkehr während der Validierung. Dieser Zähler ist kein Cache-Hit-Verhältnis, und ein erfolgreicher oder schnellerer Lesevorgang der Anwendung allein beweist keine Cache-Nutzung. Die Befüllung ist asynchron, sodass unmittelbar wiederholte Lesezugriffe trotzdem noch keine Daten liefern können. Siehe DACS-Anfragepfad überprüfen.

P95-Latenz erfolgreicher Anfragen (Millisekunden)

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

Durchschnittliche Größe der Download-Anfragen

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]))

Warteschlangenüberläufe

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

Listen- und SYN-Warteschlangenverluste

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

Empfohlene Warnungen

Erstellen Sie Warnungen, die Ihre Workload-Basislinie und die Größe der Cache-Server-VM widerspiegeln. Ziehen Sie mindestens folgende Benachrichtigungen in Betracht:

• Ein DACS-Scrape-Ziel, das nicht verfügbar ist oder fehlt.
• Anhaltende Erhöhungen ungleich null in cache_server_accept_queue_overflows_total.
• Anhaltende Erhöhungen ungleich null in cache_server_listen_drops_total oder cache_server_syn_queue_full_drops_total.
• Zunahmen in cache_server_accept_errors_total, gruppiert nach errno.
• P95- oder P99-Latenz erfolgreicher Anfragen über dem Workload-Ziel.
• Aktive Verbindungen nähern sich der getesteten Kapazität der VM-Größe des Cache-Servers.
• Unerwartete Änderungen der Cache-Größe oder ein Ungleichgewicht zwischen Cache-Server-Pods.
• Ungewöhnlich hohe systemweit zugewiesene Dateideskriptoren. Denken Sie daran, dass cache_server_open_fds keine Dateideskriptoranzahl pro Prozess ist.

Ermitteln Sie einen Basiswert unter erwarteter Parallelität, bevor Sie feste Schwellenwerte festlegen. Korrelieren Sie Netzwerkdruck-Metriken mit Anforderungsrate, Anforderungsgröße, Latenz, Knoten-CPU, Knotenspeicher sowie Azure Blob-Anfrage- und Bytemetriken.

Nächste Schritte

• Verwalten Sie den verteilten Accelerator für Cloud-Speicher.
• Fehlerbehebung eines verteilten Beschleunigers für Cloud-Speicher.