ExpressJS: Operation_Name and Operation_Id not showing in Application Insights

[Cmmc13]

Hello there,

I have a node server running expressJS, on which I am trying to add logging through Application Insights, using the following configuration and testing it locally:

const express = require('express');
const app = express();
let appInsights = require("applicationinsights"); //v^3.2.1

appInsights.setup(process.env.AZURE_APPLICATION_INSIGHTS_CONNECTION_STRING)
.setAutoDependencyCorrelation(true)
.setAutoCollectRequests(true)
.setAutoCollectPerformance(true)
.setAutoCollectExceptions(true)
.setAutoCollectDependencies(true)
.setAutoCollectConsole(true, true)
.setUseDiskRetryCaching(true)
.setDistributedTracingMode(appInsights.DistributedTracingModes.AI_AND_W3C)
.setSendLiveMetrics(true) .start();
appInsights.defaultClient.config.samplingPercentage = 100;
appInsights.defaultClient.config.maxBatchSize = 0;

app.use(express.json());

This setup seems to work well, I can get every single log through the Application Insights' log search, however, they are missing some fields I usually use such as the "operation_Name" and "operation_Id".

After searching for nearly 2 days I still can't figure out if this is intentional. I did find people reporting similar issues, but in the end, none of the solutions worked. I am sure switching to azure functions would solve this issue, but is there a way to have the tracing working like it does in azure functions while using expressJS?

[JacksonWeber]

@Cmmc13 What version of the SDK are you using? Just as a heads up, as mentioned in the documentation, operation name is not yet supported in the 3.X SDK.

[Cmmc13]

Thank you for the quick reply @JacksonWeber, I am indeed using a 3.X version. Although when I read the documentation I thought it just meant the Operation_Name field would be defaulted to a value in which case it might still be useful.
Regardless, it does not say anything about Operation_Id and I still cannot see it in the AI interface/log search.

[Cmmc13]

Downgrading to v2.9.5 solved the issue, so it indeed seems to be related to Operation_Name not being supported yet.

[JacksonWeber]

@Cmmc13 Can you provide some more details about the telemetry you're trying to see OperationName on? 3.x SDK should automatically populate this field so I just want to get a better idea of your use case.

[gausejakub]

Hi @JacksonWeber,

I'd like to share our experience with setting a custom operation_Id in our NestJS application. Our goal is to manually create trace logs while setting a custom operation_Id for correlating logs. Specifically, we send the operation_Id from the frontend, allowing us to link backend traces with frontend traces seamlessly.

However, we encountered difficulties with version 3.x. By default, the operation_Id is empty, and I couldn't find a way to set it automatically or manually.

Here's our current setup:

appInsights
  .setup(appInsightsSetup)
  .setAutoDependencyCorrelation(true)
  .setAutoCollectRequests(true)
  .setAutoCollectPerformance(true, true)
  .setAutoCollectExceptions(true)
  .setAutoCollectDependencies(true)
  .setAutoCollectConsole(false)
  .setUseDiskRetryCaching(true)
  .setSendLiveMetrics(false)
  .setDistributedTracingMode(appInsights.DistributedTracingModes.AI_AND_W3C);

appInsights.defaultClient.context.tags[appInsights.defaultClient.context.keys.cloudRole] = `${APP_NAME}:${envName}`;

appInsights.start();

For logging traces, we use:

appInsights?.defaultClient?.trackTrace({
  message: finalMessage,
  severity: appInsights.KnownSeverityLevel.Warning,
  properties: finalContext,
});

Despite trying various approaches to set the operation_Id — both manually and automatically — we haven't had any success.

In contrast, version 2.x provided a straightforward solution that worked without issues:

appInsights
  .setup(key)
  .setDistributedTracingMode(appInsights.DistributedTracingModes.AI_AND_W3C)
  .start();

appInsights.defaultClient.context.tags[
  appInsights.defaultClient.context.keys.operationId
] = 'your-operation-id';

appInsights.defaultClient.trackTrace({
  message: 'Testing message',
  severity: appInsights.Contracts.SeverityLevel.Information,
  properties: {},
});

For now, we’ve had to revert to version 2.9.6, but we’d prefer to use the latest version. If there's a preferred way to set operation_Id in version 3 that we might have missed, I'd appreciate any guidance.

Thanks!

[JacksonWeber]

@gausejakub The operation ID in 3.x of the SDK is just set to an OpenTelemetry traceId by default. If you're using the trackTrace() method. The value should never be blank, and I'm curious about how you're getting into that state. Can I take a look at one of your traces where operationId isn't being populated?

You mention that you try to manually set operationId in order to handle correlation between back and front-end logs. For these kinds of more custom scenarios, we would recommend that if you still want to upgrade to an OpenTelemetry based solution, that you use the Azure Monitor OpenTelemetry distro which will allow you more fine-grained control of the OpenTelemetry components that are created under the hood in v3.x of this SDK.

[JacksonWeber]

@gausejakub Operation ID and Operation Name are only supported on Request telemetry in v3.x of the SDK. We don't currently have support for setting it manually. We are tracking this feature though, and I can give you an update in thee case that it becomes supported in v3.x.