This topic is so big that it deserves its own blog post(s) – which we will provide in the future. For now, let’s take look at this from a very simple perspective: for better telemetry tracking around single or multiple applications, the logged information should be linked together. Why? Because it will help track down failures, pinpoint performance bottlenecks, keep track of the scope of your application and its dependencies and so on.
To do this linking, we need to pass around IDs that link sent/received messages together. One of these IDs is called a “dependency ID”.
Dependency IDs are unique identifiers that represent an operation between the called dependency and the received request on that dependency. From the sender’s point of view, this is called the dependency ID; from the receiver’s point of view, this is called the parent ID. That way, the telemetry that tracks the request (receiver) knows that its parent was the tracked dependency (sender).
The Observability library provides all sorts of dependency types that can be tracked, but not all of them support dependency IDs in their signatures. Starting from v2.5, all dependency types can be tracked with dependency IDs.
With incoming HTTP calls and retrieved messages on an Azure Service Bus queue, any incoming message should be tracked as a telemetry request in Application Insights. Previously, we tracked dependencies the same way as requests which made parent/child linking hard, as the request is in this case always the parent of the dependency. In v2.5 we made sure that requests are tracked differently so that the linking between the two is done automatically, without any intervention needed from the developer.
Looking at the result of this new feature and the tedious complexity that is hidden behind seamless simplicity, it is amazingly beautiful. An example of request linking is shown below:
Don’t worry – the service-to-service correlation feature will be explained in-depth in later phases, so that you can integrate it without effort in your application. For now, enjoy the prospect of beautiful request linking.
Future proof Application Insights connection string support
Soon, Application Insights will stop supporting instrumentation keys and fully rely on connection strings to track telemetry. Instead of waiting, we have already made sure that we can support connection strings. The feature documentation and code also reflect this, to gently guide users to use connection strings instead of instrumentation keys.
We have added a couple of new extensions to make this explicit:
SQL-pseudo command for more realistic SQL dependency tracking
Tracking SQL dependencies has already been available for a long time as a feature in Arcus Observability. In v2.5 however, we made sure that tracking said dependencies is more in line with realistic SQL scenarios. The problem was that we asked for a single table name, while realistic interactions with SQL Servers often happen across multiple tables (like
JOIN). Therefore, we made sure that consumers now can pass in a pseudo-like SQL command that will be passed to the dependency tracking. This pseudo-command will make sure that the dependency telemetry on Application Insights is more distinguished from any other SQL tracking. Administrators will also have an idea of the underlying low-level interaction with the SQL dependency, without knowing the finely-grained details.
Observability v2.5 is quite big. Not only have we taken significant steps in the service-to-service correlation story, but we have also made Observability more production-ready and future-proof. Stay tuned for more information on the service-to-service correlation feature, which is probably the biggest cross-repository Arcus feature we have ever created.
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!
Subscribe to our RSS feed