Conceitos de Observabilidade que voce precisa saber
Decidi criar este artigo porque Observabilidade (ou o11y, para abreviar) é um dos tópicos de TI mais críticos que vieram junto com o Google SRE (Site Reliability Engineering). Não encontrei um artigo que reunisse alguns conceitos cruciais para ajudar todos a entender e trabalhar em projetos de Observabilidade.
Tópicos que abordarei aqui:
· Monitoração Versus Observabilidade
· Os principais problemas resolvidos pela Observabilidade
· Benefícios da Observabilidade
· Os Três Pilares da Observabilidade
· SRE Golden Signals
· Como Utilizar os Golden Signals para Encontrar Gargalos na Performance
· Tipos de Monitoração de Aplicação, Sintética, Monitoração de Performance de Aplicação (APM) e Monitoração de Usuário Real (RUM)
· Traces Distribuídos
· API e SDK conceitos e comparação
· OpenTelemetry
Monitoração versus Observabilidade
Se você precisa de mais detalhes sobre as diferenças, dê uma olhada neste outro artigo (em inglês):
A seguir explicarei a definição geral de observabilidade e monitoração:
Observabilidade é a capacidade de entender o estado interno de um sistema analisando os dados que ele gera, como logs, métricas e rastreamentos. Ele ajuda as equipes a analisarem o que está acontecendo dentro de um contexto em ambientes multi-cloud para que você possa detectar e resolver as causas relacionados a esses problemas.
Monitoração é o processo de coletar, analisar e usar as informações para acompanhar o progresso de um programa para alcançar seus objetivos e orientar as decisões de gerenciamento. O Monitoração se concentra em observar métricas específicas. O registro fornece dados adicionais, mas geralmente é visto isoladamente fora de um contexto.
Observabilidade e Monitoração se complementam, cada um servindo a um propósito diferente.
O Monitoração informa quando algo está errado, enquanto a observabilidade permite que você entenda o porquê e os relacionamentos entre os componentes. A Monitoração é um subconjunto e uma parte essencial para a observabilidade.
Observabilidade Contextualiza a Monitoração
A observabilidade tem três pilares principais: métricas, logs e Traces. Métricas e logs têm sido tradicionalmente usados para monitorar sistemas de software. O Trace é uma funcionalidade "nova", mas essencial para se ter observabilidade.
Logs são eventos imutáveis que ocorrem ao longo do tempo.
Com certeza, os logs são uma ótima maneira de solucionar problemas. Os logs nos ajudam a ter visibilidade de todos os problemas que ocorrem e seu tempo de ocorrência. Mas em aplicativos de microsserviços, fica difícil entender e correlacionar logs de diferentes hosts.
Mesmo se você estiver usando uma ferramenta especializada para analisar os logs para você, essas ferramentas não podem associar os logs a um contexto sem os Traces; qual a ordem de cada transação que gerou esse log? O Trace nos ajuda a correlacionar eventos com spans pai e filho. Se os logs forem integrados com IDs de Trace, você poderá obter insights contextuais mais rapidamente, o que facilita a solução de problemas.
Métricas são uma representação numérica de dados medidos em intervalos de tempo.
Com as métricas, podemos ver a utilização da CPU, uso da memória, armazenamento, rede e assim por diante, que podem ser usados para determinar por exemplo a saturação da infraestrutura. Também pode ajudar a monitorar o desempenho e melhorar o planejamento de capacidade. Mas, da mesma forma que os logs, em uma configuração distribuída como a arquitetura de microsserviços, é um desafio identificar a causa raiz dos problemas se as métricas mostrarem um pico sem estarem dentro de um contexto.
Quando as métricas são associadas aos traces, podemos entender facilmente que uma query recebida por um serviço específico está causando uma alta utilização da CPU, por exemplo quando essa query é de baixa performance, permitindo depurar os problemas de maneira eficiente.
Da mesma forma que Logs e métricas, quando combinados com rastreamentos, trazem insights contextuais que ajudam a encontrar a raiz de um determinado problema.
Os Principais Problemas Resolvidos pela Observabilidade
- Applicações Cloud-Native e Microservices estão em constante mudança e dependem de tecnologias complexas; qualquer alteração tem o potencial de derrubar todo um sistema, pois temos serviços e componentes hospedados em diferentes ambientes de host.
- Um único problema pode gerar vários incidentes para equipes diferentes, dificultando a determinação da causa raiz do problema
- A disponibilidade do aplicativo pode fazer ou quebrar o negócio.
- Os desenvolvedores implantam o código com mais frequência, dificultando a compreensão do que está acontecendo no desempenho.
- Aplicativos e infraestrutura são altamente interdependentes em todos os níveis.
Beneficios da Observabilidade
Reduza o esforço operacional fornecendo:
- Uma maneira fácil de identificar dependências
- AAutomação com detalhes RCA quando necessário
- Diagnósticos automáticos e RCA através de inteligência artificial (IA)
- Diagnósticos automáticos e RCA através de inteligência artificial (IA)
Melhore a experiência do cliente, fornecendo:
- Resolvendo problemas críticos de negócios mais rapidamente
- Fornecendo aplicativos melhores analisando seu desempenho
- Suportando a necessidade de implementar novas funcionalidades e encontrar problemas em tempo real
- Identificando e corrigindo problemas de desempenho antes que a experiência do usuário seja afetada
Melhorar a visibilidade do negócio atrav'es:
- Informações centralizadas sobre dependências de aplicativos
- Informações centralizadas para painéis e relatórios
- Identificar e quantificar problemas com alto impacto nos negócios.
Os Três Pilares da Observabilidade
SRE Golden Signals
Um ótimo lugar para começar a implantar uma solução de Observabilidade é implementando os Golden Signals do Google:
- Latência —o tempo que leva para atender uma solicitação ou a métrica, formalmente conhecida como tempo de resposta.
- Trafego — Quantidade de solicitacoes a uma aplicação
- Erros — Taxa de erro das transações
- Saturação — Quão ocupado o sistema está.
Review the Google SRE book for more.
Como Utilizar os Golden Signals para Encontrar Gargalos na Performance
Com os Golden Signals, podemos avaliar o desempenho dos aplicativos e identificar a causa raiz dos problemas; essa é a abordagem que a maioria das soluções de monitoração de aplicação (APM) usa para encontrar a causa raiz.
Aqui você pode ver três exemplos de como os Golden Signals juntos podem facilmente mostrar o gargalo:
Tipos de Monitoracao de Aplicação
- Monitoracao Sintetica (Transacoes Artificiais)
- Monitoracao de Performance de Aplicacao (APM)
- Monitoracao da Experiencia de Usuario
Monitoração Sintética: Esta técnica de monitoramento emula gravações com script de transações artificiais (sintéticas). Os scripts são criados para simular o comportamento do usuário em uma aplicação web navegando pelo site e geralmente escolhendo um local onde a simulação poderá mostrar o desempenho rodando em diferentes sites. Ele pode ser usado para testar apenas alguma função de um site, por exemplo, o login ou o processo, já que o login passa por outras funções do site. É útil detectar problemas antes do acesso real do usuário. Também é benéfico em um ambiente de pré-produção para testar novas funcionalidades.
Monitoração de Usuario Real (RUM): O monitoramento de usuários reais é uma técnica de monitoramento passivo que analisará todas as iterações do usuário em um site e coletará informações sobre as seções e o desempenho do usuário, coletando, por exemplo, quais navegadores os usuários estão usando e o local em que estão acessando o aplicativo. Por se tratar de acesso real, vai considerar a conectividade do usuário (wi-fi, 4G, 5G). Um problema detectado aqui já impacta o usuário; no sintético, podemos ver os impactos reais antes que o usuário seja afetado, mas não consideramos as particularidades do usuário.
Monitoração de Performance de Aplicação(APM): fornecerá monitoramento no nível do aplicativo onde podemos ver o desempenho (Golden Signals) de cada transação, tudo na perspectiva do backend, por exemplo, uma consulta para encontrar um livro. No entanto, o APM não considerará a experiência do usuário final, por exemplo, sua rede, localização etc.
Cenário para explicar as diferenças entre APM, Sintético e RUM:
Também criei uma analogia para ajudar quem precisa explicar para uma equipe não técnica:
Traces Distribuidos
O trace é uma técnica que conecta todas as transações entre vários serviços, possibilitando o rastreamento de ponta a ponta. Um trace é o processamento completo de uma solicitação, desde uma solicitação inicial passando por todas as subatividades necessárias (span) até o final da transação.
Por exemplo, um processo de pagamento é um trace; toda a transação de pagamento precisa executar alguns Spans para concluir o pagamento, por exemplo, entrar em contato com um fornecedor de cartão de crédito, atualizar o banco de dados e retornar o resultado ao usuário.
Como o Trace acontece:
1 — Uma solicitação chegou ao aplicativo e um ID de Trace é criado
2 — O processo de pagamento recebeu a solicitação, processa as informações e enviará o trace ID para todas as atividades downstream (spans) e associará tudo ao mesmo Trace.
3 — Assim que cada span é concluído, um timestamp de início e término é criado e será incluído na linha do tempo do Trace, finalizando todo o rastreamento.
Como você pode ver na explicação do Trace, um span representa uma unidade de trabalho, rastreando solicitações específicas. Um trace é composto por vários spans, e cada span é capaz de mostrar os detalhes de sua execução.
Atributos de um span da aplicação Robot Shop usando a ferramenta Instana:
Duas formas de representação dos traces
API and SDK concept and comparison
Por que preciso conhecer API e SDK para minha Jornada de Observabilidade? A resposta é fácil; é porque SDK e APIs são os mecanismos usados pelas ferramentas de observabilidade para instrumentar as aplicações.
O que é API (interface de programação de aplicativos)?
API é uma interface criada para um aplicativo para permitir que entidades externas se comuniquem com esse aplicativo com uma camada de abstração e usando padronização para facilitar a interação dessas entidades externas com o aplicativo. Assim, a API permitirá que as soluções de Observabilidade extraiam informações das aplicações.
O que é SDK (Software Development Kit)
SDK é um conjunto de ferramentas utilizadas para facilitar e padronizar o desenvolvimento de software, de forma que os desenvolvedores não precisem criar aplicações do zero; eles podem reutilizar as ferramentas fornecidas por esses kits.
Assim, o SDK é um kit completo de ferramentas, e as APIs fazem parte desse kit, criando uma interface com a qual entidades externas podem se comunicar.
A ferramenta de Observabilidade pode ter seu SDK que os desenvolvedores podem usar para instrumentar e publicar as APIs dessa aplicação e permitir que as aplicações enviem dados para os back-ends de Observabilidade.
O vídeo a seguir explica a diferença entre API e SDK:
OpenTelemetry
OpenTelemetry é um projeto de código aberto da CNCF (Cloud Native Computing Foundation) com o objetivo de criar uma maneira padrão neutra de fornecedor para coletar dados de telemetria para aplicativos, infraestrutura e serviços.
OpenTelemetry no final é uma coleção de ferramentas, APIs e SDKs usados para gerar dados de telemetria para back-ends de observabilidade.
Porque eu preciso aprender isso?
A primeira razão é que, ao aprender como o Otel funciona, você pode aprender como funciona a Observabilidade, como ocorre a coleta de dados, como o rastreamento é criado e assim por diante.
A segunda razão é que o Otel está se tornando um padrão para todas as ferramentas de observabilidade e todos os fornecedores devem ser compatíveis com o Otel. Mas por que os fornecedores estão investindo nisso? Como a Otel não oferece back-end, análises, IA e muitos outros recursos, a coleta de dados em si não é o principal mercado dos fornecedores de observabilidade.
Você pode consultar mais detalhes aqui: https://opentelemetry.io/docs/concepts/
Como os dados são coletados usando o Otel?
Referência: https://opentelemetry.io/docs/concepts/instrumenting/
Coletor: O Coletor do OpenTelemetry é um proxy independente de fornecedor que pode receber, processar e exportar dados de telemetria. Ele oferece suporte ao recebimento de dados de telemetria em vários formatos e ao envio de dados para um ou mais back-ends.
Instrumentação Automática: Para usar a auto-instrumentação, o desenvolvedor deve satisfazer algumas dependências que variam de acordo com a linguagem de programação. Assim que essas dependências forem instaladas, os desenvolvedores devem configurar alguns detalhes para deixar a instrumentação pronta, por exemplo, informar o receptor de back-end.
Instrumentação Manual: Para instrumentar uma aplicação manualmente, o desenvolvedor deve instalar a API Otel e o SDK Otel, devendo definir no código como coletar e enviar informações para o backend do Observability, exigindo mais esforço para que a instrumentação aconteça.
Alguns exemplos de como instrumentar uma aplicação:
https://open-telemetry.github.io/opentelemetry-python/getting-started.html
É isso, pessoal; acredito que esse material poderá ajudá-lo a aprender sobre alguns conceitos importantes de Observabilidade. :)
Tiago Dias Generoso is a Distinguished IT Architect | Senior SRE | Master Inventor localizado em Pocos de Caldas, Brasil. O artigo acima é pessoal e nao necessariamente representa a posição do empregador.
