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 requiere un nodo lo suficientemente grande como para poder manejar el uso de CPU y memoria requerido. Si el pod de réplica ama-metrics no se programa en un nodo o un grupo de nodos que tenga suficientes recursos, es posible que siga recibiendo OOMKilled y vaya a CrashLoopBackoff. Para solucionar este problema, si tiene un nodo o grupo de nodos en el clúster que tiene mayores recursos (preferiblemente en el grupo de nodos del sistema) y desea programar la réplica en ese nodo, puede agregar la etiqueta azuremonitor/metrics.replica.preferred=true en el nodo y el pod de réplica se programará en este nodo. También puede crear grupos de sistemas adicionales, si es necesario, con nodos más grandes y puede agregar la misma etiqueta a sus nodos o grupo de nodos. También es mejor agregar etiquetas a nodepool en lugar de nodos, por lo que los nodos más recientes del mismo grupo también pueden ser usados para programar cuando esta etiqueta se aplica a todos los nodos del grupo.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"