Tracing directive

[jum (Jens-Uwe Mager)]

I tried using the tracing directive, and it does what I need, namely adding a traceId to the log and a traceparent header. But it also starts an OTEL exporter, which I do not need. Is there a way to just have the trace ids and traceparent header without the OTEL export stuff going on?

In my log I see a lot of these messages:

2024/04/28 20:20:51 traces export: context deadline exceeded: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing: dial tcp [::1]:4317: connect: connection refused"

This is just the msg part, so they are not even in json format.

[francislavoie]

You can configure OTEL stuff using env vars, see tracing (Caddyfile directive) — Caddy Documentation

But if all you need is a UUID, don’t use tracing. Instead, use the {uuid} placeholder. You can add it to a request_header to send it upstream. As of v2.8.0, this’ll also be included in the logs (you can build from master if you need that right away).

[jum (Jens-Uwe Mager)]

For example setting OTEL_TRACES_EXPORTER=none does not work, it still attempts to export and produces the errors.

To be able to get a traceid into the log and a traceparent header I probably need a caddy module? The format is also not an uuid, a trace id is 32 digits hex and the parent (span) is 16 digits hex.

[francislavoie]

@jum

For example setting OTEL_TRACES_EXPORTER=none does not work, it still attempts to export and produces the errors.

The docs link to here:

open-telemetry/opentelemetry-specification/blob/bc61ad5b4c5cd4a4e250eb72b2c6bfdf2c74b157/specification/configuration/sdk-environment-variables.md

Don’t you want OTEL_SDK_DISABLED?

@jum

To be able to get a traceid into the log and a traceparent header I probably need a caddy module?

No plugins needed for {uuid}, it’s built-in.

@jum

The format is also not an uuid, a trace id is 32 digits hex and the parent (span) is 16 digits hex.

Why do you need it to be specifically that format if you’re not using the OTEL exporter?

[jum (Jens-Uwe Mager)]

I tried OTEL_SDK_DISABLED as well, does not make a difference.

I need the trace id and traceparent in the proper format. I do not need the OTEL exporter because caddy‘s stderr (where all my logging is going, inclusive access logging), is already having all the information I need. All output of my docker containers ends up in Google cloud stack driver logging. The only missing piece is now proper trace ids to let stackdriver correlate the logs of the various containers. All the containers (except caddy currently) conform to the traceid and traceparent convention.

OTEL is only one software ecosystem that uses the same traceid and traceparent convention, there are many others.