there is a requirement (and some outstanding todo's) to log errors and warnings from the API, so move logger setup into API to facilitate this. |
||
|---|---|---|
| .. | ||
| collector | ||
| screenshots | ||
| src | ||
| README.md | ||
| docker-compose.yml | ||
README.md
Distributed Tracing Example
This example uses docker-compose, and illustrates the distributed tracing functionality of OpenTelemetry. An HTTP request to service-one will make multiple asynchronous HTTP requests, each of which is injected with a traceparent header.
All trace data is exported via grpc to an OpenTelemetry Collector, where they are forwarded to zipkin and jaeger.
The example is presented as a slim framework single-file application for simplicity, and uses Guzzle as an HTTP client. The same application source is used for all services.
Running the example
$ docker-compose run service-one composer install
$ docker-compose up
# in a separate terminal
$ curl localhost:8000/users/otel
Screenshots
Jaeger
Zipkin
Notes
- A guzzle middleware is responsible for wrapping each outgoing HTTP request in a span with http-based attributes, and injecting
traceparent(and optionallytracestate) headers. - A slim middleware is responsible for starting the root span, using the route pattern for the span name due to its low cardinality (see https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#span). This is also where incoming trace headers are managed.

