A monitor process who is able to bind incoming and outgoing HTTP requests so that applications do not need to propagate correlation headers.

• Transparency: no need for app developers modify their code; only deployment modifications (may be) required
• Minimal overhead: no significant performance impact over apps being monitored

1. listen to key syscalls (recvfrom, sendto, fork, clone,...)
2. detect incoming / outgoing HTTP requests in a per-thread basis
3. extract tracing headers from incoming requests & inject them into outgoing related requests

Compile

$ gcc -o rbinder rbinder.c

Run server with rbinder. Example:

$ ./rbinder /usr/bin/python server.py

Scenario

• Two services (1 & 2)
• Service 1 needs requesting something from 2 to fulfill its received requests
• rbinder is used for propagating service 1's tracing headers

Start service 2

$ PORT=9000 SERVICE_NAME=2 python ./demo/server.py

Start service 1

$ PORT=9876 SERVICE_NAME=1 ./rbinder /usr/bin/python ./demo/server.py

Request to service 1 with tracing headers

$ curl -H "X-Request-Id: 12345" localhost:9876

Service 2 output

WARNING:root:User-Agent: python-requests/2.18.3
Connection: keep-alive
Host: localhost:9000
Accept: */*
X-Request-Id: 12345
Accept-Encoding: gzip, deflate

$ docker-compose -f ./demo/docker-compose.yml up -d --build

Request to service 1 with tracing headers

$ curl -H "X-Request-Id: 12345" localhost:9876

Service 2 logs

$ docker-compose -f ./demo/docker-compose.yml logs service2

service2_1  | WARNING:root:Host: service2:9000
service2_1  | User-Agent: python-requests/2.18.4
service2_1  | Accept-Encoding: gzip, deflate
service2_1  | Accept: */*
service2_1  | Connection: keep-alive
service2_1  | X-Request-Id: 12345

regarding stuff in this dir

Scenario

• Front Envoy for generating tracing headers
  • it forwards all incoming requests to service 1
• 2 back-end services (1 & 2)
• Service 1 needs requesting something from 2 to fulfill its received requests
• Code for services instrumented with py_zipkin

Scenario

• Service 1 propagate tracing headers by itself

Run

$ docker-compose -f ./demo/instrumented_services/docker-compose.yml up -d --build

Request

$ curl localhost:8000

Check Zipkin web interface

http://localhost:9411/

Scenario

• rbinder is used for progating headers through service 1 calls

Run

$ RBINDER=1 docker-compose -f ./demo/instrumented_services/docker-compose.yml up -d --build

Check Zipkin web interface

http://localhost:9411/

regarding stuff in this dir

Scenario

• Front Envoy for generating tracing headers
  • it forwards all incoming requests to service 1
• 2 back-end services (1 & 2)
• Service 1 needs requesting something from 2 to fulfill its received requests
• Spans are sent to Zipkin through Envoy proxies

Scenario

• Service 1 propagate tracing headers by itself

Run

$ RBINDER='' docker-compose -f ./demo/proxied_services/docker-compose.yml up -d --build

Request

$ curl localhost:8000

Scenario

• rbinder is used for progating headers through service 1 calls

Run

$ RBINDER=1 docker-compose -f ./demo/proxied_services/docker-compose.yml up -d --build

Request

$ curl localhost:8000

Thanks to Envoy maintainers for their inspiring examples.