You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using the Native package to enrich my application insights telemetry, but I have noticed that not all telemetry is enriched with details from the ServiceContext, set by the call FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext) at startup in the SF Service class.
Many of our SF microservices use Owin based Web Api Contollers, RabbitMq message handlers and HangFire JobServers, all spawning their own threads, which leads me to think that I need to call the .SetServiceCallContext in more places than just the SF service class itself, to ensure that the CallContext for all threads have set the SF ServiceContext details to be picked up by Application Insights.
So should I call FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext) multiple times?
The text was updated successfully, but these errors were encountered:
Hi @mikanyg,
For Owin based api controllers, my experience has been that you just need to set call context when you create service listeners.
However, all FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext) does is that it sets a property bag on the logical CallContext. Remember that CallContext is associated with Tasks (not threads - as thread pool threads are a shared resource and any task can be scheduled on a thread), so CallContext will only flow to a particular point in code if it was set upstream either in the current task/sync code or a parent task.
So, your assessment is correct, you may need to play around a bit and make the call in a few other places that lead to the place in code where telemetry is being generated. The original guidance in the readme simply identifies the entry points for out-of-the-box use cases. If you have message handlers and scheduled jobs that do not fit with the boilerplate templates, you should identify entry points and make sure context flows from there.
I am using the Native package to enrich my application insights telemetry, but I have noticed that not all telemetry is enriched with details from the ServiceContext, set by the call
FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext)
at startup in the SF Service class.Many of our SF microservices use Owin based Web Api Contollers, RabbitMq message handlers and HangFire JobServers, all spawning their own threads, which leads me to think that I need to call the .SetServiceCallContext in more places than just the SF service class itself, to ensure that the CallContext for all threads have set the SF ServiceContext details to be picked up by Application Insights.
So should I call
FabricTelemetryInitializerExtension.SetServiceCallContext(ServiceContext)
multiple times?The text was updated successfully, but these errors were encountered: