Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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.
El agente consta de una implementación con dos réplicas de forma predeterminada (que HPA configurará automáticamente en función del uso de memoria) 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 los pods de réplica ama-metrics no están programados en nodos o grupos de nodos con recursos suficientes, podrían obtener OOMKilled y entrar en CrashLoopBackoff. Para corregirlo, puede agregar la etiqueta azuremonitor/metrics.replica.preferred=true a los nodos o grupos de nodos del clúster con recursos más altos (en el grupo de nodos del sistema). Esto garantiza que los pods de réplica se programen en esos nodos. 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"