-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Correlation does not work within WCF service #1631
Comments
@mrbullwinkle : To create a seperate doc for this, to drive clarity |
Any news on this issue? |
@peta Are you asking if there are plans in Application Insights to make correlation work automatically for WCF services? |
Any news about AppInsights for WCF as 6 months is over? |
None. Its likely to come via OpenTelemetry route. (OpenTelemetry WCF instrumentation+AzureMonitor exporter, which dont have feature parity with current ApplicationInsights. Don't have an ETA on when or whether it'll have same feature parity as this SDK.) |
This issue is stale because it has been open 300 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
When WCF service makes async call to http/sql/other dependency, writes traces, or reports exceptions, child telemetries do not correlate to the request telemetry.
It happens because WCF prevents ambient correlation context to flow with the request.
WCF is working to improve this story in future.
Workaround
Use WCF behavior extensions to restore the context. This article provides examples on how to create and configure the extension.
The workaround has a downside that telemetry reported by HttpModules/Handlers/Filters that happen in request execution pipeline BEFORE workaround will be correlated to telemetry reported in controller only by operation Id:
E.g trace1 was tracked in some HttpModule and trace2 was tracked in the WCF service.
Normally, Request telemetry becomes a parent to both traces (i.e. operation_Id match for traces and request, and request.Id match each trace operation_ParentId).
With the above workaround, operation_Ids would still match for all of them, however, trace1 operation_ParentId would NOT match request.Id, while trace2 parentId would match request Id.
The text was updated successfully, but these errors were encountered: