Extrair métricas do Prometheus em escala no Azure Monitor
Este artigo fornece diretrizes sobre o desempenho que pode ser esperado ao coletar métricas em alta escala para o Serviço gerenciado do Azure Monitor para Prometheus.
CPU e memória
O uso de CPU e memória está correlacionado ao número de bytes de cada amostra e o número de amostras extraídas. Esses parâmetros de comparação baseiam-se nos destinos padrão extraídos, no volume de métricas personalizadas extraídas e no número de nós, pods e contêineres. Esses números são uma referência, pois o uso ainda pode variar significativamente dependendo do número de séries temporais e bytes por métrica.
Atualmente, o limite de volume superior por pod é de cerca de 3 a 3,5 milhões de amostras por minuto, dependendo do número de bytes por amostra. Essa limitação é resolvida quando a fragmentação é adicionada no futuro.
O agente consiste em uma implantação com uma réplica e um DaemonSet para métricas de extração. O DaemonSet extrai todos os destinos no nível do nó, como cAdvisor, kubelet e exportador de nós. Você também pode configurá-lo para extrair quaisquer destinos personalizados no nível do nó com configurações estáticas. O conjunto de réplicas extrai todo o resto, como kube-state-metrics ou trabalhos de extração personalizados que utilizam a descoberta de serviço.
Comparação entre cluster pequeno e grande para réplica
| Destinos de extração | Amostras Enviadas / Minuto | Contagem de nós | Contagem de Pods | Uso da CPU Prometheus-Coletor (núcleos) | Uso de memória Prometheus-Coletor (bytes) |
|---|---|---|---|---|---|
| destinos padrão | 11.344 | 3 | 40 | 12,9 mc | 148 Mi |
| destinos padrão | 260.000 | 340 | 13000 | 1,10c | 1,70 GB |
| destinos padrão + destinos personalizados |
3,56 milhões | 340 | 13000 | 5,13c | 9,52 GB |
Comparação entre cluster pequeno e grande para DaemonSets
| Destinos de extração | Amostras Enviadas / Total de minutos | Amostras Enviadas / Minuto / Pod | Contagem de nós | Contagem de Pods | Total de Uso da CPU Prometheus-Coletor (núcleos) | Total de Uso de Memória Prometheus-Coletor (bytes) | Uso da CPU / Pod (núcleos) Prometheus-Coletor | Uso de Memória / Pod (bytes) Prometheus-Coletor |
|---|---|---|---|---|---|---|---|---|
| destinos padrão | 9.858 | 3.327 | 3 | 40 | 41,9 mc | 581 Mi | 14,7 mc | 189 Mi |
| destinos padrão | 2,3 milhões | 14.400 | 340 | 13000 | 805 mc | 305,34 GB | 2,36 mc | 898 Mi |
Para mais métricas personalizadas, o pod único se comporta da mesma forma que o pod réplica, dependendo do volume de métricas personalizadas.
Agendar o pod réplica ama-metrics em um pool de nós com mais recursos
Um grande volume de métricas por pod exige um nó grande o suficiente para ser capaz de lidar com o uso de CPU e memória necessário. Se o pod réplica ama-metrics não for agendado em um nó ou nodepool que tenha recursos suficientes, ele poderá continuar recebendo OOMKilled e ir para CrashLoopBackoff. Para superar esse problema, se você tiver um nó ou nodepool no cluster que tenha recursos mais superiores (no pool de nós do sistema) e desejar agendar a réplica nesse nó, você poderá adicionar o rótulo azuremonitor/metrics.replica.preferred=true no nó e o pod réplica será agendado nele. Além disso, você pode criar pools de sistema adicionais, se necessário, com nós maiores e pode adicionar o mesmo rótulo aos nós ou nodepools deles. Também é melhor adicionar rótulos ao nodepool em vez de nós para que nós mais recentes no mesmo pool também possam ser usados para agendamento quando esse rótulo for aplicável a todos os nós no pool.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"