Supervisar el acelerador distribuido para el almacenamiento en la nube (versión preliminar)

El acelerador distribuido para el almacenamiento en la nube (DACS) expone métricas en formato Prometheus desde cada servidor de caché. Utilice estas métricas para supervisar las conexiones, la capacidad de la caché, la latencia y el volumen de las solicitudes, el tamaño de las solicitudes y la presión de red del sistema operativo.

Punto de conexión de métricas

Antes de empezar, instala DACS y espera a que los pods de cache-server estén listos. Sustituye <cache-namespace> en los comandos y la configuración por el espacio de nombres que contiene esos pods.

Cada pod de servidor caché expone métricas en el puerto 9096 en la /metrics ruta. Recopile las métricas de todos los pods de servidor de caché para que el sistema de supervisión capture el estado y los contadores de cada servidor.

Enumera los pods de servidor caché y confirma el puerto 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}'

Verifica un punto de conexión 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

En otro terminal, recupera las métricas:

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

Detén el comando de reenvío de puertos cuando termines de revisar el endpoint.

Configura tu pipeline de métricas

Configura tu colector compatible con Prometheus para descubrir pods de servidores de caché en el espacio de nombres DACS y recopilar métricas del puerto 9096 en /metrics. El colector necesita acceso de red a las direcciones IP del pod en el puerto 9096 y acceso autenticado a la API de Kubernetes. Otorgue a su identidad los permisos get, list y watch para pods en el espacio de nombres DACS. Para un colector dentro del clúster, asigna un Rol con estos permisos a su cuenta de servicio.

La siguiente configuración de Prometheus es un ejemplo de un colector dentro del clúster. Limita el descubrimiento de Kubernetes al espacio de nombres DACS. Sustituye <cache-namespace> por tu espacio de nombres.

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

Si tu pipeline utiliza un operador Prometheus, crea un recurso PodMonitor o equivalente que seleccione app=cacheserver, el espacio de nombres DACS y el puerto de métricas. Usa las etiquetas y los nombres de los puertos de tu versión preliminar instalada.

Después de configurar el scraping, verifica que tu sistema de métricas tenga un objetivo activo para cada pod de servidor caché. Conserva las podetiquetas , instance, y namespace para poder identificar un único servidor caché poco saludable o saturado.

Referencia de métricas

Un servidor de caché expone las siguientes familias de métricas:

Las familias de métricas de histogramas exponen las series temporales estándar _bucket, _sum y _count. Los valores de contador se reinician cuando un proceso del servidor de caché se reinicia. Usa rate() o increase() en lugar de comparar los valores brutos de los contadores entre reinicios.

Usa los nombres de métricas expuestos por tu versión previa instalada, incluyendo cache_server_request_counter y la unidad de latencia _ms. Las herramientas de análisis de convenciones de nomenclatura de Prometheus pueden generar advertencias sobre estos nombres, aunque Prometheus pueda recopilar las métricas y consultarlas.

Ejemplos de consultas PromQL

Los siguientes ejemplos asumen que tu pipeline de métricas preserva las etiquetas namespace y pod. Para un espacio de trabajo de métricas compartido, añade también una etiqueta única cluster a las muestras de cada clúster. Las agregaciones conservan las tres etiquetas para evitar que se combinen pods con el mismo nombre de distintos espacios de nombres o clústeres. Si tu colector usa una etiqueta diferente del clúster, sustituye ese nombre. Si no dispone de una etiqueta de clúster, utilice un origen de datos limitado a un único clúster.

Permita que se realicen al menos dos extracciones antes de evaluar rate() o increase(). En un servidor inactivo, el cuantil de latencia y el tamaño medio de la petición pueden devolver un valor como NaN porque no se observaron solicitudes en la ventana de consulta. Esta condición por sí sola no indica un error de extracción. Comprueba la métrica del up destino por separado.

Conexiones activas por servidor de caché

cache_server_active_connections

Tasa de solicitud por servidor de caché

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

En el lanzamiento 0.1.0, cache_server_request_counter incluye las etiquetas request_type y status. Incluye esas etiquetas en la agregación para dividir subidas, descargas y fallos. Revisa las etiquetas expuestas por tu versión instalada.

Descargas correctas en la caché

Para comprobar la actividad de descarga de los servidores de caché durante las lecturas repetidas, filtre las solicitudes de descarga correctas y agregue los resultados de todos los pods de servidor pertenecientes al recurso de caché seleccionado:

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

Sustituya los marcadores de posición del clúster, el espacio de nombres y la expresión regular de los pods. Selecciona solo los pods de servidor que posee tu recurso de caché, no otras cachés en un espacio de nombres compartido. Para una fuente de datos de un solo clúster sin una etiqueta cluster, omite ese selector. Los valores de las etiquetas Download y Success distinguen entre mayúsculas y minúsculas.

Registre un valor de referencia antes de las lecturas y permita al menos dos recopilaciones de métricas. increase() estima la actividad durante el intervalo y tiene en cuenta los reinicios de contadores; no es una diferencia exacta entre contadores en bruto. Una serie ausente no es prueba de actividad cero. Comprueba el estado del scraping y las etiquetas expuestas antes de interpretar el resultado.

Correlaciona el aumento con las métricas de aciertos de caché del cliente y aísla el tráfico no relacionado durante la validación. Este contador no es una tasa de aciertos de caché, y una lectura correcta o más rápida de la aplicación por sí sola no demuestra el uso de la caché. La carga es asincrónica, por lo que las lecturas repetidas inmediatas pueden seguir sin encontrar datos. Consulte Comprobar la ruta de solicitudes de DACS.

Latencia de petición exitosa P95 (milisegundos)

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

Tamaño medio de la solicitud de descarga

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

Desbordamientos de la cola de aceptación

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

Pérdidas en las colas de escucha y SYN

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

Alertas recomendadas

Crea alertas que reflejen la línea base de tu carga de trabajo y el tamaño de la máquina virtual del servidor de caché. Como mínimo, considera alertas para:

• Un objetivo de scraping DACS que está caído o no se encuentra.
• Aumentos sostenidos distintos de cero en cache_server_accept_queue_overflows_total.
• Aumentos sostenidos distintos de cero en cache_server_listen_drops_total o cache_server_syn_queue_full_drops_total.
• Aumentos en cache_server_accept_errors_total, agrupados por errno.
• Latencia del percentil 95 (P95) o 99 (P99) de las solicitudes correctas superior al objetivo de la carga de trabajo.
• Conexiones activas que se aproximan a la capacidad probada del tamaño de máquina virtual del servidor de caché.
• Cambios inesperados en el tamaño de la caché o desequilibrio entre los pods de servidor de caché.
• Número anormalmente alto de manejadores de archivo asignados a nivel de sistema. Recuerda que cache_server_open_fds no es un recuento de descriptores de archivo por proceso.

Establecer una línea base bajo la concurrencia esperada antes de establecer umbrales fijos. Correlaciona las métricas de presión de red con la tasa de solicitud, tamaño de la petición, latencia, CPU del nodo, memoria del nodo y métricas de petición y byte de Azure Blob.

Pasos siguientes

• Gestionar el acelerador distribuido para almacenamiento en la nube.
• Soluciona problemas con el acelerador distribuido para almacenamiento en la nube.