Glog and OpenTelemetry

[jeffotoni]

Glog and OpenTelemetry

Glog and OpenTelemetry do not compete with each other — quite the opposite. They complement each other perfectly within a modern architecture.

And yes, I created a structure for glog to extend flexibly without breaking it, or rather, that is the goal, but I did look at the scenario and reality we have today, such as Grafana, Jaeger, Prometheus, Datadog, etc.

In other words, how to make it flexible so we can deliver something practical and flexible in a very simple or complex scenario.

I can say that it is not easy, but I made the first version, the first kick, and all help is welcome, until reflections like this are super important for our next improvements and focus.

A preview
📍 Where each one comes in:
• OpenTelemetry is the backbone of distributed observability, responsible for generating and propagating traceID, spanID, metrics and spans between services via context.Context (beautiful, all good).

• Glog acts as a real, lean, fast and formattable logger, focused on:
• Readable logs in stdout
• Formats such as text, json, slog
• Dynamic fields, such as user_id, method, etc.
• And now (possibility): integration with traceability

In our APIs, when we use a TraceID in Context, we already have something very simple that solves many traceability problems, but we can make it even more robust using otel, and complementing it with glog, I will leave this integration in our RODMAP.

Next steps we can mature the integration with OpenTelemetry within the Quick framework as follows:
• Each API handler (*quick.Ctx) will generate or capture a traceID and spanID.
• This data will be automatically added to the glog context.

•This ensures end-to-end traceability, with logs that you can correlate with spans and metrics in any observability stack (Grafana Tempo, Jaeger, etc).

You will have an ecosystem where:

• OpenTelemetry tracks
• Glog logs
• Quick orchestrates

All with performance, simplicity and extensibility.

This is the direction we are heading... 🚀