[Feature Request] Group unhandled paths instead of filter
Filipoliko opened this issue · comments
Hi,
just ran into this #79 issue and im glad to see the new defaults. It definitely makes sense to me.
Im just a bit worried about filter_unhandled_paths=True
throwing away information about some 404 requests. I think we are missing out on some potentially key information about what kinds of requests are being sent to the server. Instead of filtering, wouldn't it make sense to group these requests under some others
/unhandled
value?
If this sounds interesting, there could be a new flag group_unhandled_paths
created. If set to True
, it could group all unhandled paths into some common value for these unhandled requests. The other flag name filter_unhandled_paths
does not make much sense to implement this kind of logic, so it makes more sense to me to create a new one.
If there is agreement, I would be happy to create a PR.
@Filipoliko that sounds useful. Do you envision a new metric or a special value of path
for existing metrics (perhaps None
)?
@stephenhillier I've been thinking about a special value of path
.
I was thinking other
, unhandled
, or even None
could be nice.
http_requests_total{app_name="api",method="GET",path="other",status_code="404"} 1.0
http_requests_total{app_name="api",method="GET",path="unhandled",status_code="404"} 1.0
http_requests_total{app_name="api",method="GET",path="None",status_code="404"} 1.0
http_requests_total{app_name="api",method="GET",path="__unknown__",status_code="404"} 1.0
I checked how other projects are handling this.
- prometheus-flask-exporter is using
None
- fastify-metrics - is using
__unknown__
(but it is configurable by user)
But it is difficult to find examples. Some projects are offering users to implement some sort of custom url path transformers so they can handle it any way they want.
I think either value sounds reasonable 👍
Don't feel like you need to make it configurable right away (your choice), that could be added later if somebody needs it.