[BUG] Documentation should clarify that node apps should use applicationinsights, not this package

[dbjorge]

Description/Screenshot

This package's README contains no indication that it is not intended for use with Node.js applications. The closest thing to documentation about use from a non-DOM environment that I was able to find linked from the README was this comment in the suggested sample for the @microsoft/applicationinsights-web-basic package, which made me expect that that package would be the appropriate one to use in a Node environment without DOM access:

    <!-- Light SKU CDN. Use this SKU if you are running in environment with no DOM access.
        SKU functionlity is limited. It does not have curated apis for supported schemas 
        in Application Insights and auto collection of data. -->

Neither @microsoft/applicationinsights-web-basic nor @microsoft/applicationinsights-web work in a Node.js environment (at least, not unless an XMLHttpRequest polyfill exists globally) - both of them run without error, but don't actually send any telemetry (they fail silently when trying to use XMLHttpRequest and not finding it).

The Azure diagnostics when a user makes this mistake are not useful; the only meaningful suggestion they make is to "double check your instrumentation key".

Steps to Reproduce

• Be a user with no past experience using App Insights
• Have a node.js app you'd like to instrument with telemetry
• Ask a search engine for the "Application Insights JavaScript SDK"
• Find this repo's README and attempt to follow its instructions
• Spend a bunch of time confused when using the SDK gives you no errors, but silently fails to send data

Expected behavior

• The README should include prominent documentation that if you're trying to instrument a Node.js app, you want https://github.com/microsoft/ApplicationInsights-node.js instead of this repo/package
• These Azure docs should be updated similarly (with a pointer to these docs)
• The comment at the top of the -basic package's sample should similarly clarify that it isn't intended for non-Browser environments, even though it specifically mentions non-DOM environments
• If the SDK needs an XMLHttpRequest implementation to work, it should check whether one is available during initialization and fail fast if none is available. The error message should suggest that if this is a Node.js environment, you should use the applicationinsights package instead.
• The Azure TroubleshootDiagnoseBlade suggestions under the path "Application Insights > Diagnose and solve problems > Configure and sending data using Open Telemetry or Application Insights SDK > I need to monitor a non-Web App (console, etc.)" should contain a specific suggestion for a user in this scenario.

Additional context
n/a

[pizzaz93]

• The README should include prominent documentation that if you're trying to instrument a Node.js app, you want https://github.com/microsoft/ApplicationInsights-node.js instead of this repo/package Update README.md to redirect to Node.JS #1828

• These Azure docs should be updated similarly (with a pointer to these docs) Redirect to Node.js documentation from JS SDK and AISKULight SDK connection string clarification MicrosoftDocs/azure-docs#92380

• The comment at the top of the -basic package's sample should similarly clarify that it isn't intended for non-Browser environments, even though it specifically mentions non-DOM environments Specify supported environment for Application Insights JS SDK Azure-Samples/applicationinsights-web-sample1#6

• If the SDK needs an XMLHttpRequest implementation to work, it should check whether one is available during initialization and fail fast if none is available. The error message should suggest that if this is a Node.js environment, you should use the applicationinsights package instead.

• The Azure TroubleshootDiagnoseBlade suggestions under the path "Application Insights > Diagnose and solve problems > Configure and sending data using Open Telemetry or Application Insights SDK > I need to monitor a non-Web App (console, etc.)" should contain a specific suggestion for a user in this scenario.

[pizzaz93]

@MSNev Should the last two items be separated into:

1. An engineering issue/request?
2. A support suggestions edit request that wouldn't be tracked externally?

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.