Monitoring Node.js

The Instana Node.js Collector

The Instana Node.js collector is an npm package that you add to the dependencies of your Node.js apps to enable metrics collection and automatic tracing, as well as reporting metrics and traces to Instana.

Server Only

This package is for monitoring Node.js server applications with Instana. If you want to monitor JavaScript applications running in a browser, check out our docs on website monitoring.


To install the Instana Node.js collector and have your Node.js app monitored by Instana, install the npm package @instana/collector via:

npm install --save @instana/collector

Now that the collector is installed, it needs to be activated from within the application. Do this by requiring and initializing it as the first statement in your application:


// All other require statements must be done after the collector is initialized.
// Note the () after the require statement of the collector which initializes it.

// const express = require('express');

For more in-depth information, refer to the installation page.


If your Node.js applications are run exclusively on Kubernetes, consider using the Instana AutoTrace WebHook method instead, which require no modifications to your applications.

Apigee Microgateway

Please refer to the Apigee Microgateway page for information on how to use the Instana Node.js collector package with Apigee Microgateway (also known as edgemicro).


For information on how to configure the Instana Node.js collector, refer to the configuration page.

Kubernetes & OpenShift

If your Node.js application and the Instana agent run in a Kubernetes cluster, please check the documentation on Kubernets network access for information about the required configuration in this setup.

Cloud Foundry

Note: This section assumes that the Instana agent is currently running on the Diego cells of the Cloud Foundry foundation. Without an agent running on the underpinning Diego cell, monitoring Cloud Foundry applications is not supported. Additionally, since the Tile version 1.177.0, the instana_buildpack automates the setup of Node.js applications on Cloud Foundry. For more information, refer to the Instana Buildpack documentation.

For information on how to setup Instana agents and the related Cloud Foundry or Pivotal Platform functionality, see our Cloud Foundry and Pivotal Platform documentation.

On Cloud Foundry, a configuration is not required at the level of cf push and the application manifest. The only necessary step is to add the @instana/collector package to the Cloud Foundry Node.js application as described above.


The Instana Node.js collector package provides an API for custom tracing and more. See the API page for more information.

Supported Node.js Versions

The Instana Node.js collector supports the following Node.js versions:

Node.js Version Collector Versions
16.0.0 and above 1.125.0 - latest
14.0.0 and above 1.97.0 - latest
12.0.0 and above 1.67.0 - latest
10.4.0 and above 1.38.0 - latest
8.2.1 and above 1.28.0 - latest
6.0.0 and above 1.0.0 - latest
4.5 and above 1.0.0 - 1.103.0
5.10 and above 1.0.0 - 1.103.0

This means that the collector supports Node.js 8.x beginning with version 8.2.1, but not versions 8.0.0 - 8.2.0. Similar version ranges are given for the other Node.js release lines, for example Node.js 10.x is supported beginning with 10.4.0; but releases 10.0.0 - 10.3.x are not supported. These constraints mostly relate to automatic tracing. Metrics collection and manual tracing (via the SDK or OpenTracing) is supported in Node.js version 6.0.0 and higher.

Note that newer Node.js versions typically require an up to date version of @instana/collector. For example, to have automatic tracing in Node.js 12.x, you need to use at least @instana/[email protected].

We usually support LTS versions of Node.js (those with even major version numbers, that is, Node.js 8, 10, 12, ...) for at least one year after their official end of life. Non-LTS versions (those with odd major version numbers) are supported at least until their EOL. Note that the Instana Node.js collector usually works with non-LTS Node.js versions even after their EOL (e. g., it will work with Node.js 9, 11, 13, 15) even though they are no longer officially supported. You can find out about Node.js releases and their lifecycle on this page (or here for older releases).

If you need support for very old Node.js versions (e.g. Node.js 5 and older) you can pin the version of @instana/collector in your package.json file. For example, to use @instana/collector with Node.js 4, pin the version to @instana/[email protected], which is the last collector version with support for Node.js 4.

Supported Libraries


The column labeled "Since Collector Version" denotes the minimum version of @instana/collector that is required for a given feature. Please check the changelog for details.

Library Since Collector Version
Express error handling & path templates 1.32.0, 1.43.0
Fastify 1.x path templates 1.44.0
HTTP(s) clients 1.10.0
HTTP(s) servers 1.10.0
HTTP/2 clients 1.103.0
HTTP/2 servers 1.103.0
hapi path templates 1.68.0
koa-router path templates 1.56.0
request-promise 1.10.0
request 1.10.0
superagent 1.102.0


The column labeled "Since Collector Version" denotes the minimum version of @instana/collector that is required for a given feature. Please check the changelog for details.

Library Since Collector Version
Apollo Federation 1.87.0
GRPC 1.63.1
GraphQL 1.69.0


The column labeled "Since Collector Version" denotes the minimum version of @instana/collector that is required for a given feature. Please check the changelog for details.

Library Since Collector Version
AWS SDK v2 S3 1.115.0
AWS SDK v3 S3 1.129.0
AWS SDK v2 DynamoDB, 1.116.0
AWS SDK v3 DynamoDB, 1.127.0
Elasticsearch Legacy Client (elasticsearch)) 1.10.0
Elasticsearch Modern Client (@elastic/elasticsearch)) 1.96.0
Memcached (memcached) (>= 2.2.2) 1.126.0
MongoDB (mongodb) (>= 2.2) 1.13.0
Mongoose (mongoose) 1.13.0
MySQL (mysql) 1.29.0
MySQL (mysql2) 1.37.1
MSSQL (mssql) 1.47.0
Postgres (pg) 1.44.2
Postgres (pg-native) 1.86.0
Redis (redis) 1.31.0
Redis (ioredis) 1.33.0
Sequelize depends on driver1


The column labeled "Since Collector Version" denotes the minimum version of @instana/collector that is required for a given feature. Please check the changelog for details.

Library Since Collector Version
AWS SQS2 6 1.114.0
AWS Kinesis 1.120.0
Google Cloud PubSub2 (>= 1.2.0) 1.107.0
NATS streaming2 3 1.72.0
NATS2 3 1.72.0
RabbitMQ/amqplib2 1.51.0
kafka-node2 3 1.20.0
kafkajs2 1.83.0
Bull7 1.119.0

Cloud Services

The column labeled "Since Collector Version" denotes the minimum version of @instana/collector that is required for a given feature. Please check the changelog for details.

Library Since Collector Version
AWS SQS2 6 1.114.0
AWS SDK v2 S3 1.115.0
AWS SDK v3 S3 1.129.0
AWS SDK v2 DynamoDB 1.116.0
AWS SDK v3 DynamoDB 1.127.0
AWS Kinesis 1.120.0
Google Cloud Storage 1.105.0
Google Cloud PubSub2 (>= 1.2.0) 1.107.0


The column labeled "Since Collector Version" denotes the minimum version of @instana/collector that is required for a given feature. Please check the changelog for details.

Library Since Collector Version
Bunyan 1.54.0
express-winston4 1.88.0
log4js 1.84.0
Pino 1.52.0
Winston (>= 3.x) 1.53.0
Winston (<= 2.x) 1.88.0


The column labeled "Since Collector Version" denotes the minimum version of @instana/collector that is required for a given feature. Please check the changelog for details.

Library Since Collector Version
async 1.10.0
Bluebird 1.35.0
Native Promises 1.10.0
q 1.10.0
Timers 1.10.0


The column labeled "Since Collector Version" denotes the minimum version of @instana/collector that is required for a given feature. Please check the changelog for details.

Library Since Collector Version Comment
Apigee Microgateway/edgemicro (2.4, 2.5, >= 3.x) 1.89.0 Requires additional installation steps.5

Metrics Collection

Tracked Configuration Metrics
Runtime Versions GC Activity
Deployed Apps Memory Usage
Name Heap Spaces
Version Event Loop
Description HTTP Servers - Request/Response Times
Arguments Health check status and time of last status change
HTTP Servers Config
Health checks (via admin-plugin-healthcheck)  

The dependencies of a Node.js process can also be retrieved from the software versions API endpoint.

Health Signatures

  • Garbage Collection Activity
  • Latency
  • Calls
  • Errors
  • Failing health checks (see Health Check Support below)

Health Check Support

The Instana Node.js collector will conduct custom health checks and execute them every ten seconds. If the checks fail for at least 30 seconds, an issue will be raised to inform the user.

Health checks are gathered from installed admin-plugin-healthcheck modules.

health check

Health checks listed in the Node.js dashboard.


Issue raised about failing health checks.

Tracing Support

OpenCensus Instana Trace Exporter

Instana provides an OpenCensus Trace Exporter for applications written in Node.js. Using the Instana agent processes as proxy, Instana forwards traces that are exported by applications instrumented with Census to its backend.

For more information, see the OpenCensus Exporters website.


Note: This feature is currently in beta-testing.

AutoProfile™ generates and reports process profiles to Instana automatically and continuously. Learn more about profiles in Analyze Profiles section.

To enable AutoProfile™, see Node.js Collector Configuration.

Monitoring Issues

Node.js Collector Not Installed

Monitoring issue type: nodejs_collector_not_installed

The Node.js process has not connected with the agent to send traces and metrics. This may be due to one of the following reasons:

  1. The @instana/collector package has not been installed correctly in the Node.js application.
  2. The Node.js process cannot report to the host agent on the same host due to network connectivity issues

Verify The Process Is Instrumented

If the @instana/collector package has been added to your application and correctly activated, you will see entries like the following in your application logs:

Attempting agent communication via <hostname>:<port>

If you do not see any such message in your application log, the package @instana/collector is probably not installed and initialized correctly. The installation documentation provides an overview of the steps to perform depending on your application, and the Common Pitfalls documentation provides an overview of the gotchas we have seen over time.

