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
Test was run locally, but if needed can setup a "on cloud" reproduction.
Repro steps
Create a Service Bus Triggered function (Topic -> Subscription)
Connected with AppInsights
Add some traces via context.log
throw an error so as the processed messages gets moved to the DLQ (makes it easier to debug)
Fire a service bus event for subscription
Expected behavior
When a Service Bus triggered function is executed, I would expert the context.traceContext to be initialized using the Service Bus message Diagnostic-Id.
Actual behavior
The function seems to just initialize a brand new traceContext (not correlated to anything).
Known workarounds
Using the AppInsights wrapWithCorrelationContext, a traceContext can be initialized with the Diagnostic-Id being manually overridden as the traceParent.
// Default export wrapped with Application Insights FaaS context propagationexportdefaultasyncfunctioncontextPropagatingHttpTrigger(context,message){// overwrite with the proper traceparent from the message. constsbTraceParent=context.bindingData.applicationProperties['diagnostic-Id'];if(sbTraceParent){context.traceContext.traceparent=sbTraceParent;}constcorrelationContext=appInsights.startOperation(context,req)asCorrelationContext;// Wrap the Function runtime with correlationContextreturnappInsights.wrapWithCorrelationContext(async()=>{try{appInsights.defaultClient.trackTrace({message: 'Correct Trace Context',});//wrong operation_Idcontext.log('Incorrect Trace Context');returnawaittrigger(context,message);}catch(e){context.log.error(e);throwe;}finally{// Track Request on completionappInsights.defaultClient.flush();}},correlationContext)();}
However, doing so only partially works.
The "out of the box" request/response logging will still be done using the initial traceContext
Any calls to context.log will still use the initial trace context.
Message In Service Bus
Request Logged Against Initial TraceContext
Traces from AppInsights Correlation Context
The text was updated successfully, but these errors were encountered:
@ejizba when you have a second to take a look, it would be greatly appreciated 🙇 I've been chasing this down all week.
Our architecture is entirely using the Azure Managed Services (APIM, Azure Functions, ServiceBus, AppInsights) so I was hoping we'd get this out of the box...
It's also been pretty confusing knowing which team/repo this issue really falls under. I'm hoping it is something you all can help solve, because you're the only team I've been able to get much response from.
@RohitRanjanMS do you know if this service bus Diagnostic-Id is propagated as described for other languages? AFAIK, we're just passing along the traceContext we get from the host
Investigative information
Please provide the following:
Test was run locally, but if needed can setup a "on cloud" reproduction.
Repro steps
context.log
Expected behavior
When a Service Bus triggered function is executed, I would expert the
context.traceContext
to be initialized using the Service Bus messageDiagnostic-Id
.Actual behavior
The function seems to just initialize a brand new
traceContext
(not correlated to anything).Known workarounds
Using the AppInsights
wrapWithCorrelationContext
, a traceContext can be initialized with theDiagnostic-Id
being manually overridden as thetraceParent
.However, doing so only partially works.
traceContext
context.log
will still use the initial trace context.Message In Service Bus
Request Logged Against Initial TraceContext
Traces from AppInsights Correlation Context
The text was updated successfully, but these errors were encountered: