BT

Início Notícias Observabilidade e microservices: por que precisamos de tracing e métricas eficazes

Observabilidade e microservices: por que precisamos de tracing e métricas eficazes

Favoritos

Recentemente, Ben Linders escreveu um artigo para o InfoQ sobre uma palestra que o Pierre Vincent, gerente de site reliability engineering (SRE) da Poppulo, apresentou sobre observabilidade e sistemas distribuídos. Ao longo de anos publicamos vários artigos sobre o tema da observabilidade, e particularmente na área de serverless e microservices. Há também uma série de projetos open source neste espaço para ajudar os desenvolvedores, incluindo Prometheus, OpenTracing, Envoy e, mais recentemente, o Kiali.

Em um artigo recente, Zach Jory, da Aspen Mesh, publicou mais algumas ideias sobre o assunto. Ele começa observando algo que várias outras pessoas falaram ao longo dos anos: que embora quebrar monólitos em microservices possa ser uma atividade necessária, não leva automaticamente a sistemas mais fáceis, e que algumas atividades podem se tornar ainda mais difíceis:

Uma área óbvia em que isso acrescenta complexidade é a comunicação entre serviços. Pode ser difícil alcançar a visibilidade da comunicação serviço-a-serviço, mas ela é fundamental para a construção de uma arquitetura otimizada e resiliente.

Jory afirma que, embora o monitoramento, que visa dar uma ideia da saúde geral de um sistema, tenha existido por muitos anos, o conceito de observabilidade, que visa fornecer dados sobre o comportamento dos sistemas, tornou-se cada vez mais importante para sistemas distribuídos na nuvem, como os comumente encontrados com os microservices.

A observabilidade diz respeito à exposição de dados e ao fácil acesso a informações, o que é crítico quando é necessário visualizar como as comunicações falham, não ocorrem como esperado, ou quando não deveriam ocorrer.

A maneira como os serviços interagem uns com os outros durante a execução precisa ser monitorada, gerenciada, e controlada. Isso começa com a capacidade de observação e a capacidade de entender o comportamento de sua arquitetura de microservices.

Jory acredita que o surgimento de tecnologias de service mesh, como o Istio, tornou a observabilidade o requisito número um para quem quer usar ou desenvolver com elas. (Embora sua empresa tenha uma implementação própria de service mesh, as razões que ele levanta são agnósticas para a implementação, então vale a pena entendê-las.)

Ele então discute os dois principais recursos de observabilidade que seriam fornecidos por um service mesh: começando com o tracing, para que se possa saber quais microservices estão envolvidos em quais transações:

O rastreamento (tracing) distribuído é ótimo para depurar e entender o comportamento da aplicação. A chave para entender todos os dados de rastreamento é a capacidade de correlacionar extensões de diferentes microservices relacionados a uma única solicitação de cliente. Para conseguir isso, todos os microservices da aplicação devem propagar os cabeçalhos de rastreamento.

E, depois, a métrica, com base nos dados de telemetria que podem ser reunidos automaticamente no service mesh. Métricas importantes a serem coletadas incluem o volume de solicitações, a duração da solicitação, a latência, e o tamanho da solicitação.

A maioria das falhas em microservices ocorre durante as interações entre serviços, portanto, uma visualização dessas transações ajuda as equipes a gerenciar melhor as arquiteturas para evitar falhas. A capacidade de observação proporcionada por um service mesh facilita muito a visualização do que está acontecendo quando os serviços interagem entre si, facilitando a criação de uma arquitetura de microservices mais eficiente, resiliente, e segura.

Curiosamente, o Jory aborda algo que discutimos no final de 2017 como uma previsão para 2018, de que o monitoramento e a observabilidade seriam um fator-chave para os desenvolvedores. Naquela época, o Péter Márton, CTO da RisingStack, fez a seguinte citação:

Para elevar o monitoramento e observabilidade de microservices a um próximo nível e trazer a era das próximas ferramentas de APM, é preciso um padrão de instrumentação aberto e livre de padrões de fornecedores, como o OpenTracing. Porém, esse novo padrão também precisa ser usado por fornecedores de APM, provedores de serviços, e mantenedores de bibliotecas de código aberto.

Avançamos oito meses e estamos definitivamente vendo a ascensão de projetos preocupados em tornar a observabilidade uma parte fundamental das arquiteturas de microservices, baseado ou não nas tecnologias de service mesh. Também estamos vendo esforços concentrados no desenvolvedor, como o Eclipse MicroProfile, adicionando suporte ao OpenTracing.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

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

Comentários da comunidade

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

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.