Monitora l'acceleratore distribuito per lo storage cloud (anteprima)

Distributed accelerator for cloud storage (DACS) espone metriche in formato Prometheus da ogni server cache. Utilizzare queste metriche per monitorare connessioni, capacità di cache, latenza e volume delle richieste, dimensioni delle richieste e pressione di rete del sistema operativo.

Endpoint delle metriche

Prima di iniziare, installa DACS e aspetta che i pod del server cache siano pronti. Sostituisci <cache-namespace> nei comandi e nella configurazione con lo spazio di nomi che contiene quei pod.

Ogni pod cache-server espone metriche sulla porta 9096 nel /metrics percorso. Inserire ogni pod del server di cache in modo che il sistema di monitoraggio acquisisca lo stato e i contatori per server.

Elenca i pod del cache-server e conferma la porta delle metriche:

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

Verifica localmente un endpoint:

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

In un altro terminale, recupera le metriche:

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

Ferma il comando port-forward quando hai finito di controllare l'endpoint.

Configura la tua pipeline di metriche

Configura il tuo collector compatibile con Prometheus per scoprire i pod del server cache nel namespace DACS e fai scraping alla porta 9096 su /metrics. Il collector necessita di accesso di rete agli indirizzi IP del pod sulla porta 9096 e di accesso autenticato all'API Kubernetes. Concedere le autorizzazioni per l'identità get, list e watch per i pod nello spazio dei nomi DACS. Per un collector in-cluster, assegna un ruolo con questi permessi al suo account di servizio.

La seguente configurazione di Prometheus è un esempio di collettore in-cluster. Limita la scoperta di Kubernetes allo spazio dei nomi DACS. Sostituisci <cache-namespace> con il tuo namespace.

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

Se la tua pipeline utilizza un Operatore Prometheus, crea una PodMonitor risorsa o una risorsa equivalente che selezioni app=cacheserver, il namespace DACS e la porta metrica. Usa le etichette e i nomi delle porte della versione preliminare installata.

Dopo aver configurato lo scraping, verifica che il tuo sistema di metriche abbia un target attivo per ogni pod di server cache. Conserva le etichette pod, instance e namespace così puoi identificare un singolo server cache malsano o saturo.

Informazioni di riferimento sulle metriche

Un server di cache espone le seguenti famiglie di metriche:

Le famiglie di metriche degli istogrammi espongono le serie standard _bucket, _sum, e _count temporali. I valori dei contatori si resettano quando un processo del server di cache si riavvia. Usa rate() o increase() invece di confrontare i valori grezzi dei contatori tra i riavvii.

Usa i nomi delle metriche esposti dalla tua versione preview installata, inclusi cache_server_request_counter e l'unità _ms di latenza. Gli strumenti lint di Prometheus per le convenzioni di denominazione possono avvertire di questi nomi anche se Prometheus può analizzarli e interrogarli.

Esempi di query PromQL

I seguenti esempi presumono che la tua pipeline di metriche preservi le etichette namespace e pod. Per uno spazio di lavoro di metriche condiviso, aggiungi anche un'etichetta unica cluster ai campioni di ogni cluster. Le aggregazioni mantengono tutte e tre le etichette in modo che i pod con nomi identici non vengano combinati tra namespace o cluster. Se il tuo collector usa un'etichetta cluster diversa, sostituisci quel nome. Senza un'etichetta di cluster, usa una sorgente dati limitata a un solo cluster.

Consentire almeno due inserimenti prima di valutare rate() o increase(). Su un server inattivo, il quantile di latenza e la dimensione media della richiesta possono essere restituiti NaN perché non sono state osservate richieste nella finestra di interrogazione. Questa condizione di per sé non indica un errore di scraping. Controllare separatamente la metrica up della destinazione.

Connessioni attive tramite server cache

cache_server_active_connections

Tasso di richieste per server cache

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

La versione 0.1.0, cache_server_request_counter comprende le etichette request_type e status. Includere queste etichette nell'aggregazione per suddividere caricamenti, download ed errori. Controlla le etichette rese disponibili dalla versione installata.

Download riusciti nella cache

Per verificare l'attività di download del server cache durante le letture ripetute, filtra le richieste di download riuscite e aggrega su tutti i pod server posseduti dalla risorsa Cache selezionata:

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

Sostituisci i segnaposto cluster, namespace e pod-regex. Abbina solo i server pod posseduti dalla tua risorsa Cache e non quelli di altre cache in uno spazio di nomi condiviso. Per una sorgente dati a cluster singolo senza cluster etichetta, ometti quel selettore. I valori delle etichette Download e Success applicano la distinzione tra maiuscole e minuscole.

Registrare una linea di base prima delle letture e consentire almeno due inserimenti. increase() stima l'attività sulla finestra e tiene conto dei reset dei contatori; non è una differenza esatta tra contatori grezzi. Una serie assente non è prova di attività pari a zero. Controlla lo stato dello scraping e le etichette esposte prima di interpretare il risultato.

Correla l'aumento con le metriche di cache hit del client e isola il traffico non correlato durante la validazione. Questo contatore non è un rapporto di cache hit, e una lettura dell'applicazione riuscita o più veloce da sola non prova l'uso della cache. La popolazione è asincrona, quindi le letture ripetute immediate potrebbero comunque non restituire dati. Vedi Verifica il percorso della richiesta DACS.

Latenza di richiesta di successo P95 (millisecondi)

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

Dimensione media delle richieste di download

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

Accettare gli overflow della coda

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

Ascolto e rimozioni della coda SYN

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

Avvisi consigliati

Crea avvisi che riflettano la baseline del carico di lavoro e la dimensione della VM del server cache. Al minimo, considera gli avvisi per:

• Un bersaglio di scraping DACS non disponibile o mancante.
• Aumenti sostenuti diversi da zero in cache_server_accept_queue_overflows_total.
• Aumenti persistenti diversi da zero in cache_server_listen_drops_total o cache_server_syn_queue_full_drops_total.
• Aumenti in cache_server_accept_errors_total, raggruppati per errno.
• Latenza delle richieste riuscite P95 o P99 superiore all'obiettivo del carico di lavoro.
• Connessioni attive che si avvicinano alla capacità testata delle dimensioni della VM del server di cache.
• Cambiamenti inaspettati nella dimensione della cache o squilibri tra i pod dei server della cache.
• Handle di file allocati a livello di sistema anormalmente elevati. Ricorda che cache_server_open_fds non è un conteggio di descrittori di file per processo.

Stabilire una linea di base in condizioni di concorrenza previste prima di impostare soglie fisse. Correlaciona le metriche di pressione di rete con la frequenza delle richieste, la dimensione della richiesta, la latenza, la CPU del nodo, la memoria dei nodi e le metriche di richiesta e byte di Azure Blob.

Passaggi successivi

• Gestisci un acceleratore distribuito per lo storage cloud.
• Risoluzione dei problemi con acceleratore distribuito per lo storage cloud.