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"