cc: @abaranch, @briancr-ms, @BogdanBe, @vitalyf007

Stable version of Application Insights SDK doesn't support hierarchical correlation today. Correlation is implemented using two fields: RequestTelemetry.ID and ITelemetry.Context.Operaiton.Id. When these fields match - we show them as related in UI.

Cross-tier and hierarchical correlation requires more fields. Typical scenario for this type of correlation that we want to support is for every page view event (collected by JavaScript SDK) we show as "children" all ajax calls run on the page. For every ajax call we show corresponding server request collected by .NET server SDK. Every server request may have children operations like "business logic execution" or "rendering" which in turn may have calls to external dependencies as children activities. So we can troubleshoot page loading sloweness and show the root cause when sloweness was caused by database issue.

We propose the following terminology:

• Transaction Name - name of the first/topmost/root operation that initiated entire chain of execution.
• Transaction ID - correspondingly unique ID of operation described above.
• *Parent Operation ID" - unique id of the operation that was active at the moment when telemetry was reported
• Operation Name - name of the telemetry item if it is request telemetry or dependency telemetry
• Operation ID - unique id of the telemetry item if it is request telemetry or dependency telemetry

_Note:_ We propose to use term Transaction as oppose to Root Operation as we believe that transaction is easier to understand and explain.

Label for corresponding telemetry items on request details blade will be updated to this:
"All traces/exceptions/dependencies for this request transaction".

We can use the following http header names to propagate correlation information:

• x-ms-request-id for parent operation ID
• x-ms-transaction-id for transaction ID
• x-ms-transaction-name for transaction name

Going forward In order to support proper end-to-end cross-tier events correlation we want to start using concept called "correlation vector". The idea behind correlation vector is very similar to the new EventSource correlation and causation feature in FW 4.6. Here is Vance Morrison blog post explaining this feature.

Correlation vector is a string consist of base64-encoded GUID and a dot-delimited vector of integer values: HyCFaiQoBkyEp0L3.1.2

It support two method: Increment that will increment the last integer in a vector and Extend that will add .0 to the end of the vector.

Whenever new layer receives correlation vector it extends it and use it as the current operation identity. Every time new outgoing operation is started - correlation vector of current operation is incremented on one side and extended on other side of operation.

The main advantages of correlation vector comparing to traditional ParentOperaitonId, TransactionId approach are:

• Ability to build execution tree even if some events are missing
• Ordering of operation that doesn't rely on event time

So the new data field CorrelationVector will be included into Operation context.

Hovewer, there are still services using ParentOperationId, TransactionId concept for end-to-end tracking of operations. There are services receiving headers like x-ms-request-id representing operation ID that should be used as a parent operation of the service's new operation. Thus the proposal is to support fields ParentOperationId and TransactionId for these services.

The idea is that SDK developer will use ParentOperationId field for the requests called with this header. However if no operation id header was configured - CorrelationVector-based correlation will be preferred.