The ResponseMetrics middleware emits the timing metric fx.private.relay.response. This gives us the application's view of the response time, bucketed by the hour. We use the view tag to segment by views, to determine trends over time and slow periods.
This PR improve the tag view in a few cases:
/api/v1/runtime_data, other API view functions. - The tag was api.views.privaterelay.view. This is now api.views.privaterelay.runtime_data. Other API view functions also had '.view' for the last component, and now use their function name.
/__heartbeat__, other Dockerflow views - The tag was <unknown_view>, and is now dockerflow.django.views.heartbeat. Similar changes are made for /__version__ and /__lbheartbeat__.
Frontend files - The tag was <unknown_view>, and is now <static_file>.
This PR also includes tests for ResponseMetrics.
How to test
[x] I've added a unit test to test for potential regressions of this bug.
The
ResponseMetricsmiddleware emits the timing metricfx.private.relay.response. This gives us the application's view of the response time, bucketed by the hour. We use theviewtag to segment by views, to determine trends over time and slow periods.This PR improve the tag
viewin a few cases:/api/v1/runtime_data, other API view functions. - The tag wasapi.views.privaterelay.view. This is nowapi.views.privaterelay.runtime_data. Other API view functions also had '.view' for the last component, and now use their function name./__heartbeat__, other Dockerflow views - The tag was<unknown_view>, and is nowdockerflow.django.views.heartbeat. Similar changes are made for/__version__and/__lbheartbeat__.<unknown_view>, and is now<static_file>.This PR also includes tests for
ResponseMetrics.How to test