Fix OTEL logging in HotRod example #4556
Conversation
Signed-off-by: albertteoh <see.kwang.teoh@gmail.com>
| // - uint64 -> string | ||
| // - float32 -> float64 | ||
| // | ||
| // See: https://github.com/open-telemetry/opentelemetry-go/blob/main/bridge/opentracing/bridge.go#L538 |
There was a problem hiding this comment.
As the comment states, the mappings below are taken from the OTEL bridge to maintain consistency.
Codecov ReportPatch and project coverage have no change.
Additional details and impacted files@@ Coverage Diff @@
## main #4556 +/- ##
=======================================
Coverage 97.03% 97.03%
=======================================
Files 301 301
Lines 17837 17837
=======================================
Hits 17308 17308
Misses 424 424
Partials 105 105
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
| // TODO rather than always converting the fields, we could wrap them into a lazy logger | ||
| fa := fieldAdapter(make([]log.Field, 0, 2+len(fields))) | ||
| fa = append(fa, log.String("event", msg)) | ||
| fa = append(fa, log.String("level", level)) |
There was a problem hiding this comment.
Ha! Yes, you're right, my bad for this oversight and thanks for the callout. Added "level" as an attribute to the logs in: a31b067
Note that the MySQL spans are missing the log level:
That's because LogFields is invoked directly from the active span here:
Is this something we should fix in this PR?
There was a problem hiding this comment.
looks fine as is. Level is not meaningful in the span logs, the only reason to transfer it when converting real logs is to keep data fidelity.
| ) | ||
| } | ||
|
|
||
| func otLogFieldsToOTelAttrs(fields []zapcore.Field) []attribute.KeyValue { |
There was a problem hiding this comment.
| func otLogFieldsToOTelAttrs(fields []zapcore.Field) []attribute.KeyValue { | |
| func logFieldsToOTelAttrs(fields []zapcore.Field) []attribute.KeyValue { |
There was a problem hiding this comment.
Renamed in: b1d21a1
| } | ||
|
|
||
| type fieldAdapter []log.Field | ||
| func (e *bridgeFieldEncoder) AddBinary(key string, value []byte) { | ||
| e.pairs = append(e.pairs, otTagToOTelAttr(key, value)) |
There was a problem hiding this comment.
Since we know the type here, why do we call into method that erases the type and has to match on it at runtime? We could call the right otel attribute constructor right here.
There was a problem hiding this comment.
Just out of convenience, particularly for the "unsupported" types which fall back to the default case; although I like the fact that there's less indirection, so I've made direct calls in: b1d21a1.
Signed-off-by: albertteoh <see.kwang.teoh@gmail.com>
Signed-off-by: albertteoh <see.kwang.teoh@gmail.com>
## Short description of the changes - A cleaned up version of jaegertracing#4550. - It uses a single spanLogger for both OpenTracing and OpenTelemetry spans. - The logging works for both types spans because of [this clever line of code](https://github.com/opentracing/opentracing-go/blob/master/gocontext.go#L14) where `tracerWithHook` is an OTEL bridge tracer, allowing span to be stored in the `ctx` the "OTEL-way", making the span discoverable as a legitimate OTEL span such that `ok == true`: ```go if span, ok := ctx.Value(currentSpanKey).(Span); ok { ... } ``` ## Testing Ran locally to confirm logs appearing for both OpenTracing spans:  and OpenTelemetry spans:  --------- Signed-off-by: albertteoh <see.kwang.teoh@gmail.com> Signed-off-by: Afzal Ansari <afzal442@gmail.com>
Short description of the changes
tracerWithHookis an OTEL bridge tracer, allowing span to be stored in thectxthe "OTEL-way", making the span discoverable as a legitimate OTEL span such thatok == true:Testing
Ran locally to confirm logs appearing for both OpenTracing spans:
and OpenTelemetry spans:
