Previously, we only supported HTTP and Azure Service Bus request tracking in our telemetry extensions. The v2.6 expands on this with great new and extensible ways to track telemetry.
Azure EventHubs request tracking
We are working on fully supporting Azure EventHubs in our Messaging library. This means that we should be able to track EventHubs requests, as the messaging system will retrieve and process these events. When we update our Messaging library, events that get processed by your implemented message handlers will automatically be tracked.
We also provide overloads that take in an additional Azure EventHubs consumer group, and an operation name that provides a functional description of the event.
Azure Functions (isolated) HTTP trigger request tracking
With the arrival of isolated Azure Functions, processing HTTP requests has changed. Previously, we were able to re-use the ASP.NET Core HttpRequest/IActionResult but the isolated HTTP trigger variant stepped away from the reusable approach and uses new types: HttpRequestData/HttpResponseData. This impacts how we track events with our Observability library, as there is no default conversion available between the two approaches.
Therefore, Observability v2.6 introduces a new set of LogRequest overloads in the Arcus.Observability.Telemetry.AzureFunctions package that uses HttpRequestData instead of HttpRequest.
Our Templates library will receive an update that provide you with an Azure Functions (isolated) HTTP trigger project template, which will use this request tracking out-of-the-box. Note that isolated Azure Functions are able to work with custom middleware components, so the request tracking will (just like regular API applications) run in the background and not pollute your application code like with in-process Azure Functions.
Custom request tracking
Adding these new types of request tracking got us thinking that people should be able to extend it. We have already provided a way to track custom dependencies, which is in fact a way to support systems that don’t have support built-in the Observability library. Before v2.6, we didn’t provide such an extension for custom requests. With this extension, consumers can fully extend and use our library in any system possible. As service-to-service correlation relies on the request/dependency relationship, we can also say with confidence that we are able to provide service correlation to any system.
Conclusion
Alongside the new types of request tracking, this new release also contains a bunch of changes and fixes that improve the entire telemetry tracking experience. Take a look at the release notes to learn more about the newest Arcus Observability features.
You can also see our official documentation for more information on all the currently supported features. If you have any questions, remarks, comments, or just want to discuss something with us: feel free to contact the Arcus team at Codit.
Thanks for reading!
-Arcus team
Subscribe to our RSS feed