OpenTelemetry é um conjunto de ferramentas, APIs e bibliotecas de código aberto projetadas para fornecer observabilidade em sistemas de software distribuídos. Ele permite a coleta, geração e exportação de dados de telemetria, como traces, metrics e logs, que ajudam a monitorar o desempenho, diagnosticar problemas e entender o comportamento de aplicações em tempo real.
Para facilitar nosso entendimento, sobre os principais componentes eu resumi da seguinte forma:
- Métricas, dados pontuais do sistema ou aplicação;
- Logs, dados mais granulares e/ou personalizados, do sistema ou aplicação;
- Traces, uma visão fim a fim do eco-sistema da aplicação.
Todos esses dados por si só ajudam a "monitorar" mas não dizem muito a respeito do que pode estar de fato acontecendo com a minha aplicação. Isso depende de como você visualiza as informações, e precisamos ter ferramentas de visualização para olharmos para esses dados, e transforma-los em informação.
Vamos considerar aqui didaticamente falando um cenário de CPU 80%, é um dado. Número de usuários acessando o site simultaneamente, 400, é um dado.
Olhando para um gráfico que relate o número de usuários atuais, 400, "vs" a mesma informação só que de uma hora atrás, 350, podemos entender se nossa aplicação está funcionando adequadamente, ou não.
Pegando outro exemplo, considerar o tempo de carregamento da página, 4 segundos, ou o tempo de execução de uma requisição de banco de dados, 1 segundo. E comprar essas informações com períodos anteriores são extremamente produtivos para que na consolidação e co-relação de todos esses dados conseguimos extrair a informação de:
- Apesar da CPU em 80% a minha aplicação esta funcionando de maneira adequada ou não (caso 400 usuários seja muito pouco, caso 4 segundos para o carregamento da paginas seja muito tempo).
Esse conjunto de dados relacionados, transformados em informação, são extremamente poderosos em ambientes de nuvem pública. Se elevarmos essa visão para o prisma de FinOps, podemos entender que talvez neste caso não precisaremos subir mais um servidor web/app somente porque CPU está em 80%. Neste nosso exemplo podemos entender que apensar do valor de 80% na métrica de CPU não temos um impacto no funcionamento da aplicação e portanto não há impacto no negocio como um todo.
Como não há uma degradação da performance e da experiencia do usuário no uso de nossa aplicação, eu não preciso considerar uma configuração da política de auto scaling para o lançamento de uma nova EC2 somente porque a CPU está em 80%. Fazendo assim um uso mais adequado dos meus recursos de nuvem pública.
Veja que tanto a observabilidade quanto FinOps dependem do aumento de maturidade da gestão do ambiente em nuvem pública e que podemos conviver com dados de métricas mais próximos do limite de maneira consciente, tomando uma decisão embasada em dados e de maneira colaborativa.
Desenvolver a prática de observabilidade pode ser muito importante não somente para a monitoração mais adequada e assertiva das aplicações e do negócio, mas também para auxiliar na gestão financeira dos recursos de nuvem pública utilizados pelo negócio.
PS. as vezes esse tempo extra que utilizaríamos para realizar a configuração da "nossa" ferramenta de observabilidade pode ser melhor investido apenas no planejamento de como iremos utiliza-lá, se abrirmos mão de "montar" o nosso ambiente de monitoração e usarmos os serviços nativos gerenciados ou as ferramentas de monitoração SaaS.
Eu sou um ferrenho defensor de usar menos tempos em atividades de suporte não ligadas ao negócio e sermos mais produtivo com o uso de ferramentas mais adequadas e otimizadas.
As vezes os custos intangíveis são maior que os tangíveis.
