<@U4H0M349G> 1. Adding counter/timer to a top leve...

# http4k

[fredrik.nordin]

@dave 1. Adding counter/timer to a top level route and then overriding it with a timer/counter in a lower level route works as expected; there are tests for that 😄
2. I'll look at making the different types of metrics separate Filters instead; that'll make it more consistent with the other filters. Thanks for the suggestions!
3. The reason we need to do header manipulation (using the x-uri-template header) and not simply using uri.path, is that when you have a route that has a path variable in it, e.g. /books/{id:*}, you'll end up with a new counter/timer for every individual "id" for that route. Imagine when you have a collection that contains many thousand resources - you would end up with the same amount of metrics in memory and will probably run out of mem. That is why using the URI template is a better idea and is something that tends to be done in other metric implementations. That leads to the problem of getting hold of the relevant header, which is only set on the request by the TemplateRoutingHttpHandler at route construction time. Now if I change the implementation to individual filters instead of the current one, I should be able to easily get hold of it. I'll sort it out.