Esse blogpost emergiu com a necessidade que tive de juntar o que li sobre observabilidade. Adianto que não será uma abordagem muito profunda sobre o assunto, interessando, sugiro fortemente que leia as referências =)
Agradeço aqui também o Sr. André e meu caro Will por terem me ajudado com esse conteúdo <3. Vlw, pessoal!
Uma realidade em nossos sistemas e que as coisas irão falhar - pequenas alterações podem resultar em muitos resultados inesperados, incluindo interrupções e falhas globais que impactam todos os clientes. Essa é a realidade dos sistemas complexos.
O estudo Microsoft Operations Framework (MOF) de 2001 (veja como já tem tempo) descobriu que empresas de alto desempenho usavam uma abordagem disciplinada para resolver problemas, empregando telemetria em produção a fim de entender os possíveis fatores contribuintes para focar na solução do problema.
Já em 2015 no state of DevOps Report, tivemos uma “revelação”, neste relatório ficou claro que empresas de alto desempenho podiam resolver incidentes de produção muito mais rápido que seus pares tendo como prática o uso de controle de versão e telemetria junto com monitoramento proativo para conseguirem MTTR rápido
O que é Observabilidade?
Segundo a teoria de controle, a observabilidade é uma medida que descreve quão bem podem os estados de um sistema ser inferidos a partir do conhecimento de suas saídas externas1. A observabilidade e a controlabilidade são conceitos oriundos da matemática e da engenharia e tratam de criação e manutenção de sistemas.
Com microsserviços, a observabilidade pode ser difícil de alcançar devido à grande complexidade do contexto. Seja em data centers ou na nuvem, para atingir a excelência operacional e atender aos objetivos de negócios, você precisa entender e aprimorar o desempenho dos seus sistemas. As soluções de observabilidade permitem que você colete e analise dados de aplicativos e infraestruturas para que seja possível entender os seus estados internos e ser alertado, solucionar e resolver problemas com disponibilidade e performance de aplicativos para melhorar a experiência do usuário final.
Monitoramento == Observabilidade?
Há uma pequena, porém pertinente, diferença nas palavras monitorar que é um verbo, algo que você faz e observabilidade que é um substantivo, o atributo de um sistema, ou seja, podemos dizer que observabilidade de um sistema é a extensão como que podemos compreender o estado interno desse sistema a partir de suas saídas.
A monitoração, por outro lado, é algo que fazemos. Nós monitoramos o sistema. Nós observamos.
Pilares da observabilidade
Registros (logs)
Um log de evento é um registro imutável com carimbo de data/hora de eventos discretos que aconteceram ao longo do tempo. Os logs de eventos em geral vêm em 3 formas, mas são fundamentalmente os mesmos: um carimbo de data/hora e uma carga útil de algum contexto. As três 3 formas são: Texto, Estruturado e Binário.
Métricas
As métricas são uma representação numérica de dados medidos em intervalos de tempo. Como os números são otimizados para armazenamento, processamento, compactação e recuperação, as métricas permitem uma retenção de dados mais longa, bem como consultas mais fáceis. Isso torna as métricas perfeitamente adequadas para a construção de painéis que refletem tendências históricas.
Rastreamento (tracing)
Um rastreamento (trace ou tracing) é uma representação de uma série de eventos distribuídos, causalmente relacionados, que codificam o fluxo de requisição de ponta a ponta através de um sistema distribuído.
O que precisamos
Agregação de logs
Você deve encarar a implementação de uma ferramenta para agregação de logs como um pré requisito para implementar uma arquitetura de microsserviços
uma abordagem que pode ser útil é utilizar ids de correlação nos logs
Os logs são um modo fácil e incrível de obter informações de seus sistemas, porém, a medida que houver mais microsserviços e mais requisições, você acabará gerando muitos dados.
Agregação de métricas
Assim como o desafio de observar logs de diferentes lugares, precisamos encontrar maneiras melhores de coletar e visualizar dados de nossos sistemas.
Tracing distribuído
Basicamente, uma arquitetura de microsserviços é um conjunto de processos que atuam em colaboração para executar algum tipo de tarefa, então, faz sentido, quando queremos entender como nosso sistema realmente se comporta em um ambiente de produção, que sejamos capazes de ver os relacionamentos entre os nossos microsserviços. Aqui sugiro fortemente o estudo de OpenTelemetry (antigo OpenTracing).
SLAs e SLOs
SLA é um acordo entre as pessoas que criam o sistema e as pessoas que o utilizam.
Os slos definem o que a equipe se compromete a oferecer, logo, atingir o SLO é satisfazer os requisitos de um SLA, de forma simplista podemos pensar nos slos como o que uma equipe precisa fazer para que a empresa atinja seus slas. Você pode se aprofundar um pouco mais nesse assunto aqui.
Alertas
Alertas são problemas. Precisamos notificar alguém para que seja tomada alguma ação. O desafio em um ambiente de microsserviços é descobrir exatamente quais tipos de problemas devem fazer com que uma pessoa seja acordada às três da manhã. Você pode se aprofundar um pouco mais nesse assunto aqui.
Monitoração semântica
Na monitoração semântica definimos um modelo para a semântica aceitável em nosso sistema. Nosso objetivo não é apenas garantir que estamos gerando telemetria em torno da saúde do aplicativo, mas também medir até que ponto estamos atingindo nosso objetivo organizacional. Quais são as propriedades que o sistema deve ter para que achemos que ele está funcionando com médias aceitáveis? Em boa medida, a monitoração semântica exige uma mudança em nosso comportamento. Em vez de verificar a presença de erros, precisamos fazer constantemente a pergunta: o sistema está se comportando do modo como esperamos? Exemplos de perguntas que podem ajudar:
- Novos clientes podem se cadastrar?
- Estamos despachando pedidos a uma taxa considerada normal?
Um dos maiores desafios é chegar a um consenso acerca de como será esse modelo. Como podemos ver, não estamos falando de algo no baixo nível como "o uso de CPU não deve exceder 95%"; estamos fazendo afirmações de nível alto sobre o nosso sistema. É nessa hora que o dono do produto (product owner) deve entrar em cena - mas talvez seja sua tarefa como operador garantir que a discussão como o dono do produto realmente ocorra.
Possibilitar a criação de métricas como parte do trabalho diário
Você precisa que todos criem métricas facilmente. Para isso, devemos ter a infraestrutura e as bibliotecas necessárias para facilitar o máximo possível alguém de criar telemetria para qualquer funcionalidade. Ao gerar telemetria de produção como parte do trabalho diário, temos cada vez mais capacidade não apenas de ver o problemas quando ocorrem, mas também de projetar nosso trabalho, de modo que problemas em projetos e operações possam ser revelados com antecedência.
Conclusão
Conforme vimos, há muitos aspectos em que devemos pensar. É preciso garantir que será possível usar as informações para fazer perguntas sobre seu sistema. Você é capaz de dizer com confiança que o sistema está funcionando de modo adequado aos seus usuários? Com o tempo será necessário coletar mais informações e aprimorar as ferramentas para melhorar a observabilidade das aplicações.
Sistemas distribuídos podem ser complicados de entender e quando mais distribuídos forem, mais difícil será a tarefa de resolver os problemas que emergem por esta natureza. À medida que sua arquitetura de microsserviço se torna mais complexa, será mais difícil saber como anteceder os problemas que poderiam ocorrer. Desse modo será essencial mudar sua maneira de pensar, afastando-se das atividades que, em sua maior parte, são de monitoração, e avançar em direção a deixar o seu sistema mais observável.
Considere fortemente adotar SLOs e alertas com base nesses preceitos a fim de reduzir a fadiga de alertas e manter sua atenção com um foco apropriado. Assegure-se de investir em telemetria de nível empresarial, de aplicativo, de infra estrutura, de software cliente (frontend), de pipeline de implementação…
Acima de tudo, trata-se de aceitar que nem tudo será conhecido antes de o sistema chegar ao ambiente produtivo. Melhore sua capacidade de lidar com o desconhecido
Referências
[1] https://en.wikipedia.org/wiki/Observability
The Site Reliability Workbook (cap 2)
The DevOps Handbook (cap 14)
Building Microservices: Designing Fine-Grained Systems (cap 10)
Top comments (0)