Question: how to ignore healthcheck endpoint with otelmux

[huydinhle]

We are using otelmux to instrument our gorilla mux requests. Is there a way to ignore /health endpoint ?

[Aneurysm9]

There are a couple ways to handle this. You can attach the middleware to a mux that doesn't route to the health check endpoint and then compose that with one that does the health check but doesn't have the middleware. Alternately, you could implement a custom sampler that samples out health check requests. Finally, the otelhttp instrumentation has a Filter type that can be used to filter requests that should not have spans created. A PR moving that type (and its helper implementations) to a common location and integrating it with the otelmux instrumentation would probably be welcomed.

[jaredpiedt]

@Aneurysm9 I need similar functionality so I'm happy to work on a PR. Do you still prefer moving otelhttp.Filter to a different location or is it ok to use that type directly in the otelmux instrumentation?

[dmathieu]

We're starting to use the Filter (and other attributes) in several places (the grpc instrumentation is the most recent one).
So I think moving it to a general location would be welcomed.

[jaredpiedt]

@dmathieu thank you for the quick reply. I noticed that the otelgrpc.Filter and otelhttp.Filter types have different function signatures. Would you like to keep both types and move them to a central package or figure out a way to combine the types?

[dmathieu]

Now thinking about this, making them shared may not be so easy, especially due to subtle differences with method signatures as we have in grpc.
Happy to hear other opinions, but maybe we can start with a separate option for otelmux.

[jaredpiedt]

@dmathieu I agree with keeping the two separate. Are you opposed to just using otelhttp.Filter in the otelmux library? That would create the least amount of changes to the code base, but I wasn't sure if it was bad practice to share code between different exporter packages?

[dmathieu]

If that were to happen, I think it would be better to have a shared/base package.

[Rshep3087]

We we're looking at this also at my company. Has there been any movement on this issue? We can look at picking it up if not.

[dmathieu]

No, there hasn't been any movement yet.

[Rshep3087]

So looking to move the filter package out of otelhttp, internal directory seems to make the most sense. It only has a util package at the moment.

Once that is moved to a shared/base package, otelhttp should only need imports changed. otelmux will need the filters config similar to otelhttp and filter called on the ServeHTTP method.