Skip to content

luizhlelis/dotnet-trace-context

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

66 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Dotnet Trace Context

Application architecture

The purpose is to propagate a message with traceparent id throw two api's and one worker using W3C trace context standard. The first-api calls the second-api by a http call, on the other hand, the second-api has an asynchronous communication with the worker by a message broker (I chose rabbitmq for that). Furthermore, I chose zipkin as default APM tool, being responsible for get the application traces and build the distributed tracing diagram.

Distributed Trace

The first and second APIs have the same code base, but they're deployed in different containers.

Running the project

Inside src folder, type the command below to up all containers (first-api, second-api, worker, rabbit and zipkin):

  docker-compose up

wait for all containers get on and then send a request to the first-api:

curl --request POST \
  --url http://localhost:5000/WeatherForecast \
  --header 'Content-Type: application/json' \
  --header 'accept: */*' \
  --data '{
	"temperatureC": 10,
	"summary": "Trace Test"
}'

the message that you sent above will travel throughout the flow (first-api > second-api > rabbit > worker) along with the propagation fields (traceparent and tracestate). To see the generated distributed tracing diagram, access zipkin in your browser:

  http://localhost:9411/

at home page, let the search field empty and type RUN QUERY to load all traces. Finally, click in your trace, then you'll see a diagram like this:

Zipkin Diagram

Releases

No releases published

Packages

No packages published