Raspar métricas do Prometheus em escala no Azure Monitor
Este artigo fornece orientação 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 da CPU e da memória está correlacionado com o número de bytes de cada amostra e o número de amostras raspadas. Esses benchmarks são baseados nos destinos padrão raspados, no volume de métricas personalizadas raspadas e no número de nós, pods e contêineres. Estes números servem de referência, uma vez que a utilização ainda pode variar significativamente dependendo do número de séries cronológicas e bytes por métrica.
O limite superior de volume por pod é atualmente de cerca de 3-3,5 milhões de amostras por minuto, dependendo do número de bytes por amostra. Esta limitação é resolvida quando a fragmentação é adicionada no futuro.
O agente consiste em uma implantação com uma réplica e DaemonSet para raspar métricas. O DaemonSet raspa todos os destinos no nível do nó, como cAdvisor, kubelet e exportador de nós. Você também pode configurá-lo para raspar quaisquer destinos personalizados no nível do nó com configurações estáticas. O conjunto de réplicas raspa todo o resto, como kube-state-metrics ou trabalhos de raspagem personalizados que utilizam a descoberta de serviço.
Comparação entre cluster pequeno e grande para réplica
| Alvos de raspagem | Amostras Enviadas / Minuto | Contagem de nós | Contagem de vagens | Uso da CPU do Prometheus-Collector (núcleos) | Uso de memória do Prometheus-Collector (bytes) |
|---|---|---|---|---|---|
| Metas padrão | 11,344 | 3 | 40 | 12,9 mc | 148 mi |
| Metas padrão | 260,000 | 340 | 13000 | 1,10 C | 1,70 GB |
| Metas padrão + Alvos personalizados |
3,56 milhões | 340 | 13000 | 5,13 C | 9,52 GB |
Comparação entre cluster pequeno e grande para DaemonSets
| Alvos de raspagem | Amostras Enviadas / Total Minuto | Amostras Enviadas / Minuto / Pod | Contagem de nós | Contagem de vagens | Total de uso da CPU do Prometheus-Collector (núcleos) | Total de uso de memória do Prometheus-Collector (bytes) | Prometheus-Collector CPU Uso / Pod (núcleos) | Prometheus-Collector Uso de memória / Pod (bytes) |
|---|---|---|---|---|---|---|---|---|
| Metas padrão | 9,858 | 3,327 | 3 | 40 | 41,9 mc | 581 Mi | 14,7 mc | 189 mi |
| Metas padrão | 2,3 milhões | 14,400 | 340 | 13000 | 805 mc | 305,34 GB | 2,36 mc | 898 mi |
Para métricas mais personalizadas, o pod único se comporta da mesma forma que o pod de réplica, dependendo do volume de métricas personalizadas.
Agende um pod de réplica ama-metrics em um pool de nós com mais recursos
Um grande volume de métricas por pod precisa de um nó com CPU e memória suficientes. Se o pod de réplica ama-metrics não estiver agendado em um nó ou pool de nós com recursos suficientes, ele poderá obter OOMKilled e entrar em CrashLoopBackoff. Para corrigir isso, você pode adicionar o rótulo azuremonitor/metrics.replica.preferred=true a um nó ou pool de nós no cluster com recursos mais altos (no pool de nós do sistema). Isso garante que o pod de réplica seja agendado nesse nó. Você também pode criar pools de sistema extras com nós maiores e adicionar o mesmo rótulo. É melhor rotular pools de nós em vez de nós individuais para que novos nós no pool também possam ser usados para agendamento.
kubectl label nodes <node-name> azuremonitor/metrics.replica.preferred="true"
Próximos passos
- Solucione problemas com a coleta de dados do Prometheus.