Skip to content
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

Initialize Trace Context for Service Bus Trigger using message "Diagnostic-Id" #632

Open
ChuckJonas opened this issue Sep 30, 2022 · 2 comments

Comments

@ChuckJonas
Copy link

ChuckJonas commented Sep 30, 2022

Investigative information

Please provide the following:

Test was run locally, but if needed can setup a "on cloud" reproduction.

Repro steps

  1. 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)
  1. 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 propagation
export default async function contextPropagatingHttpTrigger(context, message) {
  // overwrite with the proper traceparent from the message. 
  const sbTraceParent = context.bindingData.applicationProperties['diagnostic-Id'];
  if (sbTraceParent) {
    context.traceContext.traceparent = sbTraceParent;
  }

  const correlationContext = appInsights.startOperation(context, req) as CorrelationContext;

  // Wrap the Function runtime with correlationContext
  return appInsights.wrapWithCorrelationContext(async () => {

    try {
      appInsights.defaultClient.trackTrace({
        message: 'Correct Trace Context',
      });

      //wrong operation_Id
      context.log('Incorrect Trace Context');

      return await trigger(context, message);

    } catch (e) {
      context.log.error(e);
      throw e;
    } finally {
      // Track Request on completion
      appInsights.defaultClient.flush();
    }
  }, correlationContext)();
}

However, doing so only partially works.

  1. The "out of the box" request/response logging will still be done using the initial traceContext
  2. Any calls to context.log will still use the initial trace context.

Message In Service Bus
aebe-test__e2kf-servicebus-ngpphloem-dev01_aebe-test__-_Microsoft_Azure

Request Logged Against Initial TraceContext

e2kf-appinsights-ngp-dev01_-_Microsoft_Azure

Traces from AppInsights Correlation Context
e2kf-appinsights-ngp-dev01_-_Microsoft_Azure

@ChuckJonas
Copy link
Author

ChuckJonas commented Sep 30, 2022

Created after discussion in #522

@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.

@ejizba
Copy link
Contributor

ejizba commented Oct 31, 2022

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants