Irakurri ingelesez

Partekatu honen bidez:


Extracción de métricas de Prometheus a gran escala en Azure Monitor

En este artículo se proporciona una guía sobre el rendimiento que se puede esperar cuando se recopilan métricas a gran escala para el servicio administrado de Azure Monitor para Prometheus.

CPU y memoria

El uso de la CPU y la memoria se correlaciona con el número de bytes de cada muestra y el número de muestras que se han extraído. Estos puntos de referencia se basan en los destinos predeterminados extraídos, el volumen de métricas personalizadas extraídas y el número de nodos, pods y contenedores. Estos números están diseñados como referencia, ya que el uso puede variar significativamente en función del número de series de tiempo y bytes por métrica.

El límite de volumen superior por pod es actualmente de aproximadamente entre 3 y 3,5 millones de muestras por minuto, según el número de bytes por muestra. Esta limitación se soluciona cuando se agrega particionamiento en el futuro.

El agente consta de una implementación con una réplica y DaemonSet para extraer métricas. El DaemonSet extrae cualquier objetivo a nivel de nodo, como cAdvisor, kubelet y el exportador de nodos. También puede configurarlo para extraer cualquier destino personalizado en el nivel de nodo con configuraciones estáticas. El conjunto de réplicas extrae todo lo demás, como valores de tipo kube-state-metrics o trabajos de extracción personalizados que usan la detección de servicios.

Comparación entre clúster pequeño y grande para réplica

Destinos de extracción Muestras enviadas por minuto Recuento de nodos Número de pods Uso de CPU de Prometheus-Collector (núcleos) Uso de memoria de Prometheus-Collector (bytes)
destinos predeterminados 11 344 3 40 12,9 mc 148 Mi
destinos predeterminados 260 000 340 13000 1,10 c 1,70 GB
destinos predeterminados
más destinos personalizados
3,56 millones 340 13000 5,13 c 9,52 GB

Comparación entre clúster pequeño y grande para DaemonSets

Destinos de extracción Muestras enviadas por total de minutos Muestras enviadas por minuto por pod Recuento de nodos Número de pods Uso total de CPU de Prometheus-Collector (núcleos) Uso total de memoria de Prometheus-Collector (bytes) Uso de CPU de Prometheus-Collector por pod (núcleos) Uso de memoria de Prometheus-Collector por pod (bytes)
destinos predeterminados 9858 3327 3 40 41,9 mc 581 Mi 14,7 mc 189 Mi
destinos predeterminados 2,3 millones 14 400 340 13000 805 mc 305,34 GB 2,36 mc 898 Mi

Para más métricas personalizadas, el pod único se comporta igual que el pod de réplica según el volumen de métricas personalizadas.

Programar un pod de réplica de ama-metrics en un grupo de nodos con más recursos

Un gran volumen de métricas por pod necesita un nodo con suficiente CPU y memoria. Si el pod de réplica de ama-metrics no se programa en un nodo o grupo de nodos que tiene suficientes recursos, es posible que siga recibiendo OOMKilled y vaya a CrashLoopBackoff. Para corregirlo, puede agregar la etiqueta azuremonitor/metrics.replica.preferred=true a un nodo o grupo de nodos en el clúster con recursos más altos (en grupo de nodos del sistema). Esto garantiza que el pod de réplica se programe en ese nodo. También puede crear grupos de sistemas adicionales con nodos más grandes y agregar la misma etiqueta. Es mejor etiquetar grupos de nodos en lugar de nodos individuales, por lo que también se pueden usar nodos nuevos en el grupo para programar.

kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"

Pasos siguientes