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 que o nó tenha capacidade suficiente de CPU e memória. Caso o pod de réplica ama-metrics não seja agendado em um nó ou em um pool de nós com recursos suficientes, ele poderá ser finalizado por falta de memória (OOMKilled) e entrar no estado de CrashLoopBackoff. Para corrigir isso, você pode adicionar o rótulo azuremonitor/metrics.replica.preferred=true a um nó ou pool de nós no seu cluster que tenha recursos mais elevados (no pool de nós do sistema). Isso garante que o pod de réplica seja agendado nesse nó. Outra opção é criar pools de sistema extras com nós maiores e aplicar o mesmo rótulo. É melhor rotular pools de nós em vez de nós individuais, para que novos nós adicionados ao pool também possam ser usados para o agendamento.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"