We are preparing for a major feature called service-to-service correlation. This feature will allow us to correlate back-and-forth between different services, linking your entire application. This is a great way to get a solid overview of your project and pinpoint possible problems such as bottlenecks. As this feature encompasses several different systems and types of services, we are preparing each related Arcus repository – starting with Arcus Observability.
Tracking Azure Service Bus requests
Before v2.4, we could only track HTTP requests, which meant that we could only track incoming messages in a Web API context. For our service-to-service correlation feature, this was not enough, as many different services can ‘receive’ a request – Azure Service Bus, for example.
In Arcus Observability v2.4, we’ve added support for tracking incoming messages on Azure Service Bus queues or topic subscriptions. In an application, when a message is peaked on the queue or topic subscription, one can now track this message. In a larger setup, this was a small but critical missing part of the service-to-service correlation puzzle.
Marking dependency tracking with correlation ID
Starting from v2.4, one can add a custom dependency ID when tracking Azure Key Vault dependencies. Our goal is to upgrade every dependency tracking in our library, with the option of passing along a dependency ID. The reason we added this is also related to the service-to-service big picture. Adding such a dependency ID to our tracking will help when one wants to link a tracked request to the dependency. A more thorough explanation about service-to-service correlation will follow. For now, it’s already a big step that we can integrate dependency IDs in our tracking.
Custom request ID generation
When tracking requests in Azure Application Insights, the ID of the request was previously a generated GUID. Not configurable at all. Arcus Observability v2.4 changes that. Consumers can pass in their own generation function and therefore fully control how the request ID in Azure Application Insights looks like.
This request ID is useful (for example) in a service-to-service correlation system where you want the ID of the incoming request to be based on the sending system, or you want to incorporate the operation ID in the request ID.
.NET 6 support
.NET 6 was released some time ago, and one of our many requests was how we can support this new framework. In library development, this is not always an easy process.
Arcus wasn’t yet taking any steps to support the new framework. Arcus Observability v2.4 takes the first step in adding .NET 6 support to Arcus. In this version, we still support .NET Core 3.1 but we also already support .NET 6. Further releases across Arcus will also include this .NET 6 support, so we can ultimately say that Arcus is fully .NET 6 supported.
When .NET Core is finally unsupported, we will fully rely on .NET 6. Until then, multi-support will be our goal.
Conclusion
Arcus Observability v2.4 has a lot of new features, almost all related to our upcoming service-to-service correlation support. We also gradually support .NET 6 throughout Arcus, and hope to update the other libraries soon.
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 Codit, feel free to contact us.
Thanks for reading!
-Arcus team
Subscribe to our RSS feed