feat(otelgin): enhance gin error tracking with span recording #6346
Conversation
|
Could you test this change? Also, I wonder if we need to keep the |
|
Side note that otelgin has no owner, so it may be removed soon. |
Okay, will this package still accept new PRs at present? |
|
It does. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6346 +/- ##
=====================================
Coverage 66.9% 66.9%
=====================================
Files 193 193
Lines 15652 15654 +2
=====================================
+ Hits 10480 10482 +2
Misses 4881 4881
Partials 291 291
|
|
I think I can give it a try. If I come to maintain it, what do I need to do? |
|
That's documented in the issue, as well as in https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/CONTRIBUTING.md#code-owners. |
Co-authored-by: Damien Mathieu <42@dmathieu.com>
It's done. |
I spent some time reading through the requirements. I understand that I may still need to make some contributions before applying. If so, I need some time. |
|
link: #5252 |
Co-authored-by: Damien Mathieu <42@dmathieu.com>
instrumentation/github.com/gin-gonic/gin/otelgin/test/gintrace_test.go
Outdated
Show resolved
Hide resolved
instrumentation/github.com/gin-gonic/gin/otelgin/test/gintrace_test.go
Outdated
Show resolved
Hide resolved
instrumentation/github.com/gin-gonic/gin/otelgin/test/gintrace_test.go
Outdated
Show resolved
Hide resolved
Co-authored-by: Robert Pająk <pellared@hotmail.com>
…_test.go Co-authored-by: Robert Pająk <pellared@hotmail.com>
|
Could you resolve the conflicts? |
…ace-recorderror # Conflicts: # instrumentation/github.com/gin-gonic/gin/otelgin/gintrace_test.go # instrumentation/github.com/gin-gonic/gin/otelgin/test/gintrace_test.go
It's done. |
|
@dmathieu I could pick up ownership of this module so that it isn't removed, should I just open a PR on the codeowners file? |
|
Yes, that should be enough (link the otelgin deprecation issue in that PR). |
| @@ -95,7 +95,10 @@ func Middleware(service string, opts ...Option) gin.HandlerFunc { | |||
| span.SetAttributes(semconv.HTTPStatusCode(status)) | |||
| } | |||
| if len(c.Errors) > 0 { | |||
| span.SetAttributes(attribute.String("gin.errors", c.Errors.String())) | |||
| span.SetStatus(codes.Error, "gin error") | |||
There was a problem hiding this comment.
gin error isn't very meaningful.
| span.SetStatus(codes.Error, "gin error") | |
| span.SetStatus(codes.Error, c.Errors.String()) |
There was a problem hiding this comment.
Wont this duplicate, in a less useful flattened string from, the information being added as events below?
There was a problem hiding this comment.
@akats7 We can discuss it here. It should be the same issue here.
There was a problem hiding this comment.
I recommend using this method to record: span.SetStatus(codes.Error, c.Errors.String())
I would like to hear everyone's suggestions.
instrumentation/github.com/gin-gonic/gin/otelgin/test/gintrace_test.go
Outdated
Show resolved
Hide resolved
Could you review this PR if you want to be an code owner? 😉 |
|
lgtm, my only real thought is I personally always find it convenient to have the error message at least partially included directly on the span instead of only having the span events. Since span events are sometimes (always?) stored in separate table it could becomes an additional step to view the message depending on the platform you use. For example I know a lot of the java instrumentation just adds error: true as an attribute and then creates a span event, and we've had teams complain that the error message has no contextual info |
This is indeed a problem, and it usually depends on what backend tools we are using. Fortunately, when the entire span contains some abnormal events, the tool I am currently using allows me to see the exception information directly in the span interface. Of course, for more detailed information, I still need to switch to view it in Events. —— Back to this PR, due to the OTEL standard specifications, I suggest we still maintain storing exceptions in Events. After all, this project is for the majority of users, and we need to present ourselves as professionally as possible and in accordance with the standards. 😁 |
|
Yes we need to record the errors as a span event, what I'm getting at is when it comes to: I do find including the error string to have value |
…_test.go Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
No description provided.