-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add WithRouteTagMiddleware function to otelhttp package #4017
Conversation
Co-authored-by: Damien Mathieu <42@dmathieu.com>
Could you please provide examples? You can even consider adding "test examples". EDIT: I think if we document how to use it with: |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #4017 +/- ##
=======================================
- Coverage 79.2% 79.0% -0.2%
=======================================
Files 165 165
Lines 10318 10349 +31
=======================================
+ Hits 8176 8182 +6
- Misses 2006 2030 +24
- Partials 136 137 +1
|
…to otelhttp-route-tag-middleware
go.opentelemetry.io/otel/sdk v1.16.0 h1:Z1Ok1YsijYL0CSJpHt4cS3wDDh7p572grzNrBMiMWgE= | ||
go.opentelemetry.io/otel/sdk v1.16.0/go.mod h1:tMsIuKXuuIWPBAOrH+eHtvhTL+SntFtXF9QD68aP6p4= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have to move the test to /test
subdirectory as the instrumentation libraries must not depend on the SDK.
@pellared I've added one example so far and can add more in the morning. I added it to instrumentation/net/http/otelhttp/example/server/github.com/labstack/echo . It semanticly makes sense but may be tough to find. What do you think? |
@pellared I've added a bunch of examples to instrumentation/net/http/otelhttp/example/server. Probably not the best place so lmk if there's somewhere else they should be. |
I think simpler, and testable examples would be better than this. What we need is a code sample, not a full-blown runnable app. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am really on low time until Wednesday, but I did my best to put any feedback that can hopefully help.
r.GET("/users/:id", func(c echo.Context) error { | ||
id := c.Param("id") | ||
name := getUser(c.Request().Context(), id) | ||
return c.JSON(http.StatusOK, struct { | ||
ID string | ||
Name string | ||
}{ | ||
ID: id, | ||
Name: name, | ||
}) | ||
}, echo.WrapMiddleware(otelhttp.WithRouteTagMiddleware("/users/:id"))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it not be possible to get rid of the "/users/:id"
duplication?
I do not like requiring to add echo.WrapMiddleware(otelhttp.WithRouteTagMiddleware()
for each registering handler.
I would prefer to have something like
r.Use(echo.WrapMiddleware(otelhttp.NewMiddleware("my-server")))
r.Use(OTelRouteTaggerMiddleware()) // or: r.Use(otelecho.RouteTaggerMiddleware())
r.GET("/users/:id", func(c echo.Context) error {
id := c.Param("id")
name := getUser(c.Request().Context(), id)
return c.JSON(http.StatusOK, struct {
ID string
Name string
}{
ID: id,
Name: name,
})
})
I hope something similar could be adopted for other libraries 😉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pellared I can't come up with a way we can create a generic middleware for this since the route tag is usually router specific and not possible to retrieve in our middleware. If users want a catch all middleware I think each library would need to implement this. For example echo would need a middleware that uses the result of c.Path()
as the route tag.
We could provide a utility function that adds a passed route tag as an attribute and changes the span name as discussed previously.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could provide a utility function that adds a passed route tag as an attribute and changes the span name as discussed previously.
I think this may be more flexible and powerful. Writing a little middleware that would use this function should not be a big deal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added this utility function to otelhttp and route tagger middleware in 4 of the http router modules. Added a question about where to put the examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you update the examples? The existing example structure is good enough. We can refine it later once we have a consensus on the implementation part.
Add RouteTaggerMiddleware for most routers
Not sure how to do this and actually add examples for the |
They can be put in the same directory, but with a different module name. See this example from gRPC: https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/instrumentation/google.golang.org/grpc/otelgrpc/example_interceptor_test.go |
Won't that still require dependencies in the go.mod? I created a file called |
It's still unclear to me where I should be putting the example tests. Maybe there is not really a good answer for this at the moment? |
For me it is good as it is for now. We can improve the examples later. You are correct here: #4017 (comment) |
// RouteTaggerMiddleware annotates the current span with the handler's route path. | ||
func RouteTaggerMiddleware() restful.FilterFunction { | ||
return func(request *restful.Request, response *restful.Response, chain *restful.FilterChain) { | ||
otelhttp.AnnotateSpanWithHTTPRoute(request.Request.Context(), request.SelectedRoutePath()) | ||
chain.ProcessFilter(request, response) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not depend on otelhttp
in other instrumentation libraries. These libraries are not stable and bumping in otelhttp
can break otelgin
users. The AnnotateSpanWithHTTPRoute
implementation is so small that I would rather inline it in existing instrumentation packages.
I would prefer if this PR is only about otelhttp
.
I would move the middleware implementations using AnnotateSpanWithHTTPRoute
to examples under otelhttp
. This would demonstrate how someone could use otelhttp
e.g. instead of otelmux
. Related comment: #4017 (comment)
Does anyone have opinions on whether this should be closed? It seems like the third party instrumentation is due to be removed at some point so maybe this is obsolete? |
With the routing enhancements in Go 1.22, and this PR being rather stale, I think we should close it. Note that while 1.22 added routing support, retrieving the pattern is only available from 1.23. So we'll have to wait for 1.22 to be EOL. |
This new function simplifies usage of this utility by users of third party router packages.