What has changed?
The service-to-service correlation feature was already supported before we looked into W3C. Service-to-service correlation provides a way to link all the send-out telemetry of your application’s services into a single transaction diagram. This helps pinpoint the cause of service failures, performance bottlenecks, and gives you a clear overview of all the resources your project uses. In Azure Application Insights, this translates to transaction diagnostics and an application map.
So, what has changed? Previously, we were using hierarchical correlation, which uses Request-Id to establish a link between the ‘parent’ (sender) and ‘child’ (receiver). This ID could be sent via an HTTP header or an Azure Service Bus application property or any other system that has a sender/receiver relationship. There were two problems with this approach: 1. the hierarchical correlation system is deprecated, and 2. it is not Microsoft’s default correlation format. This enacted a switch to the W3C correlation system. The biggest changes are internal. However, this format uses the traceparent value to pass along sender/receiver services instead.
Migrate from hierarchical to W3C correlation
The W3C update impacts three packages. Make sure that you update to these three versions at least: Arcus Web API v1.7, Arcus Messaging v1.4, and Arcus Observability v2.7.
🚩 Note that you do not need a Messaging package in an API application or the way around. These are just the minimum versions you’ll need in any one of your applications using Arcus.
Now comes the fun part. To have seamless integration with Microsoft in any of your applications, all you have to do is add/change these lines in your Program:
⚡ Notice that there are no additional changes required for API, Messaging-specific or event Azure Functions applications. All the critical changes are internal. The modifications described here are just to create a seamless integration with Microsoft technology. Behind the scenes, the AddAppName/Add...AppVersion will make sure that Microsoft’s TelemetryClient is configured as appropriate. This same client will be re-used when registering the Serilog sink.
⚠️ It’s worth noting that these changes need to happen across all your applications, as these will now use W3C correlation by default. Not changing them will result in a broken transaction diagram. You can always move back to hierarchical to do this migration in steps.
Moving forward
After the packages are upgraded and the small observability changes are added, we can look at the current and future tracked telemetry. Because this new system uses Microsoft’s default W3C correlation format, all called dependent services will be tracked automatically. This includes HTTP requests, SQL commands and any Azure services like Azure Service Bus or EventHubs. This means that if you have tracked such service before with Arcus extensions, you can now remove this (otherwise it will be tracked twice).
This will greatly reduce the observability clutter in your application.
⚡ Since this new update also builds on top of existing Application Insights services, you can inject the TelemetryClient into your application if you want to do some advanced telemetry tracking. Since the Serilog sink reuses this client, any additional advanced configuration will also affect the telemetry sent via the regular Arcus telemetry.
Future dependent services that are not one of Microsoft’s resources can still be easily tracked with Arcus telemetry. All other technology will be tracked automatically.
💡 All the Arcus project templates will be adapted to this new way of working, so that new projects can also benefit from this behavior.
Conclusion
What’s great about this update is that it does not break current behavior, but extends it with automatic dependency tracking via the Application Insights services. There were some arguments around still using the Application Insights SDK instead of our Arcus Serilog sink setup, but this new update renders the difference moot. They now work together.
📢 To learn more about W3C service-to-service correlation, see our extensive user guides where we explain step-by-step how an application without tracking can be adapted to fully leverage the power of Arcus and Microsoft telemetry.
See our official Observability 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!
The Arcus team
Subscribe to our RSS feed