BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Construindo sistemas distribuídos observáveis

Construindo sistemas distribuídos observáveis

Favoritos

Hoje em dia, os sistemas estão cada vez mais complexos, com microservices sendo distribuídos através da rede e escalando dinamicamente, resultando em várias maneiras de falhar, maneiras essas que nem sempre podemos prever. Acreditar que podemos construir o sistema perfeito pode levar a um falso senso de segurança, então precisamos estar preparados! Investir na capacidade de observar nossos sistemas nos dá a possibilidade de questioná-los sobre coisas que nunca pensamos antes. Algumas das ferramentas que podem ser usadas para isso são: métricas, rastreamento, logs estruturados e correlacionados.

Pierre Vincent, gerente de engenharia em disponibilidade de sites (SRE - Site Reliability Engineer) na Poppulo, falou sobre a construção de sistemas distribuídos observáveis no QCon Londres deste ano. O InfoQ cobriu essas conferência com Q/As, apresentações, resumos e artigos.

O InfoQ entrevistou Vincent sobre como aplicar a capacidade de observar nossos sistemas distribuídos.

InfoQ: Você mencionou na sua palestra que a implantação em produção é apenas o começo. Pode explicar melhor?

Pierre Vincent: Somos muito bons em tudo antes de implantar em produção, mas raramente melhoramos o que está acontecendo desde então. Quanto mais olho para isto, percebo que gastar todo nosso tempo em pré-produção não apenas tem pouco retorno mas também é quase contra-produtivo. Podemos vir a acreditar que construímos a coisa perfeita, mas no final das contas, os sistemas podem falhar e passa a ser difícil lidar com isso, especialmente quando temos que trabalhar em sistemas distribuídos.

Como desenvolvedor, senti isso de maneira inversa por um bom tempo: a produção era o último passo; depois de implantarmos um sistema em produção nossa tarefa acabava e era problema de outra pessoa, seguindo em frente para o desenvolvimento da próxima funcionalidade. Nos sentimos confortáveis em pensar que todas as coisas importantes que fazemos em pré-produção são o suficiente: TDD, teste de integração, pré-produção, ponta-a-ponta e assim por diante.

Hoje em dia, estamos lidando com sistemas muito mais complexos, distribuídos, que escalam dinamicamente, etc… Isso possibilita muito mais falhas que temos que pensar a respeito. Acreditar que os sistemas que construímos são perfeito nos dá um falso senso de segurança: quando as coisas dão errado, simplesmente não estamos preparados. E a má notícia é que as falhas serão muito mais difíceis de lidar porque não temos o que precisamos à nossa disposição para detectar o problema ou investigá-lo.

InfoQ: Como a capacidade de observar os sistemas pode nos preparar para problemas que ocorrem em produção?

Vincent: Investir na capacidade de observar sistemas significa estar preparado para gastar tempo em instrumentação, nos dando as ferramentas para lidar com coisas desconhecidas que ocorrem em produção.

Podemos usar maneiras diferentes para obter informações do ambiente de produção. Isto pode ser bem simples no início, como checagens básicas da saúde do ambiente. Existem muitas ferramentas que fazer coisas poderosas com métricas coletadas de tempos em tempos. Métricas, rastreamento, logs, correlações, logs estruturados, eventos; não existe uma solução para tudo, mas combinadas proporcionam algo realmente poderoso. Temos que admitir que as coisas podem dar errado, e quando dão errado, temos todas as coisas necessárias para detectar problemas, reagindo e recuperando os sistemas rapidamente.

InfoQ: Quais técnicas e práticas na observação de sistemas você recomenda?

Vincent: Pode ser tentador se contentar apenas com métricas e monitoramento, enquanto existem outras coisas que valem a pena dar uma olhada.

As métricas são muitos eficientes em agregar dados em dimensões de granularidade baixa, o que as tornam uma boa escolha para monitoramento a nível de serviços. No entanto, métricas não escalam muito bem em cardinalidade alta, o que é necessário para debugar e explorar. Tentamos usar o Prometheus para coletas cronológicas de alta cardinalidade e não deu muito certo.

Um bom sistema de logs, especialmente logs estruturados, tem um papel fundamental em aumentar nosso entendimento de como as aplicações se comportam. Por um bom sistema de logs, quero dizer a facilidade de realizar buscar e fornecer contexto suficiente para entender como os eventos ocorreram. Correlação entre os logs também é uma das primeiras coisas que devemos dar atenção, como por exemplo o id de uma requisição seguindo pelo sistema inteiro. Logs podem ser custosos, bibliotecas de logs frequentemente tem sobrecargas não triviais, pode ser desafiador gerenciar o volume de informações que geram, e amostras dos níveis de logs não são fáceis.

Tivemos experiências positivas com o Zipkin (Open Tracing) na nossa arquitetura; na verdade, usamos Trace Ids como nosso sistemas de logs correlacionadas, o que torna bem fácil mudar de logs para rastreamento. Dentro de poucas horas olhando o sistema de rastreamento, descobrimos algumas coisas que não fazíamos ideia de que estavam acontecendo. Infelizmente, o rastreamento distribuído tem um grande custo de instrumentação para sistemas existentes. Estamos utilizando há mais de um ano e ainda não instrumentamos tudo. Um conselho: se estiver começando agora, inicie com um sistema de rastreamento, será muito mais barato lá na frente.

Uma coisa que estamos analisando no momento são exceções de comunicação, em particular para erros de browser ocorridos no lado do cliente, por exemplo. Este era um ponto cego que tivemos e já faz um tempo que estamos verificando se ferramentas como o Sentry podem aumentar a visibilidade, especialmente para erros que impactam o cliente.

De um modo geral, deve ser gasto um tempo analisando cada uma das ferramentas nos que elas se propõem a fazer. Uma única ferramenta não irá funcionar; o desafio é encontrar um equilíbrio perfeito de maneira que uma complemente a outra.

InfoQ: Quais são os benefícios que a observação de sistemas pode trazer?

Vincent: O benefício imediato para nós foi a visibilidade. Quando começamos a utilizar o Prometheus há alguns anos atrás, nossa reação foi bem clara: como podíamos trabalhar sem saber dessas coisas? Dali em diante, foi um círculo vicioso, fazendo mais perguntas e aplicando mais instrumentação se não podíamos respondê-las.

Como disse antes, as coisas não vêm sem um preço - tivemos que revisar toda nossa estratégia quando as métricas não se encaixavam na nossa solução. Um exemplo é que começamos a confiar em logs estruturados para granularidade a nível de clientes (que tem uma alta cardinalidade), o que nos deu a habilidade de debugar numa base cliente-a-cliente.

InfoQ: O que esperar para o futuro com respeito à observação de sistemas?

Vincent: Melhorias em torno da facilidade de uso e experiência do desenvolvedor é o que realmente vem em mente. Se os sistemas são difíceis de instrumentar e as saídas não são fáceis de interpretar, esta é uma batalha perdida.

Se tivesse que apostar em uma coisa, acho que o sistema de logs irão ganhar muito mais atenção em breve. Mesmo que tenham seus limites no momento, existe muito potencial no sistema de logs estruturados: fornecer contextos mais detalhados e possibilitar um debug melhor.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT