ApplicationInsights-node.js

ApplicationInsights-node.js is the official Node.js SDK for Azure Monitor Application Insights, letting teams observe backend services deployed anywhere — Azure VMs and Web Apps, a private datacenter, or another public cloud. Version 3.x rebuilds the SDK on top of OpenTelemetry, replacing the older proprietary 2.x pipeline with the standard OTel tracer, meter, and logger providers, while still shipping a setup().start() shim for teams migrating off the 2.x API.

Once started, the SDK auto-instruments HTTP calls, database and cache dependencies, and uncaught exceptions, batches the resulting spans/metrics/logs through the Azure Monitor OpenTelemetry Exporter, and optionally forwards the same telemetry to any OTLP-compatible backend via configurable otlpTraceExporterConfig, otlpMetricExporterConfig, and otlpLogExporterConfig processors. A built-in “statsbeat” mechanism reports SDK health (ingestion success, throttling, errors) back to Microsoft so both users and the Application Insights team can tell whether telemetry is actually making it out.

Because it sits on the shared OpenTelemetry global provider registry, a single process can host multiple TelemetryClient instances; each defaults to useGlobalProviders: true so auto-instrumentation is enabled without extra wiring, with an explicit opt-out for isolated, manual-only clients (e.g. per-tenant setups or tests) that need to avoid mixing telemetry across clients.

What You Get

• useAzureMonitor(options) entry point that configures OTel tracer/meter/logger providers and connects them to the Azure Monitor OpenTelemetry Exporter in one call
• Auto-collection of HTTP requests, outbound dependencies, uncaught exceptions, and performance counters with per-feature enable/disable flags
• Optional OTLP trace, metric, and log exporters/processors that run alongside the Azure Monitor exporter for dual-backend telemetry
• A backwards-compatible 2.x-style shim (appInsights.setup().start(), defaultClient, TelemetryClient) for incremental migration off the legacy SDK
• Built-in statsbeat instrumentation that reports the SDK’s own telemetry-delivery health (success rate, throttling, errors) back to Azure Monitor
• shutdownAzureMonitor() and flushAzureMonitor() lifecycle helpers for clean process shutdown and forced telemetry flush

Common Use Cases

• Adding request, dependency, and exception telemetry to an existing Express/Node API service deployed to Azure App Service or a VM
• Migrating a codebase off the legacy Application Insights 2.x SDK onto the OpenTelemetry-based 3.x pipeline using the compatibility shim
• Running a service outside Azure (another cloud or on-prem) while still centralizing telemetry in an Application Insights resource
• Dual-shipping telemetry to both Azure Monitor and a self-hosted OTLP collector (e.g. Grafana Tempo/Loki) during a vendor evaluation or migration window
• Diagnosing telemetry-delivery problems in production using the SDK’s statsbeat data before assuming an application-side bug

Under The Hood

Architecture The SDK’s public surface (src/main.ts) is a thin orchestration layer: useAzureMonitor() builds an ApplicationInsightsConfig (src/shared/configuration/config.ts), constructs optional OTLP span and log processors from it, and delegates the actual provider wiring to Microsoft’s @azure/monitor-opentelemetry distro before attaching its own exception auto-collector. Around this core sits a modular tree — src/agent (App Service and Azure Functions loaders plus diagnostics), src/metrics, src/traces, src/logs, and src/declarations for generated contract types — with a separate src/shim layer that reimplements the legacy 2.x setup().start() / defaultClient / TelemetryClient API on top of the same OpenTelemetry core, letting old and new call styles coexist in one process via shared global providers.

Tech Stack Written in TypeScript (~5.4) targeting Node.js 20+, the SDK is effectively a curated assembly of the OpenTelemetry JS ecosystem (@opentelemetry/api, sdk-trace-node, sdk-logs, sdk-metrics, OTLP HTTP/proto exporters) layered under Azure’s own @azure/monitor-opentelemetry and @azure/monitor-opentelemetry-exporter packages, with @azure/identity and @azure/functions covering auth and serverless integration. Builds run through tsc, linting through ESLint and Prettier, and the npm scripts expose separate test, test:e2e, functionaltest, and backcompattest targets for testing the packaged artifact against real and legacy scenarios.

Code Quality The repository carries roughly 32 TypeScript test files split across unitTests, backCompatibility, endToEnd, functionalTests, and performanceTests, run with Mocha, Sinon, and Nock under Nyc coverage. Sample tests reach into real OpenTelemetry provider internals (span processors, logger providers) rather than only asserting on mocks, and comments in test helpers explicitly document version-specific SDK internals the tests depend on. ESLint and Prettier configs are present and enforced via npm scripts, and configuration classes use explicit typed fields with narrow runtime type checks on incoming options.

What Makes It Unique The SDK’s distinguishing feature is less its telemetry collection — which follows standard OpenTelemetry instrumentation patterns — than its migration and self-diagnostic tooling: a full backward-compatible shim that lets teams keep their 2.x call sites working unmodified while the underlying pipeline is entirely OpenTelemetry-based, plus a built-in “statsbeat” feature-and-delivery-health reporter that gives both users and Microsoft support visibility into whether the SDK’s own telemetry is actually reaching Azure Monitor.