Logs, Trace distribuído em microsserviços usando .NET / C# e Devprime
11 de julho de 2023Uma das áreas críticas no desenvolvimento de microsserviços é a observabilidade das aplicações, que inclui logs distribuídos, rastreamento de transações (trace) e métricas. Tradicionalmente, essa observabilidade exigia implementações específicas em cada aplicação, o que representava um desafio significativo para os desenvolvedores antes da plataforma Devprime.
A plataforma Devprime é um poderoso acelerador no desenvolvimento de microsserviços, oferecendo uma ampla gama de recursos para aumentar a produtividade dos desenvolvedores. Uma das principais vantagens dessa plataforma é a capacidade de desenvolver rapidamente o primeiro microsserviço nativo em nuvem em apenas 30 minutos, graças a uma estratégia inteligente de arquitetura de software e implementação automática de código.
A Devprime resolve o desafio da observabilidade ao oferecer um recurso inteligente no adaptador de Observability que habilita a geração automática de logs distribuídos, utilizando estratégias de correlação para capturar e indexar logs dentro do cluster. Isso facilita a recuperação e análise posterior desses logs em ferramentas amplamente utilizadas, como o ELK (Elasticsearch, Logstash e Kibana).
Além disso, a Devprime também oferece a implementação automática do protocolo OpenTelemetry, permitindo a exposição de rastreamento distribuído. Esses dados de trace podem ser consumidos por várias ferramentas do mercado, como Zipkin, Jaeger e outras ferramentas de gerenciamento de desempenho de aplicativos (APM).
Com esses recursos disponíveis na plataforma Devprime, os desenvolvedores podem se concentrar no desenvolvimento do núcleo de seus microsserviços, enquanto as tarefas de observabilidade são tratadas automaticamente. Isso resulta em maior produtividade, menor tempo de desenvolvimento e uma arquitetura de microsserviços mais robusta e confiável.
Primeiros passos
Chegou o momento tão esperado de colocar em prática o uso do Distributed Log e Distributed Trace em cenários de sistemas distribuídos. No primeiro artigo desta série, demonstramos a criação do primeiro microsserviço, e agora iremos utilizar dois projetos já implementados para facilitar a compreensão do contexto de observabilidade fornecido pela plataforma Devprime.
Para realizar essa demonstração, é necessário configurar o Docker local com os containers do MongoDB, RabbitMQ, SEQ e Jaeger, seguindo os passos disponíveis na documentação da Devprime. É importante lembrar que é preciso ativar uma Exchange “devprime” e as filas “orderevents” e “paymentevents” no RabbitMQ.
Preparando o ambiente
– Instale o .NET 7.0 ou uma versão superior.
– Instale o Visual Studio Code. – Instale e ative Devprime CLI.
Obtendo o código de exemplo
Nesse exemplo nós utilizaremos o microsserviço “Order” e o microserviço “Payment” que podem ser obtidos diretamente do github da Devprime ou implementados manualmente seguindo a documentação da Devprime.
1) Efetue o clone do projeto
git clone https://github.com/devprime/devprime-microservices-order-payment
2) Atualize o Stack e licença de uso pelo Devprime CLI.
Entre na pasta clonada e digite “dp stack”
Executando os microsserviços “Order” e “Payment”
Agora que você já tem os microsserviços disponíveis e atualizados certifique-se que executou as configurações iniciais do Docker no inicio do artigo e entre em cada uma das pastas para executar cada microsserviço em uma aba do prompt de comando.
a) Order (ms-order)
.\run.ps1 ou ./run.sh (Linux, macOS)
b) Payment (ms-payment)
.\run.ps1 ou ./run.sh (Linux, macOS)
Após ter os dois microsserviços rodando ao mesmo tempo é possível acessar a url do primeiro https://localhost:5001 e efetuar um post na API preenchendo os dados do pedido que será processado no primeiro serviço e depois propagando para o segundo microsserviço.
Ativando as configurações de Observability
Agora chegou o momento de habilitar a captura de logs no ambiente local, onde utilizaremos a ferramenta SEQ, citada no início do artigo. Você também pode optar por utilizar, por exemplo, o ELK (Elasticsearch, Kibana, Beats e Logstash). Para a leitura do Distributed Trace, utilizaremos o Zipkin, que é compatível com o protocolo Open Telemetry.
No ambiente local, as configurações são realizadas no arquivo src/App/appsettings.json, disponível em cada projeto. No nosso exemplo, temos os projetos “ms-order” e “ms-payment”. No ambiente produtivo, esses parâmetros são configurados por meio de um cofre de segurança que compartilha as informações.
Utilize o Visual Studio Code para editar os arquivos em cada uma das pastas usando o seguinte comando:
code src/App/appsettings.json
Ao abrir as configurações de cada arquivo, localize a chave DevPrime_Observability e, na raiz, verifique se o parâmetro Enable está como true. Em seguida, na seção Logs, confirme se o Enable também está como true e se as opções ShowAppName e HideDateTime estão definidas como true. O ShowAppName mostra o nome do microsserviço e o HideDateTime oculta a exibição da data e hora, pois a ferramenta SEQ já possui essa informação.
Em seguida, vá para a opção export e verifique se o Enable está como true e o padrão está definido como “SEQ”. Depois, localize a seção Trace e certifique-se de que o Enable e o type estão definidos como “zipkin”.
“DevPrime_Observability”: {
“Enable”: “true”,
“Log”: {
“Enable”: “true”,
“Save”: “false”,
“Type”: “text”,
“FileSize”: “5242880”,
“HideDetails”: “false”,
“HideDateTime”: “true”,
“ShowAppName”: “true”,
“Path”: “”,
“ShowHttpErrors”: “400”,
“Export”: {
“Enable”: “true”,
“Type”: “seq”,
“Host”: “http://localhost:5341”,
“ApiKey”: “your api key”,
“ControlLevelSwitch”: “Information”
}
},
“Metrics”: {
“Enable”: “false”
},
“Trace”: {
“Enable”: “true”,
“Type”: “zipkin”,
“Endpoint”: “http://localhost:9411/api/v2/spans”
}
},
Visualizando o Distribuited Log no SEQ
Nós concluímos a configuração dos microsserviços e agora basta acessar a URL do microsserviço de Order em https://localhost:5001 e efetuar um post para observar o comportamento de log automático disponibilizado pela Devprime e nesse contexto visível pelo Seq na url local http://localhost:8000.
É importante ressaltar que além de gerar os logs automaticamente e padronizados em todas as aplicações a plataforma Devprime utiliza uma estratégia de Trace ID e Correletion ID permitindo o relacionamento entre os logs mesmo quando executado em microsserviços diferentes conforme o exemplo apresentado anteriormente com a visualização do ms-order e ms-payment.
Agora repita o processo efetuando um novo post na api Order e dessa vez remova toda a linha do campo “customerName e faça um novo post.
Nesse cenário por falta o campo obrigatório uma regra de negócio de negócio registrou um erro que estourou no resultado da API como um identificador automático do trace que permite a equipe interna localizar exatamente qual foi o programa nesse procedimento.
É importante ressaltar que mesmo com o erro nenhuma informação adicional foi devolvida a API e isso é um recurso interno da Devprime que possui um pipeline de processamento e proteção para evitar a exposição de informações confidenciais.
Agora é o momento de retornar ao SEQ e consultar o nosso log filtrado pelo TraceId == “9435d9eb-1e95-49fa-9e94-df7b34fd6d3f” e teremos o resultado desse fluxo da aplicação com o detalhamento completo do erro.
Visualizando o Distribuited Trace no Zipkin
A plataforma Devprime expõe o trace distribuído no formato Opentelemetry que vem sendo incorporado em várias ferramentas de APM (Application performance management) no mercado e uma delas apresentada nesse contexto é o Zipkin. Você pode utilizar o Jaeger ou qualquer outra similar.
O próximo passo é confirmar que os microsserviços Order e Payment estão rodando e efetuar um post na API do microsserviço ms-order disponível em https://localhost:5001. Em nosso ambiente local do Docker o Zipkin está executando na porta 9411. Para visualizar o trace distribuído basta acessar a url http://localhost:9411 e filtrar os eventos capturados e obter automaticamente a visualização abaixo.
Considerações final
A Devprime é uma plataforma que acelera a produtividade do desenvolvedor de software, economizando até 70% do investimento no backend, conforme você observou neste artigo que trata sobre o tema da observabilidade. Foi possível conferir recursos automáticos que facilitam o dia a dia do desenvolvedor de software e contribuem naturalmente para as equipes de SRE (Site Reliability Engineering) responsáveis pela administração das plataformas digitais.
Em um ambiente produtivo, é recomendado utilizar coletores como o FluentD ou FluentBit para capturar os logs diretamente das saídas dos contêineres e publicá-los em um repositório apropriado para indexação e consultas futuras.
Para capturar o OpenTelemetry no ambiente produtivo, é necessário implantar um coletor e um repositório para consulta por meio das ferramentas compatíveis. Os provedores de Cloud, como AWS, Azure e Google, estão evoluindo para disponibilizar recursos para o OpenTelemetry.
O que achou? Participe nos comentários e compartilhe.
Image: Freepik/Vectorjuice