feat(proxy): add per-service metrics to the proxy service

[pbleser-oc]

Description

Improve the metrics for the proxy service.

• extend the instrumenter middleware to add a label with the name of the service the request is being dispatched to
• add a native Prometheus histogram that tracks the durations and also includes a label for the name of the service the request is being dispatched to, as well as a result label (success, client-error, server-error) based on the HTTP status code of the response
• add per-service gauge functions to count the number of in-flight requests
• add a counter for routing failures, for when an inbound request cannot be mapped to a route
• extend the route.RoutingInfo struct with a service attribute, and a Service() getter
• remove the routing_failure_count metric, as it is redundant

Added metrics:

• opencloud_proxy_request_duration_seconds{service=..., method=..., result=...} (native histogram)
• opencloud_proxy_service_request_total{service=..., method=..., result=...} (counter)
• opencloud_proxy_service_duration_seconds{service=..., method=..., result=...} (legacy histogram)

The labels:

• method: is the HTTP method (GET, ...)
• result: maps the HTTP response status code to one of three values to reduce the cardinality, either success (0-399), client-error (400-499), server-error (500-)
• success: is the service identifier, e.g. eu.opencloud.web.webdav, eu.opencloud.web.graph, ...

Note

Previously existing metrics have been kept as-is, backwards compatibility is retained.

Motivation and Context

More detailed metrics will allow for better introspection of a running production installment, in order to determine if something is slow, and what, by being able to drill down by service and not just with global metrics that do not differentiate.

How Has This Been Tested?

Manually by checking the resulting metrics when querying the /metrics endpoint of the debug address, as well as with a Prometheus scraping container.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation added

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 5 complexity

Metric	Results
Complexity	5

View in Codacy

🟢 Coverage 6.47% diff coverage · -0.05% coverage variation

Metric	Results
Coverage variation	✅ -0.05% coverage variation (-1.00%)
Diff coverage	✅ 6.47% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (e0bfca4)	88741	21470	24.19%
Head commit (36747cf)	88899 (+158)	21461 (-9)	24.14% (-0.05%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3521)	201	13	6.47%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[micbar]

See my question.