Observabilidade em Sistemas Distribuídos

Publicado por O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

Capítulo 1. A Necessidade de Observabilidade

O software de infraestrutura está no meio de uma mudança de paradigma. Contêineres, orquestradores, arquiteturas de microsserviços, malhas de serviços, infraestrutura imutável e funções como serviço (também conhecidas como “sem servidor”) são ideias incrivelmente promissoras que mudam fundamentalmente a forma como o software é construído e operado. Como resultado destes avanços, os sistemas que estão a ser construídos de forma generalizada – em empresas grandes e pequenas – tornaram-se mais distribuídos e, no caso da conteinerização, mais efémeros.

Os sistemas estão sendo construídos com diferentes metas, requisitos e garantias de confiabilidade. Em breve, se ainda não, as falhas de rede e de hardware subjacentes serão abstraídas de forma robusta dos desenvolvedores de software. Isso deixa as equipes de desenvolvimento de software com a responsabilidade exclusiva de garantir que seus aplicativos sejam bons o suficiente para aproveitar o que há de melhor e mais recente em abstrações de rede e agendamento.

Em outras palavras, melhor resiliência e tolerância a falhas de componentes prontos para uso significa que – assumindo que esses componentes prontos para uso foram compreendidos e configurados corretamente – a maioria das falhas não tratadas pelas camadas de aplicação dentro da pilha de chamadas surgirão de interações complexas. entre diversas aplicações. A maioria das organizações está na fase inicial de adoção de tecnologias nativas da nuvem, e os modos de falha desses novos paradigmas ainda permanecem um tanto nebulosos e não amplamente divulgados. Para manobrar com sucesso neste admirável mundo novo, obter visibilidade do comportamento dos aplicativos torna-se mais urgente do que nunca para as equipes de desenvolvimento de software.

O monitoramento de antigamente pode ter sido uma responsabilidade dos engenheiros de operações, mas a observabilidade não é uma preocupação puramente operacional. Este é um livro de autoria de um engenheiro de software, e o público-alvo são principalmente outros desenvolvedores de software, não apenas engenheiros de operações ou engenheiros de confiabilidade de site (SREs). Este livro apresenta a ideia de observabilidade, explica como ela é diferente do monitoramento e alertas tradicionais centrados em operações e, o mais importante, por que é tão atual para desenvolvedores de software que criam sistemas distribuídos.

O que é observabilidade?

A observabilidade pode significar coisas diferentes para pessoas diferentes. Para alguns, trata-se de logs, métricas e rastreamentos. Para outros, é o velho vinho do monitoramento em garrafa nova. O objectivo global de várias escolas de pensamento sobre observabilidade, no entanto, permanece o mesmo – trazer melhor visibilidade aos sistemas.

A OBSERVABILIDADE NÃO SE TRATA APENAS DE LOGS, MÉTRICAS E RASTREIOS

Logs, métricas e rastreamentos são ferramentas úteis que ajudam a testar, compreender e depurar sistemas. No entanto, é importante observar que ter logs, métricas e rastreamentos não resulta em sistemas observáveis.

No seu sentido mais completo, observabilidade é uma propriedade de um sistema que foi projetado, construído, testado, implantado, operado, monitorado, mantido e evoluído em reconhecimento dos seguintes fatos:

Nenhum sistema complexo é totalmente saudável.
Os sistemas distribuídos são patologicamente imprevisíveis.
É impossível prever a miríade de estados de falha parcial em que várias partes do sistema podem acabar.
A falha precisa ser encarada em todas as fases, desde o projeto do sistema até a implementação, teste, implantação e, finalmente, operação.
A facilidade de depuração é a base para a manutenção e evolução de sistemas robustos.

AS MUITAS FACES DA OBSERVABILIDADE

O foco deste relatório está em logs, métricas e rastreamentos. No entanto, estes não são os únicos sinais de observabilidade. Rastreadores de exceção como o Sentry de código aberto podem ser inestimáveis, pois fornecem informações sobre variáveis locais de thread e rastreamentos de pilha de execução, além de agrupar e desduplicar erros ou exceções semelhantes na IU.

Perfis detalhados (como perfis de CPU ou perfis de contenção mutex) de um processo às vezes são necessários para depuração. Este relatório não cobre técnicas como SystemTap ou DTrace, que são de grande utilidade para depurar programas independentes em uma única máquina, uma vez que tais técnicas geralmente são insuficientes durante a depuração de sistemas distribuídos como um todo.

Também estão fora do escopo deste relatório as leis formais de modelagem de desempenho, como a lei de escalabilidade universal, a lei de Amdahl, ou conceitos da teoria das filas, como a lei de Little. Técnicas de instrumentação em nível de kernel, pontos de instrumentação inseridos pelo compilador em binários e assim por diante também estão fora do escopo deste relatório.

A observabilidade não é uma preocupação puramente operacional

Um sistema observável não é alcançado simplesmente com o monitoramento implementado, nem com uma equipe de SRE implantando-o e operando-o cuidadosamente.

A observabilidade é um recurso que precisa ser consagrado em um sistema no momento do projeto do sistema, de modo que:

Um sistema pode ser construído de uma forma que possa ser testado de maneira realista (o que envolve um certo grau de testes na produção).
Um sistema pode ser testado de forma que qualquer um dos modos de falha difíceis e acionáveis (do tipo que geralmente resulta em alertas depois que o sistema é implantado) possa surgir durante o teste.
Um sistema pode ser implantado de forma incremental e de forma que uma reversão (ou avanço) possa ser acionada se um conjunto chave de métricas se desviar da linha de base.
E, finalmente, após o lançamento, um sistema pode ser capaz de relatar pontos de dados suficientes sobre sua integridade e comportamento ao atender tráfego real, para que o sistema possa ser compreendido, depurado e evoluído.

Nenhuma dessas preocupações é ortogonal; todos eles seguem um ao outro. Como tal, a observabilidade não é uma preocupação puramente operacional.

Conclusão

Observabilidade não é o mesmo que monitoramento, mas isso significa que o monitoramento está morto? No próximo capítulo, discutiremos por que a observabilidade não elimina a necessidade de monitoramento, bem como algumas práticas recomendadas para monitoramento.