Monitor accelerator distribuído para armazenamento na nuvem (pré-visualização)

O acelerador distribuído para armazenamento na nuvem (DACS) expõe métricas em formato Prometheus de cada servidor de cache. Utilize estas métricas para monitorizar ligações, capacidade de cache, latência e volume de pedidos, tamanhos dos pedidos e pressão da rede do sistema operativo.

Ponto final de métricas

Antes de começares, instala o DACS e espera que os pods do servidor cache estejam 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. Recolhe métricas de todos os pods de servidor de cache para que o teu sistema de monitorização capture o estado e os contadores de cada servidor.

Liste os pods de 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 dos endpoints 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

Noutro terminal, recupere as métricas:

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

Pára o comando port-forward quando terminares de verificar o endpoint.

Configure o seu pipeline de métricas

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

A seguinte configuração do Prometheus é um exemplo de um coletor dentro do cluster. Limita a descoberta do Kubernetes ao espaço de nomes DACS. Substitui <cache-namespace> pelo teu espaço de nomes.

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 o 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. Usa as etiquetas e nomes das portas da versão de pré-visualização instalada.

Depois de configurar a recolha, verifique se o seu sistema de métricas tem um alvo ativo para cada pod de servidor de cache. Preserve os podrótulos, instance e namespace para que possas identificar um único servidor de cache pouco saudável ou saturado.

Referência de métricas

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

As famílias de métricas de histogramas expõem as séries temporais padrão _bucket, _sum e _count. Os valores dos contadores são redefinidos quando um processo cache-server é reiniciado. Utilize rate() ou increase() em vez de comparar valores brutos de contadores entre reinícios.

Usa os nomes das métricas expostos pela tua versão de pré-visualização instalada, incluindo cache_server_request_counter e a unidade de latência _ms. As ferramentas de convenção de nomenclatura da Prometheus podem alertar sobre estes nomes, mesmo que o Prometheus consiga recolhê-los e consultá-los.

Exemplos de consultas PromQL

Os exemplos seguintes assumem que o seu pipeline de métricas preserva as namespace etiquetas e pod e. Para um espaço de trabalho de métricas partilhado, anexe também uma etiqueta única cluster às amostras de cada cluster. As agregações mantêm os três rótulos para que pods com nomes idênticos não sejam combinados entre namespaces ou clusters. Se o seu coletor usar uma etiqueta cluster diferente, substitua esse nome. Sem um rótulo de cluster, use uma fonte de dados limitada a um cluster.

Permita pelo menos duas raspagens antes de avaliar rate() ou increase(). Num servidor inativo, o quantil de latência e o tamanho médio do pedido podem ser retornados NaN porque não foram observados pedidos na janela de consulta. Esta condição, por si só, não indica uma falha de scrape. Verifique a métrica do up alvo separadamente.

Ligações ativas por servidor de cache

cache_server_active_connections

Taxa de pedido por servidor de cache

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

No lançamento 0.1.0, cache_server_request_counter inclui os rótulos request_type e status. Inclua essas etiquetas na agregação para dividir uploads, downloads e falhas. Verifique as etiquetas expostas pelo seu release instalado.

Downloads bem-sucedidos numa cache

Para verificar a atividade de download do cache-server durante leituras repetidas, filtre os pedidos de Download bem-sucedidos e agregue os dados de todos os pods do servidor pertencentes ao recurso 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 o cluster, o namespace e os marcadores de posição de pod-regex. Faz corresponder apenas os pods de servidor pertencentes ao teu recurso de Cache, não outros caches num namespace partilhado. Para uma fonte de dados de cluster único sem rótulo cluster , omita esse seletor. Os valores das etiquetas Download e Success distinguem maiúsculas de minúsculas.

Regista uma linha de base antes das leituras e permite pelo menos dois arranhões. increase() estima a atividade na janela e tem em conta as reposições a zero do contador; não é uma diferença exata do contador em bruto. Uma série ausente não é prova de atividade zero. Verifique a saúde da recolha e os rótulos expostos antes de interpretar o resultado.

Correlacione o aumento com métricas de cache-hit do cliente e isole o tráfego não relacionado durante a validação. Este contador não é uma taxa de acertos da cache, e uma aplicação bem-sucedida ou mais rápida em leitura isolada não prova o uso da cache. O preenchimento é assíncrono, por isso leituras repetidas imediatas ainda podem falhar. Consulte Verificar o caminho do pedido DACS.

Latência de pedido bem-sucedido do 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 transferência

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

Sobrecargas da fila de ligações aceites

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 a linha de base da sua 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á em baixo ou indisponível.
• Aumentos contínuos acima de zero em cache_server_accept_queue_overflows_total.
• Aumentos sustentados diferentes de zero 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 pedido bem-sucedido P95 ou P99 acima do objetivo da carga de trabalho.
• As ligações ativas estão a aproximar-se da capacidade testada para este tamanho de VM do servidor de cache.
• Alterações inesperadas no tamanho da cache ou desequilíbrio entre pods de servidores de cache.
• Descritores de ficheiros atribuídos anormalmente elevados a nível de sistema. Lembra-te que cache_server_open_fds não é uma contagem de descritores de ficheiro por processo.

Estabeleça uma linha base sob concorrência esperada antes de definir limiares fixos. Correlacione métricas de pressão de rede com taxa de solicitações, tamanho da solicitação, latência, CPU do nó, memória do nó e métricas de solicitações e bytes do Azure Blob.

Passos seguintes

• Gerir acelerador distribuído para armazenamento na cloud.
• Resolver problemas no acelerador distribuído para armazenamento na cloud.