We have a distributed application with a mix of legacy ASP .NET webapplications, ASP .NET Core webapplications, ASP .NET Core microservices, .NET Framework console applications and .NET Core console applications. Communication between the components are both point-to-point over HTTP and over RabbitMQ.
A typical case is that a request is processed by a public facing webapplication, and this results in both direct communication with one or more microservices over HTTP, but also that one or more events are generated and published to RabbitMQ, and processed as soon as the consumer has free capacity. We are using ApplicationInsights (which works very well for HTTP), but struggles with adding the requests over RabbitMQ to the visual representation of the end-to-end transaction. We are chaining up the requests with OperationId and ParentId as described in the documentation, and can run a query which returns all the correlated operations, but we are not able to see the entire end-to-end transaction in view "End-to-end transaction details" on the Azure Portal, only the pure HTTP requests.
Has anybody insights to share? What is necessary to do so that Application Insights understands that operations in context of a RabbitMQ consumer also should be shown graphically?
Quoting ZakiMa's comment as an answer here so it helps others in the community who have similar asks:
Hi! We're actively working on enabling exactly this. If you're interested to try private preview (a matter of having special flag in URL, no extra configuration), please send email to my alias. Domain is microsoft ---- com.
Also, just FYI for reference that this is also quoted in the docs that relate to implementing Distrubuted Tracing with Application Insights:
Currently, automatic context propagation across messaging technologies (like Kafka, RabbitMQ, and Azure Service Bus) isn't supported. It is possible to code such scenarios manually by using the trackDependency and trackRequest methods. In these methods, a dependency telemetry represents a message being enqueued by a producer. The request represents a message being processed by a consumer. In this case, both operation_id and operation_parentId should be propagated in the message's properties.
Thanks for reaching out.
UPDATE as of 06/18/2020:
This feature has been released to Public Preview. In Application Map/End-to-end details you should see a banner and Try preview option as under:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With