You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So that metrics are available on /metrics for the same AKKA server where we serve regular API calls. Therefore /api/v1/... (API calls) are routed through the load balancer to the end-user, so that the end-users can call paths that start with /api/v1, but /metrics is available only intra-cluster for Prometheus to scrape.
Below are examples on how we use pathPrefixLabeled and pathPrefix:
When a route responds with 400 for example, from its own route, let's say /api/v1/chat/ticket, the 4xx is properly recorded to route with label /api/v1/chat/ticket. However, when /api/v1/chat/ticket throws an exception and the exception is caught by AKKA's ExecutionDirectives.handleExceptions, when handleExceptions responds with 400, it is then recorded as unlabelled.
The exception handling encapsulator encapsulates all directives nearly, as follows:
The below code is from this very library, HttpMetricsDirectives. I can see that the response is patched with a PathLabel, but I figure this does not get passed when an exception is thrown from the path, because then there is no response.
private def rawPathPrefixLabeled[L](pm: PathMatcher[L], label: Option[String]): Directive[L] = {
implicit val LIsTuple: Tuple[L] = pm.ev
extractRequestContext.flatMap { ctx =>
val pathCandidate = ctx.unmatchedPath.toString
pm(ctx.unmatchedPath) match {
case Matched(rest, values) =>
tprovide(values) & mapRequestContext(_ withUnmatchedPath rest) & mapResponse { response =>
val suffix = response.attribute(HttpMetrics.PathLabel).getOrElse("")
val pathLabel = label match {
case Some(l) => "/" + l + suffix // pm matches additional slash prefix
case None => pathCandidate.substring(0, pathCandidate.length - rest.charCount) + suffix
}
response.addAttribute(HttpMetrics.PathLabel, pathLabel)
}
case Unmatched =>
reject
}
}
}
Is it possible to label these responses originating from the exception handling encapsulator?
If not, my idea is to extend the pathPrefixLabeled and pathPrefix to include the handleExceptions(exceptionHandler) part themselves and then the response would be originating from the proper route /api/v1/chat/ticket?
The text was updated successfully, but these errors were encountered:
All 2xx responses are recorded properly to their respective endpoint label, however, some 5xx and 4xx responses go to unlabelled:
The registry is created as follows:
And then we have the main route for that
prometheusRegistry
:So that metrics are available on
/metrics
for the same AKKA server where we serve regular API calls. Therefore/api/v1/...
(API calls) are routed through the load balancer to the end-user, so that the end-users can call paths that start with/api/v1
, but/metrics
is available only intra-cluster for Prometheus to scrape.Below are examples on how we use
pathPrefixLabeled
andpathPrefix
:When a route responds with 400 for example, from its own route, let's say
/api/v1/chat/ticket
, the 4xx is properly recorded to route with label/api/v1/chat/ticket
. However, when/api/v1/chat/ticket
throws an exception and the exception is caught by AKKA'sExecutionDirectives.handleExceptions
, whenhandleExceptions
responds with 400, it is then recorded as unlabelled.The exception handling encapsulator encapsulates all directives nearly, as follows:
The below code is from this very library,
HttpMetricsDirectives
. I can see that the response is patched with aPathLabel
, but I figure this does not get passed when an exception is thrown from the path, because then there is no response.Is it possible to label these responses originating from the exception handling encapsulator?
If not, my idea is to extend the
pathPrefixLabeled
andpathPrefix
to include thehandleExceptions(exceptionHandler)
part themselves and then the response would be originating from the proper route/api/v1/chat/ticket
?The text was updated successfully, but these errors were encountered: