Arcus Web API v1.3 is all about request tracking. Previous versions introduced the request tracking concept as a way to track the incoming HTTP request and outgoing HTTP response with a limited set of knobs to tweak such as to request/response body, headers, the time it took to process the request…
This new version takes this to a whole new level so that your next project can benefit from a production-ready request tracking functionality!
Omit entire routes from the request tracking
Initially, the request tracking was tracking all routes. This was a good first basic approach but when more realistic scenario’s comes into play, this is rather cumbersome.
For example, health endpoints to track the health of your web API add noise to your telemetry pipeline without a lot of added value. Especially when they are called often, and the result is almost always a success.
You can now annotate API controllers and routes with our new [ExcludeRequestTracking] attribute which will ensure that the entire request tracking functionality will be excluded:
When endpoints are exposed by one of your dependencies, such as Dapr, you have no control over where the endpoint is hosted, nor can you extend it.
For those scenarios, an additional option was added to the configurable request tracking options:
Only track certain HTTP status codes
As a continuation of the previous health endpoints example, it would be even better if we could only measure health failures and ignore all success statuses. That would make the tracking more cost-efficient and actionable, as well as help troubleshooting.
You can now define an allow list of HTTP status status codes to track for a given endpoint by using the [RequestTracking] attribute. The request tracking will only happen when the HTTP response’s status code is within the configured status code range.
In the following example, the request tracking of the health endpoint will only happen when the HTTP response status code is between 500 and 599 (range is inconclusive).
These HTTP status code ranges can also be specified in the global request tracking options. The request tracking will then only happen when every HTTP response’s status code is within this specified range.
Note that the [RequestTracking] attribute can be combined with the TrackedStatusCodeRanges option. The request tracking will then happen when the HTTP response’s status is within both status code ranges.
Finer grained request/response body exclusion
Up until now, users had the choice of using request and/or response body tracking to gain more insights. However, this was only configurable for all operations. This can become pretty expensive, since it might be too much or does not give any added value.
Because of that, we are allowing you to choose where you want to track what!
By using the [RequestTracking] attribute, you can now also specify what should be excluded from the request tracking. For example, the request and/or response body for a given route.
The following example shows how an HTTP request body can be excluded from the request tracking, in combination with the IncludeRequestBody option:
Also, buffers have been created so that you can specify how much of the HTTP request/response body should be included in the telemetry. This can be useful to get a general idea of the bodies, while also preventing the telemetry entries from being overloaded.
Conclusion
In this post we looked at some new request tracking features that are included in the v1.3 release of the Arcus Web API. For more information about request tracking, see the official documentation which goes in-depth into all the available attributes and options.
If you have any questions, remarks, comments, or just want to discuss something; feel free to contact us.
Thanks for reading!
– The Arcus team
Subscribe to our RSS feed