If your Node.js application runs in Kubernetes, you should try out the Instana AutoTrace WebHook, which automatically and transparently adds the Node.js instrumentation to your pods.

Networking Issues

If the Node.js collector is installed (refer to the previous section), and you see the following message in your application logs, the @instana/collector package cannot communicate with the host agent, and it is likely a networking issue:

Announce attempt failed: <error>. Will retry in <seconds>s.

Verify that the Node.js process can connect to the host agent on the same host on port 42699. For more information on the required network visibility, refer to the Network requirements documentation for the Instana host agent.

What we see increasingly often, is that in containerized platforms either there are network visibility issues between the container with the application to be traced and the container of the Instana host agent. Another issue of the same kind is that, due to some overlay network setup, the container of the application to be traced does not connect to the Instana agent container on the same host.

Often the problem is that the Node.js collector is using the wrong IP address or DNS name to talk to the Instana agent. You can instruct the Node.js collector to user a specific network address via the INSTANA_AGENT_HOST environment-variable.

In very few cases, we have seen customers that set up their networking so that the problem was not the network address, but the port the collector uses. In case you need a port remapping, because the host agent does not listen on port 42699 but something else, you can instruct the collector to use a different port via the INSTANA_AGENT_PORT environment variable.

In case none of the above helps you troubleshoot the issue, please open a Support Ticket.

Collector Initialized Too Late

Monitoring issue type: nodejs_collector_initialized_too_late

To ensure tracing works correctly, the package @instana/collector needs to be required and initialized before any other Node.js packages are required. However, the package can heuristically detect that it has been initialized too late. In case this warning is displayed on your Node.js dashboard, this detection mechanism has determined that other packages have been loaded before its initialization. Please refer to the installation documentation and in particular to the Common Pitfalls section for more details on this.

Often, using the approach outlined in Installation Without Modifying the Source Code can also help to resolve this issue in advanced build and deployment scenarios, in particular when using a bundler (like Webpack) or a transpiler (Babel, TypeScript, ...).

AutoProfile Package Not Available

Monitoring issue type: nodejs_collector_native_addon_autoprofile_missing

You configured the Node.js process to make use of Instana's AutoProfile feature feature, but the package @instana/autoprofile could not be loaded. As a result, you will not get profiling information for this Node.js app in Instana. The package @instana/autoprofile is an optional dependency of @instana/collector and it is automatically installed when possible. But since it is a native addon, its installation can fail.

A common reason for that (in particular for containerized applications) is that required operating system packages for building C++ are missing on the target machine or in the target container image.

Another possible root cause is the way in which the container image is built. Node.js packages need to be installed on in the target image. Running npm install or yarn on a build system and then copying the entire node_modules folder to a container image with a potentially different architecture or operating system will not work; this step needs to happen inside the target image.

Please see refer to the section on Native Addons for more information on the subject.

Missing Calls Due To Unsupported Triggers

As a general rule, Instana tracers only capture outgoing calls when there is an active entry span. In some edge cases, this can lead to calls not being captured that you would expect to be captured; for example when work is triggered by a mechanism that is not supported by our automatic instrumentation. The solution for these use cases is to create an entry span via custom tracing using Instana's Node.js SDK. Refer to this section in the Node.js SDK documentation for more details.

See Also

  1. Instana does not instrument Sequelize directly, but rather the underlying database drivers. Visibilty into what sequelize does thus depends on the database library you are using together with Sequelize (mysql, mysql2, mssql, pg, ´pg-native`, etc.).

  2. To capture subsequent calls correctly after consuming/receiving a message with AWS SQS, kafkajs, kafka-node, RabbitMQ/amqplib, NATS, NATS streaming, or Google Cloud PubSub, you need to use span.disableAutoEnd() and span.end(), see ending spans manually.

  3. Trace continuity is not supported

    • for NATS (because NATS has no message headers, see NATS tracing docs),
    • for NATS streaming (because NATS streaming has no message headers, see NATS tracing docs), and
    • when using the npm package kafka-node to send or consume messages, because that package does not support Kafka record headers: See kafka-node#763 and kafka-node#1309). Trace continuity is supported for Kafka in general starting with Kafka version 0.11 for other runtimes and also when using the package kafkajs. We therefore strongly recommend to use kafkajs instead of kafka-node when using Kafka as well as Instana in your Node.js application.
  4. Requires express-winston to be configured with statusLevels: true, as Instana only captures log messages of severity warn or higher.

  5. Using Apigee Microgateway/edgemicro with @instana/collector requires additional installation steps. Please refer to the installation instructions for this use case.

  6. AWS SQS requires manual async context restoration when using promises with async/await

  7. Bull repeatable jobs that are part of a bulk will not be properly instrumented due to not being expected by the API. They are expected to be forbidden in newest versions of Bull