Issue:
By default, all 404 URLs and handled URLs in general generate their own metrics. We also have internal built-in health checks that display in these metrics which we wish to filter or hide. This can quickly bloat the metrics if many 404s hit the application. In my own organization we have instituted a metrics limit to protect from this behavior and limit the impact on our systems.
Current Solution:
I have observed that specifying swaggerOnly: true and swagger:apiSpec in the configuration forces URL Normalization and avoids capturing unhandled routes, including 404s and health checks. This means that 404s no longer generate metrics, but we lose visibility on 404s as well and requires a swagger.json be supplied.
Proposed Additional solution:
Add an option for urlNormalization which can use a default regex and additionally allow a custom regex to be supplied to handle this without the required options for swaggerOnly and requiring a swagger.json. Also as this will remove 404s from the metrics, generate a separate 404 count metric to give some visibility on the frequency of 404s.
Add an option for filterUrls which can be an array of url strings the implementer wishes to filter (IE: /healthCheck )
I don't mind taking a whack at this myself and submitting a PR, but obviously I'm not sure if there is consensus or issues I'm not considering.
Issue: By default, all 404 URLs and handled URLs in general generate their own metrics. We also have internal built-in health checks that display in these metrics which we wish to filter or hide. This can quickly bloat the metrics if many 404s hit the application. In my own organization we have instituted a metrics limit to protect from this behavior and limit the impact on our systems.
Current Solution: I have observed that specifying
swaggerOnly: true
andswagger:apiSpec
in the configuration forces URL Normalization and avoids capturing unhandled routes, including 404s and health checks. This means that 404s no longer generate metrics, but we lose visibility on 404s as well and requires aswagger.json
be supplied.Proposed Additional solution:
urlNormalization
which can use a default regex and additionally allow a custom regex to be supplied to handle this without the required options forswaggerOnly
and requiring aswagger.json
. Also as this will remove 404s from the metrics, generate a separate 404 count metric to give some visibility on the frequency of 404s.filterUrls
which can be an array of url strings the implementer wishes to filter (IE:/healthCheck
)I don't mind taking a whack at this myself and submitting a PR, but obviously I'm not sure if there is consensus or issues I'm not considering.