Logs, Trace distribuído em microsserviços usando .NET / C# e Devprime
Tags: microsserviços, microservices, dotnet, tutorial
Published: 2023-12-27 16:24:28

Uma 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](https://devprime.io).

A plataforma [Devprime](https://devprime.io) é 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](https://devprime.io) 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).

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ps55ba175pqi7p993o4w.png)

Além disso, a [Devprime](https://devprime.io) 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).


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pvbnphs0cx0ryf1p1zho.png)

Com esses recursos disponíveis na plataforma [Devprime](https://devprime.io), 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](https://devprime.io).

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](https://devprime.io). É importante lembrar que é preciso ativar uma Exchange “devprime” e as filas “orderevents” e “paymentevents” no RabbitMQ.


**Preparando o ambiente**

– Instale o .NET 8.0 ou uma versão superior.
– Instale o Visual Studio Code. – Instale e ative [Devprime](https://devprime.io) 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](https://devprime.io) ou implementados manualmente seguindo a documentação da [Devprime](https://devprime.io).

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)
```
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/59lkbwjemxe4n2p5vlig.png)

b) Payment (ms-payment)

```
.\run.ps1 ou ./run.sh (Linux, macOS)
```

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/520s97m38m196w0bmctq.png)

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”.

```json
  “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](https://devprime.io) e nesse contexto visível pelo Seq na url local http://localhost:8000.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jcyj6yk391m5zvcpwkmm.png)

É importante ressaltar que além de gerar os logs automaticamente e padronizados em todas as aplicações a plataforma [Devprime](https://devprime.io) 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.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/554a5fh1fkq7a974ecja.png)

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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fa407iwj5xdpywg5vtej.png)

É importante ressaltar que mesmo com o erro nenhuma informação adicional foi devolvida a API e isso é um recurso interno da [Devprime](https://devprime.io) 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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/beaoqmmzkmg11aezfr3r.png)

**Visualizando o Distribuited Trace no Zipkin**

A plataforma [Devprime](https://devprime.io) 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.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jag74jfa7hg4pbk5l6sn.png)

**Considerações finais**

A [Devprime](https://devprime.io) é 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.

[],
Ramon Durães
CEO, [Devprime](https://devprime.io)

Image: Freepik/Vectorjuice