Upgrade 2.x to 3.0.1 startup warnings

[skhilliard]

Upgrading from 2.x to 3.0.1 I am seeing some warnings logged that look a little worrysome...

@azure/opentelemetry-instrumentation-azure-sdk [
  'Module @azure/core-tracing has been loaded before @azure/opentelemetry-instrumentation-azure-sdk so it might not work, please initialize it before requiring @azure/core-tracing'
]```

and 

Accessing resource attributes before async attributes settled []

...are these of concern?  If so, how can they be fixed?

[JacksonWeber]

Regarding the first warning: #1316. Looking into resolving this with the Azure SDK libraries throwing the warning.

The async attributes settled warning is thrown by OpenTelemetry and occurs because we populate resource attributes asynchronously when trying to determine if the application is running in a VM environment. We are also looking into ways to mitigate this warning as well.

[skhilliard]

@JacksonWeber Any updates for this? Thanks!

[ghost]

I have the same issue.

[JacksonWeber]

@skhilliard @rassiju06 As of 3.1.0 the warnings surrounding performance counter metrics are resolved, however the warnings surrounding package loading and resource attributes are not. Please refer to #1107 if you're looking to suppress these warnings.

[8exgh]

Set environment variable:

APPLICATIONINSIGHTS_INSTRUMENTATION_LOGGING_LEVEL

to value:

NONE

Without setting logging to NONE, this value is returned by my console app and breaks the client parsing.

[hectorhdzg]

@8exgh sorry to hear this is breaking something on your side, we were expecting this to only be noisier only, we will prioritize accordingly, this is not a simple change as we use @azure/core-tracing, same package @azure/opentelemetry-instrumentation-azure-sdk is trying to patch using OpenTelemetry

[8exgh]

@hectorhdzg from my perspective setting APPLICATION_INSIGHTS_INSTRUMENTATION_LOGGING_LEVEL environment variable to NONE does the trick (valid work around so applicationinsights node_module logs nothing to standard out). But even setting ERROR log level for example, applicationinsights still indirectly logs a message with an empty array as part of the message (the warning excluded from the array), which was surprising to me. So yeah re-iterating, using NONE log level avoids standard output from that node_modules applicationinsights library.

Use case is some custom code in a Dockerfile:

CMD echo "Getting shard number from endpoint" &&
SHARD_NUMBER=$(node getShardHelper.js) && \

which returns an integer to shell script client, which is used to invoke playwright with sharding.

But by default the applicationinsights node_module indirectly writes to standard output for logging, which would result in:

SHARD_NUMBER=SOMELOGTEXT9, which will break the playwright --shard=$SHARD_NUMBER/$TOTAL_SHARDS