Problema
Gerenciar clusters Kubernetes não é uma tarefa fácil. A tarefa de um administrador Kubernetes vai além de fazer o setup do cluster e instalar aplicações. É necessário todo um processo e ferramental para monitorar e observar o estado do cluster e das aplicações residentes nele.
Pensando nesse ponto, decidi escrever uma postagem comentando um pouco dos desafios que temos encontrado e as soluções que aplicamos. A diferença é que vamos sair um pouco do comum, que normalmente é utilizar uma stack em volta do Prometheus. Na verdade, o pontapé inicial da solução abordada nessa postagem nasce da utilização do Prometheus.
Tive experiências passadas utilizando Prometheus para monitorar as métricas do cluster, das máquinas e das aplicações executando no cluster. Mas o foco é na palavra métricas. Embora o Prometheus seja uma ferramenta muito robusta, ela foca em coletar apenas métricas, deixando de lado logs e traces. Há stacks opensource no mercado que já são focadas em resolver esses pontos, como por exemplo, a LGTM do Grafana ou ELK do Elasticsearch. Você pode simplesmente unir o Prometheus com todas essas outras e você terá uma stack completa.
O problema que vejo nessa solução é que você terá muitas ferramentas para gerenciar, e quanto mais ferramentas para gerenciar, mais pontos de falhas você pode ter. E pensando nesse ponto, utilizamos uma ferramenta que centraliza todas essas funcionalidades em um componente só — OpenTelemetry a.k.a Otel.
Solução
High-quality, ubiquitous, and portable telemetry to enable effective observability
Em poucas palavras, OpenTelemetry permite coletar métricas, logs e traces. Tudo em um só componente, não necessitando gerenciar outras ferramentas. E como o foco dele é apenas telemetria, ele não tem um componente visual para criar dashboards. E para isso, utilizamos o SigNoz. Uma ferramenta análoga ao Grafana com um bônus — APM embutido e totalmente compatível com o OpenTelemetry, onde o backend storage dele é o ClickHouse, que também é uma ferramenta muito robusta e presente na comunidade opensource.
Até o momento, estamos falando de apenas duas ferramentas (ou três)
- OpenTelemetry: o cara que age como coletor, podendo coletar logs, métricas e traces de nodes, containers e aplicações
- SigNoz: o frontend para você gerenciar os dashboards e visualizar toda a telemetria coletada
- ClickHouse: banco de dados OLAP de baixa latência e distribuído
E se eu te dissesse que o SigNoz já tem um Helm Chart pronto integrando todas essas ferramentas, para facilitar ainda mais você testar essa stack. Pois é… já cuidaram disso para a gente e aqui você pode consultar o chart.
Com esse chart você terá um daemonset do Otel agindo como agent, coletando métricas e logs de todos os pods e nodes. E para coletar traces, você precisa fazer a instrumentação das aplicações. Embora já tenha um Operator para fazer a auto-instrumentação, preferimos instalar manualmente o SDK nas aplicações e definir algumas variáveis de ambiente como OTEL_SERVICE_NAME e o endpoint para onde enviar os traces. Apenas isso!!!
Embora fazer o setup de métricas customizadas no Otel seja um pouco chato — isso porque ele não faz scraping de métricas, e sim o contrário, onde você tem que mudar sua aplicação para enviar métricas para ele. Para isso, subimos o PodMonitoring e ServiceMonitoring do Prometheus para fazer scraping dessas métricas. MAS CALMA!!! Você não precisa subir o servidor do Prometheus, apenas o CRD desses dois recursos. Também precisamos subir o Grafana Alloy pra fazer service discovery dos Pod e Service monitoring e enviar as métricas para o Otel. MATENHA A CALMA!!! No final vou falar como podemos eliminar esse cara.
Se você roda toda sua infraestrutura em nuvém, como por exemplo, usando a AWS. Você também pode precisar coletar métricas e logs do Cloudwatch e enviar para o Otel. Com a arquitetura de receivers do Otel, você pode simplesmente utilizar o receiver do Cloudwatch para coletar esses dados sem nenhum intermediário. MAS TOME CUIDADO!!! O pricing da AWS para coletar essas métricas em lote é relativamente alto. Então adicionei alguns pontos extras para minimizar o custo:
- Utilizamos o Cloudwatch streams para enviar as métricas para o Kinesis com o DirectPUT
- Com os dados no Kinesis Firehose, usamos o Data Delivery Streams para encaminhar essas métricas para o meu coletor do OpenTelemetry
- No coletor do Otel, fizemos o setup do Aws Firehose Receiver
Desse modo, todas as métricas de Lambdas, Load balancers, Opensearch, MQ, Elasticache e vários outros serviços, estão tudo centralizadas no SigNoz através do Otel.
Indo um pouco além, implementamos algumas outras ferramentas para nos ajudar a monitorar todo o ambiente
- Fizemos o setup do Alert Manager no SigNoz, e quando limites são atingidos, alertas/notificações são enviadas para o Slack
- Também fizemos o setup do Uptime Kuma — outra ferramenta opensource utilizada a grosso modo para validar a saúde das aplicações, onde você pode configurar rotas HTTP, portas TCP/UDP e outros modos para fazer polling e notificar o Slack em casos de aplicação não estar de pé
Conclusão
Se você chegou até aqui, pode ter percebido que fomos muito mais além de apenas coletar métricas, logs e traces. Fizemos não apenas isso, mas enviamos todos esses dados para apenas um cara (OpenTelemetry) e visualizamos tudo isso em apenas um lugar (SigNoz). Não só coletamos telemetria do nosso cluster Kubernetes, mas também de serviços que executam além dele, como por exemplo, em serviços da AWS.
Além de monitorar, também falamos de notificar em certos cenários, utilizando o AlertManager e o Uptime Kuma. Então SIM! Ainda não é apenas uma ferramenta para gerenciar, mas estamos muito bem servidos com várias ferramentas open source, onde num cenário enterprise, facilmente estaríamos optando pelo NewRelic ou DataDog, que são serviços extremamente caros e muita das vezes não utilizamos 100% da capacidade deles.
O cenário em que utilizamos essa stack, estamos rodando em uma arquitetura com 4 cluster Kubernetes, cada um com no mínimo 30 máquinas em ação, e no total mais de 600 aplicações executando. Fazemos a gestão do cluster ClickHouse também, que executa com 3 shards e 1 réplica cada shard. Você pode utilizar o clickhouse-backup para te ajudar no processo de gestão.
Podemos eliminar totalmente o Grafana Alloy pelo OpenTelemetry Target Allocator onde ele mesmo pode fazer o discovery dos CRDs do Prometheus e por si só, fazer scrape das métricas personalizadas servidas pelas aplicações. No momento que escrevo essa postagem, ainda não consegui implementar o Target Allocator sem utilizar o OpenTelemetry Operator, mas estamos perto de conseguir.
Um ponto que gostaria de chamar a atenção é que no momento em que escrevo essa postagem, utilizo o SigNoz versão 0.53.0 e OpenTelemetry 0.108.0. E nessas versões dessas ferramentas, ainda sintimos carência do suporte robusto ao SDK para aplicações mobile. O mundo perfeito seria se pudéssemos ter a telemetria das aplicações, sendo elas webserver ou mobile, em um lugar só. Mas sentimos que estas ferramentas OPEN SOURCE nos servem muito bem e continuam melhorando a cada tempo que passa.
Se você tem experiências semelhantes ou dúvidas, fique à vontade para me procurar ou fazer comentários!
#portugues #brasil
Top comments (0)