Expose target service name in middleware about traefik HOT 5 CLOSED

Hi @WDaan,

Thanks for your issue.

For now there is nothing else to access service name.

What is the issue with the current log/access log implementation?
Why do you want to create a plugin for that?

Could you please explain a bit more your use case?

from traefik.

I want to run Traefik in a microservice architecture, all requests will flow through Traefik.

Instead of having all microservices implement their own logger middleware, I'd like to remove that responsibility from them and move it to a Traefik plugin.

The plugin would parse usefull information from the request, obfuscate headers where needed and log the result so it can be picked up by our logging setup.

On key part of usefull information would be the service the request would get routed to.
(Same for tracking custom metrics)

Does that clarify it enough?

from traefik.

Hi @mmatur

Any further comment?

Thanks

from traefik.

Hi @WDaan,

Why are not using the current access log filtering available in Traefik?

You can use json format and you will have a bunch of field available and the one you are looking for is ServiceName

from traefik.

Hi @mmatur, thanks for your reply 😄

TLDR; it's great but just not flexible enough. Traefik v3 breaks the above mentioned 'service'-hack

• Can't make fields 'top level'
  • x-amzn-trace-id => I want this to be a top level field, because downstream services include this in their log messages and during debugging you can easily filter on this field
  • user_id,org_id => Same reason, currently I extract those from the JWT (I can probably set them as headers in the forward-auth middleware, but still cannot get them top level)
• Custom log level => I set a log level based on status code or some other factor, so I can dashboard/report on that
• Custom log format => our Fluentbit setup drops messages that do not adhere to certain rules. So I'd either have to make an exception for Traefik (which would break some dashboards) or massage/reformat it on Fluentbit side to support our format
• No servicename remapping => I remap the service name from namespace-my-service-80@kubernetes to my-service, so I can see all log messages (app + requests) with the same filter e.g. service=my-service
• No Path/Query Param extraction => api/organizations/392dcb9d-d855-4447-97bc-3255eab8e37a/?test=1234 gets remapped to api/organizations/:org as path and the params get logged as a separate JSON top level fields params and query. We use this for debugging and dashboarding/analytics use-cases

It was great to be able to use a Traefik middleware to generate this, instead of relying on all downstream dev teams to implement the standard properly in various languages. The middleware removes that pain point altogether.

Similar issues for metrics; the current metrics do not include a 'cleaned' path label (or any path label). We use this label so we can split our SLO's based on paths we expect to be fast/slow. Or on other labels that can be set from within the middleware. We currently export metrics ourselves because the default provided ones are not extensive enough and other labels can only be added from headers. On of the labels we set is the remapped service name.

Now with Traefik v3, this setup is broken because the 'service' field is no longer exists on the http.Handler

I tried to extract the LogData from the context like the accesslog-middleware does it but was unable get anything.

func GetLogData(req *http.Request) *LogData {
	if ld, ok := req.Context().Value(DataTableKey).(*LogData); ok {
		return ld
	}
	return nil
}

Is there any other way of getting access to the service name from within a middleware?

Thanks for your input 😄

from traefik.