BT

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

| por Mark Little Seguir 12 Seguidores , traduzido por Andrea Mussap Seguir 7 Seguidores em 05 jul 2018. Tempo estimado de leitura: 3 minutos |

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.

Dê sua opinião

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

Receber mensagens dessa discussão
Comentários da comunidade

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

Receber mensagens dessa discussão

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

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT