Quando um aplicativo é reescrito para usar microsserviços, o número de componentes e endpoints envolvidos em uma única transação de usuário aumenta. Portanto, a observabilidade é essencial para operar serviços do usuário de maneira confiável. Esta arquitetura de referência mostra como capturar informações de trace em aplicativos de microsserviço usando o OpenTelemetry e o Cloud Trace.
Este documento é destinado a desenvolvedores, SREs e engenheiros de DevOps que querem entender os fundamentos do rastreamento distribuído e que querem aplicar esses princípios aos serviços para melhorar a observabilidade do serviço.
.Arquitetura
O diagrama a seguir mostra a arquitetura de um aplicativo que implementa essa arquitetura.
Conforme ilustrado no diagrama anterior, essa arquitetura inclui dois clusters do GKE. Você implanta um aplicativo em cada um dos clusters. O tráfego do usuário é enviado para o aplicativo de front-end no cluster de front-end. O pod de front-end no cluster de front-end se comunica com o pod de back-end no cluster de back-end. O pod de back-end chama um endpoint de API externo.
Os dados de observação são exportados para o Cloud Trace, que rastreia como as solicitações se propagam pelos aplicativos.
Considerações sobre o design
Para serviços executados no Kubernetes, é possível usar uma malha de serviço como o Istio para ativar o rastreamento distribuído de serviços para tráfego de serviço sem a necessidade de instrumentação dedicada. No entanto, você pode ter qualquer um dos seguintes requisitos:
- Você quer ter mais controle sobre os traces do que o Istio oferece.
- Talvez seja necessário capturar os dados internos do aplicativo nas informações de rastreamento.
- Talvez seja necessário rastrear o código que não está em execução no Kubernetes.
Para esses casos de uso, você pode usarOpenTelemetry , que é uma biblioteca de código aberto que pode adicionar instrumentação a aplicativos de microsserviço distribuídos para coletar traces, métricas e registros em uma ampla variedade de linguagens, plataformas e ambientes.
Noções básicas sobre traces, períodos e contexto
O conceito de rastreamento distribuído é descrito no documento de pesquisa do Dapper (em inglês) publicado pelo Google. Conforme descrito no documento, o diagrama a seguir mostra cinco períodos em um trace.
Um trace é o total de informações que descrevem como um sistema distribuído responde a uma solicitação do usuário. Os traces são compostos por períodos, em que cada período representa uma solicitação e um par de resposta específicos envolvidos na disponibilização da solicitação do usuário. O período pai descreve a latência conforme observado pelo usuário final. Cada um dos períodos filhos descreve como um determinado serviço no sistema distribuído foi chamado e respondido, com informações de latência capturadas para cada um deles.
O diagrama mostra uma única solicitação de front-end que faz duas solicitações de back-end. A segunda chamada de back-end requer que duas chamadas auxiliares sejam concluídas. Cada chamada é identificada com o código do período e o código do período pai.
Um desafio com o rastreamento em sistemas distribuídos é que as informações sobre a solicitação de front-end original não são transportadas de forma automática ou herdada quando solicitações subsequentes são feitas para vários serviços de back-end.
Com algumas ferramentas (por exemplo, na linguagem Go), é possível fazer solicitações com contexto (o endereço IP e as credenciais do cluster). O OpenTelemetry estende o conceito de contexto para incluir contexto de período, o que significa que informações adicionais são carregadas no cabeçalho HTTP. As informações sobre o período pai podem ser incluídas em cada solicitação subsequente. Em seguida, é possível anexar períodos filhos para compor o rastreamento geral. Assim, é possível ver como a solicitação do usuário passou pelo sistema e, por fim, foi atendida novamente.
Implantação
Para implantar essa arquitetura, consulte Implantar o rastreamento distribuído para observar a latência do microsserviço.
A seguir
- Saiba mais sobre o OpenTelemetry.
- Saiba mais sobre os recursos de DevOps relacionados a essa arquitetura:
- Faça a verificação rápida de DevOps para entender sua posição em relação ao restante do setor.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.