Monitorar o acelerador distribuído para armazenamento em nuvem (versão prévia)

O acelerador distribuído para armazenamento em nuvem (DACS) expõe métricas no formato Prometheus de cada servidor de cache. Use essas métricas para monitorar conexões, capacidade de cache, latência e volume de solicitações, tamanhos de solicitações e pressão da rede do sistema operacional.

Ponto de extremidade de métricas

Antes de começar, instale o DACS e espere os pods do servidor de cache estarem prontos. Substitua <cache-namespace> nos comandos e na configuração pelo namespace que contém esses pods.

Cada pod de servidor cache expõe métricas na porta 9096 no caminho /metrics. Faça scraping de cada pod de servidor de cache para que seu sistema de monitoramento capture o estado e os contadores por servidor.

Liste os pods do servidor de cache e confirme a porta de métricas:

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

Verifique um endpoint localmente:

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

Em outro terminal, recupere as métricas:

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

Pare o comando de encaminhamento de porta quando terminar de verificar o endpoint.

Configure seu pipeline de métricas

Configure seu coletor compatível com Prometheus para descobrir pods de servidores de cache no namespace do DACS e raspar a porta 9096 em /metrics. O coletor precisa de acesso de rede aos endereços IP do pod na porta 9096 e acesso autenticado à API Kubernetes. Conceda permissões get, list e watch para pods no namespace DACS à sua identidade. Para um coletor dentro do cluster, vincule um Role com essas permissões à sua conta de serviço.

A seguinte configuração do Prometheus é um exemplo de coletor dentro do cluster. Limita a descoberta do Kubernetes ao namespace do DACS. Substitua <cache-namespace> pelo seu 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 seu pipeline usar um Operador Prometheus, crie um PodMonitor ou equivalente recurso que selecione app=cacheserver, o namespace DACS e a porta de métricas. Use os rótulos e nomes de porta da sua versão prévia instalada.

Após configurar o scraping, verifique se seu sistema de métricas tem um alvo ativo para cada pod de servidor de cache. Mantenha os rótulos pod, instance e namespace para que você possa identificar um único servidor de cache não íntegro ou saturado.

Referência de métricas

Um servidor de cache expõe as seguintes famílias de métricas:

Famílias métricas de histogramas expõem as séries padrão _bucket, _sum, e _count temporais. Os valores de contador são resetados quando um processo do servidor de cache reinicia. Use rate() ou increase(), em vez de comparar valores brutos de contadores entre reinícios.

Use os nomes das métricas expostos pela sua compilação de pré-visualização instalada, incluindo cache_server_request_counter e a unidade de latência _ms. As ferramentas de lint da convenção de nomeação do Prometheus podem alertar sobre esses nomes, mesmo que ele possa extrair e consultar esses nomes.

Exemplo de consultas PromQL

Os exemplos a seguir pressupõem que seu pipeline de métricas preserva os rótulos namespace e pod. Em um espaço de trabalho de métricas compartilhado, anexe também um rótulo cluster exclusivo às amostras de cada cluster. As agregações preservam os três rótulos para que pods com nomes idênticos não sejam combinados entre namespaces ou clusters. Se seu coletor usa um rótulo de cluster diferente, substitua esse nome. Sem um rótulo de cluster, use uma fonte de dados limitada a um cluster.

Aguarde pelo menos duas extrações antes de avaliar rate() ou increase(). Em um servidor ocioso, o quantil da latência e o tamanho médio da solicitação podem retornar NaN, porque nenhuma solicitação foi observada na janela de consulta. Essa condição por si só não indica uma falha de raspagem. Verifique separadamente a métrica de destino up.

Conexões ativas por servidor de cache

cache_server_active_connections

Taxa de solicitação por servidor de cache

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

Na versão 0.1.0, cache_server_request_counter inclui rótulos request_type e status. Inclua esses selos na agregação para dividir uploads, downloads e falhas. Verifique os rótulos exibidos na sua versão instalada.

Downloads bem-sucedidos em um cache

Para verificar a atividade de download do servidor de cache durante leituras repetidas, filtre as solicitações de download bem-sucedidas e agregue entre todos os pods de servidores pertencentes ao recurso de cache selecionado:

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

Substitua os espaços reservados de cluster, namespace e pod-regex. Selecione apenas os pods de servidor pertencentes ao seu recurso de cache, não outros caches em um namespace compartilhado. Para uma fonte de dados de cluster único sem rótulo cluster , omita esse seletor. Os valores de rótulos Download e Success diferenciam maiúsculas e minúsculas.

Registre uma linha de base antes das leituras e aguarde pelo menos duas extrações. increase() estima a atividade sobre a janela e leva em conta os resets do contador; não é uma diferença exata do contador bruto. Uma série ausente não é prova de atividade zero. Verifique a integridade da extração e os rótulos expostos antes de interpretar o resultado.

Correlacione o aumento com métricas de acerto em cache do cliente e isole o tráfego não relacionado durante a validação. Esse contador não é uma proporção de acerto no cache, e uma leitura bem-sucedida ou mais rápida do aplicativo, por si só, não prova o uso do cache. A população é assíncrona, então leituras imediatas repetidas ainda podem não encontrar o dado. Consulte Verificar o caminho da solicitação do DACS.

Latência de solicitação bem-sucedida P95 (milissegundos)

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

Tamanho médio das solicitações de 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]))

Aceitar estouros de fila

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

Quedas nas filas de escuta e SYN

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

Alertas recomendados

Crie alertas que reflitam sua linha de base de carga de trabalho e o tamanho da VM do servidor de cache. No mínimo, considere alertas para:

• Um alvo de raspagem DACS que está caído ou faltando.
• Aumentos contínuos diferentes de zero em cache_server_accept_queue_overflows_total.
• Aumentos sustentados não nulos em cache_server_listen_drops_total ou cache_server_syn_queue_full_drops_total.
• Aumentos em cache_server_accept_errors_total, agrupados por errno.
• Latência de solicitação bem-sucedida P95 ou P99 acima do objetivo da carga de trabalho.
• Conexões ativas se aproximando da capacidade testada da configuração da VM do servidor de cache.
• Mudanças inesperadas no tamanho do cache ou desequilíbrio entre pods de servidores de cache.
• Número anormalmente alto de handles de arquivo alocados no sistema. Lembre-se que isso cache_server_open_fds não é uma contagem de descritores de arquivo por processo.

Estabeleça uma baseline em condições de concorrência esperadas antes de definir limites fixos. Correlacione métricas de pressão de rede com taxa de requisição, tamanho da requisição, latência, CPU do nó, memória do nó e métricas de requisição e byte do Azure Blob.

Próximas Etapas 

• Gerencie o acelerador distribuído para armazenamento em nuvem.
• Solucionar problemas com aceleradores distribuídos para Cloud Storage.