Prometheus é um kit de ferramentas de monitoramento e alerta de código aberto e fácil de usar. Sua popularidade se deve, sem dúvida, ao seu eficiente banco de dados de coleta de dados de série temporal, linguagem de consulta flexível (PromQL) e escalabilidade geral. Além disso, seu suporte para descoberta dinâmica de serviços, integração nativa com Kubernetes e recursos de alerta o tornam uma ótima opção para monitoramento em ambientes dinâmicos nativos da nuvem. O Prometheus também possui uma comunidade ativa e de código aberto que contribui para melhorias contínuas e adoção crescente.
No entanto, apesar de todos os benefícios que o Prometheus oferece, muitos desafios podem facilmente perturbar o bom funcionamento. Vamos dar uma olhada em alguns deles.
É bastante comum que pessoas inexperientes com o Prometheus encontrem problemas de alta cardinalidade. Esses problemas podem fazer com que as instâncias do Prometheus cresçam muito mais rápido do que o esperado, criando assim problemas de escalabilidade e desempenho.
No Prometheus, cardinalidade se refere ao número de séries métricas exclusivas. Uma situação de alta cardinalidade ocorre quando há um grande número de rótulos de métricas ou valores de rótulos distintos sendo gerados.
Isso geralmente surge do uso indevido ou da má compreensão dos rótulos. Por exemplo, adicionar rótulos altamente dinâmicos (como carimbos de data/hora, identificadores exclusivos ou IDs de usuário) às métricas pode aumentar rapidamente o número de séries temporais armazenadas.
Isso pode resultar em uma série de eventos infelizes:
A alta cardinalidade leva a um aumento dramático no número de séries temporais que o Prometheus precisa armazenar, o que pode consumir rapidamente recursos de armazenamento. Claro, isso pode sair caro.
O desempenho da consulta pode sofrer significativamente em cenários de alta cardinalidade. O Prometheus precisa processar um número maior de séries temporais, o que pode retardar as respostas das consultas e aumentar o uso de CPU e memória.
Gerenciar e manter uma instância do Prometheus com alta cardinalidade torna-se mais desafiador. Requer ajustes mais cuidadosos e soluções de infraestrutura possivelmente mais sofisticadas.
Write Ahead Log ou WAL no Prometheus é um mecanismo usado para garantir a integridade dos dados e evitar a perda de dados em caso de falha ou desligamento inesperado. Sempre que o Prometheus registra novos dados, ele primeiro os grava no WAL, hospedado no sistema de arquivos do servidor onde o Prometheus está sendo executado, antes de serem gravados no banco de dados.
Essa abordagem significa que, se o Prometheus for reiniciado por qualquer motivo, ele poderá usar o WAL para recuperar quaisquer dados que ainda não tenham sido gravados no banco de dados. O WAL atua como um registro do que deveria estar no banco de dados, garantindo que nenhum dado seja perdido caso o sistema trave.
No entanto, um dos principais desafios do WAL é o tempo que leva para reproduzi-lo após uma falha ou reinicialização. Quando o Prometheus é reiniciado, ele precisa processar o WAL para reconstruir seu estado na memória. Esse processo pode ser demorado, principalmente se houver muitos dados no WAL.
Em termos práticos, isso significa que se o processo de reprodução do WAL demorar muito, o Prometheus poderá passar por um tempo de inatividade significativo, com monitoramento e alertas temporariamente indisponíveis – o que não é exatamente ideal para sistemas que dependem de monitoramento em tempo real.
Lidar com a escalabilidade no Prometheus, especialmente em ambientes dinâmicos e de grande escala, geralmente requer a adoção de estratégias e ferramentas adicionais. Embora o Prometheus seja um aplicativo monolítico, ele possui muitos recursos individuais, como coleta e armazenamento de métricas, retorno de métricas por meio de consultas, alertas e registros de avaliações e muito mais.
Se em uma configuração específica você depender muito de um único recurso do Prometheus, poderá ser forçado a ampliar todo o Prometheus, mesmo que na verdade precise dimensionar apenas uma parte dele. É aqui que entram em jogo configurações e ferramentas distribuídas como Thanos e Cortex.
Ambos ajudam a estender o Prometheus adicionando uma visualização de consulta global, oferecendo suporte nativo à API de consulta do Prometheus, fornecendo armazenamento eficiente e suporte a vários clusters. Eles também permitem o armazenamento de longo prazo de métricas do Prometheus em armazenamento de objetos (como AWS S3 ou Google Cloud Storage), tornando-o mais econômico e escalonável. No entanto, embora os componentes do Thanos e do Cortex possam ser dimensionados separadamente, resolvendo assim o problema de dimensionamento monolítico do Prometheus, todos os seus componentes adicionais requerem algum nível de conhecimento e esforço para mantê-los.
Resumindo, embora sejam extremamente úteis, tanto Thanos quanto Cortex introduzem componentes adicionais na arquitetura de monitoramento, o que aumenta a complexidade em termos de implantação, gerenciamento e solução de problemas.
Se você quiser usar o Prometheus sem encontrar esses problemas de armazenamento e escalabilidade, participe de nossa apresentação sobre o uso do Prometheus-Operator no Events Europe co-localizado organizado pela CNCF, bem como de nosso workshop prático alguns dias depois na KubeCon.
Você aprenderá como colher todos os frutos de Prometheus sem arriscar nada. Você também conhecerá a mim e ao meu colega Nicolas Takashi — somos engenheiros de plataforma da Coralogix — junto com nossos estimados co-apresentadores, Bartłomiej Płotka e Mahmoud Amin, engenheiros de software sênior do Google, e Jesus Vazquez da Grafana.
Vejo você lá!
Para saber mais sobre o Kubernetes e o ecossistema nativo da nuvem, junte-se a nós na KubeCon + CloudNativeCon Europe em Paris, de 19 a 22 de março.
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
