PoC OTel implementation with services written in Go
Inside the src/
directory, create a .env
file that matches the .env.example
file. The contents can be
identical to those in the .env.example
file.
Within the environment
entry for each service defined in the src/docker-compose.yml
file, there are three
entries (TRACES_EXPORTER
, METRICS_EXPORTER
, LOGS_EXPORTER
) for configuring how various telemetry types
get exported. All three entries can take one of the following values:
otel
: Export telemetry for this type to thecollector
service (which sends all received telemetry to its ownstdout
and Datadog by default).stdout
: Export telemetry for this type tostdout
of the container that this service is running on.noop
: Do not export telemetry for this type anywhere.
If the environment
definition for your entrypoint_service
looked like this in docker-compose.yml
:
- TRACES_EXPORTER=otel
- METRICS_EXPORTER=stdout
- LOGS_EXPORTER=noop
Then traces for entrypoint_service
would be sent to the collector
instance, metrics would just be logged to stdout
of the entrypoint_service
, and logs would be silenced entirely.
Run docker compose up --build
from inside the src/
directory.
The entrypoint
service has several public endpoints that can be accessed via:
curl http://localhost:5000/<ENDPOINT>
A full list of current endpoints for the entrypoint_service
:
/
: Log a hello message and increment a meter that tracks how many requests have been made to/
/basicA
: Send a random number to the/basicRequest
API forservice_a
, which immediately returns the number back to theentrypoint_service
./basicB
: Same as above, but forservice_b
./chainedA
: Send a random number to the/chainedRequest
API forservice_a
, which adds another random number to it, sends the result toservice_b
, who adds another random number to it before sending the result back to theentrypoint_service
./chainedAsyncA
: Send a random number to the/chainedAsyncRequest
API forservice_a
, which adds another random number to it.service_a
then asynchronously calls the/chainedRequest
API forservice_b
, and immediately returns a success message to theentrypoint_service
. This API demonstrates manual trace propagation, where the trace ID for an incoming request must be extracted and used for a new context. The code for this is in thenewContext()
function ofservice_a
./inlineTraceEx
: Send a random number to the/addNumber
API forservice_a
, which adds another random number to it and returns the result. On theentrypoint_service
, one of two inline spans are created: one if the returned number is less than or equal to 5, and another otherwise. This API demonstrates how to manually create traces inside of application code, as opposed to the automatic instrumentation that is used elsewhere in this repository.
None of them do anything particularly interesting and are only intended to demonstrate various aspects of OTel instrumentation.
- Write docs on how to configure existing instrumentation (e.g. send telemetry to collector vs service stdout vs noop)