Changed

• Require parent spans on database and outgoing HTTP instrumentations that support it. When a database query is performed using the ioredis, pg, redis or mongoose libraries, or when an outgoing HTTP request is performed using the http module, a span will only be created if a trace has already been started in the current active context, that is, if the span to be created would have a parent.

  This helps prevent database queries and outgoing HTTP requests happening in uninstrumented contexts from counting towards your requests quota.

Fixed

• Add support for Koa v3.

View the Node.js package v3.7.4 changelog for more information.

Fixed

• Handle pino logs without a msg attribute.

View the Node.js package v3.7.3 changelog for more information.

Added

• Add a log format option for autodetection the log format.
• Add support for native OpenTelemetry spans from @elastic/transport package in Node.js.

Changed

• Detect the log format automatically. We now detect if a log line is in the JSON, Logfmt, or plaintext format. No further config needed when calling our logger, like so:

  JavaScript

  const logger = Appsignal.logger("app");
  logger.info("message");

Fixed

• Fix 'unknown' events being reported for some HTTP routes.

View the Node.js package v3.7.2 changelog for more information.

Changed

• Update the OpenTelemetry dependency to version 1.9 of the OpenTelemetry API. This improves compatibility with instrumentation libraries that depend on this version of the API.

View the Node.js package v3.7.1 changelog for more information.

Changed

• Disable the OpenTelemetry trace context propagation across applications. If multiple applications are instrumented with AppSignal for Node.js using OpenTelemetry, the propagation across applications could lead to application data being reported the wrong application in AppSignal.

View the Node.js package v3.7.0 changelog for more information.

Added

• Add nginxPort configuration option. This configuration option can be used to customize the port on which the AppSignal integration exposes the NGINX metrics server.

View the Node.js package v3.6.7 changelog for more information.

Changed

• Allow overriding namespaces that are automatically set by the AppSignal agent based on the OpenTelemetry instrumentation that emitted the span, such as the graphql or background namespaces.
• Log a debug message when the reported error is ignored by the ignore_errors config option.

Fixed

• Update mysql2 and pg instrumentations. This fixes an issue where queries performed using promises with mysql2@3.11.5 are not instrumented, as well as an issue where pg is not instrumented under certain bundlers and runtimes.

View the Node.js package v3.6.6 changelog for more information.

Changed

• Remove redundant cron check-in pairs. When more than one pair of start and finish cron check-in events is reported for the same identifier in the same period, only one of them will be reported to AppSignal.

View the Node.js package v3.6.5 changelog for more information.

Added

• Add support for OpenTelemetry histograms.
• Add support for Node.js 23

Removed

• Drop support for Node.js 16

View the Node.js package v3.6.4 changelog for more information.

Changed

• Improve SQL sanitisation for functions and numbered placeholders.

View the Node.js package v3.6.3 changelog for more information.

Changed

• Delay and eventually halt agent reboots by the extension.

  The AppSignal extension is responsible for booting the AppSignal agent. If communication with the agent is lost, the extension is responsible for rebooting it.

  In certain scenarios, such as when several processes with different AppSignal configurations are misconfigured to share the same working directory, the processes' extensions can enter a loop of rebooting and killing each others' agents. These short-lived agents may then attempt to repeatedly send pending payloads to AppSignal in quick succession.

  This change causes the extension to delay each reboot of its agent by one additional second, and to no longer attempt to reboot the agent after the tenth reboot, slowing down and eventually breaking this loop.

View the Node.js package v3.6.2 changelog for more information.

Changed

• Update Prisma instrumentation to version 6.4. This improves compatibility with new Prisma versions.

View the Node.js package v3.6.1 changelog for more information.

Changed

• Update span recognition following the OpenTelemetry Semantic Conventions 1.30 database specification. We now also sanitize SQL queries in the db.query.text attribute and Redis queries in the db.operation.name attribute.
• Bump the log message when no span is active and one of our sample data helpers are used like setParams, setSessionData, setCustomData, etc from debug to warning.
• Update bundled trusted root certificates

Removed

• Remove the OpenTelemetry beta feature in favor of the new AppSignal collector. If you are using the AppSignal agent to send OpenTelemetry data in our public beta through the /enriched endpoint on the agent's HTTP server, please migrate to the collector to continue using the beta. The collector has a much better implementation of this feature for the beta.

View the Node.js package v3.6.0 changelog for more information.

Fixed

• Fix a performance issue when sanitising INSERT INTO ... VALUES queries.

View the Node.js package v3.5.5 changelog for more information.

Fixed

• Allow Pino transport to be used as a transport. Before, our Pino transport could only be used as a destination:

  Node.js

  import pino from "pino";

  JavaScript

  import pino from "pino";
  import { Appsignal, AppsignalPinoTransport } from "@appsignal/nodejs";
   
  pino(
    AppsignalPinoTransport({
      client: Appsignal.client,
      group: "pino",
    }),
  );

  This meant it was not possible to log both to our transport and to another destination.

  Now, it is also possible to use it as a Pino transport, with the transport Pino config option or the pino.transport() function:

  JavaScript

  import pino from "pino";
   
  pino({
    transport: {
      target: "@appsignal/nodejs/pino",
      options: {
        group: "pino",
      },
    },
  });

  It is no longer necessary to pass the AppSignal client to the Pino transport. AppSignal must be active for the Pino transport to work.

  By enabling its use as a transport, it is now possible to use it alongside other transports:

  JavaScript

  pino({
    transport: {
      targets: [
        // Send logs to AppSignal...
        { target: "@appsignal/nodejs/pino" },
        // ... and to standard output!
        { target: "pino/file" },
      ],
    },
  });

View the Node.js package v3.5.4 changelog for more information.

Added

• Set the app revision config option for Scalingo deploys automatically. If the CONTAINER_VERSION system environment variable is present, it will use used to set the revision config option automatically. Overwrite it's value by configuring the revision config option for your application.

Fixed

• Fix an issue where the extension fails to build on ARM64 Linux.

View the Node.js package v3.5.3 changelog for more information.

Added

• Add Fastify v5 compatibility

View the Node.js package v3.5.2 changelog for more information.

Added

• A Pino transport is now available. If Pino is your main logger, you can now use the AppSignal pino transport to send those logs to AppSignal.

  JavaScript

  import pino from "pino";
  import { Appsignal, AppsignalPinoTransport } from "@appsignal/nodejs";
   
  const logger = pino(
    AppsignalPinoTransport({
      client: Appsignal.client,
      group: "application",
    }),
  );

Changed

• Change the primary download mirror for integrations.

View the Node.js package v3.5.1 changelog for more information.

Added

• Add support for heartbeat check-ins.

  Use the checkIn.heartbeat method to send a single heartbeat check-in event from your application. This can be used, for example, in your application's main loop:

  JavaScript

  import { checkIn } from "@appsignal/nodejs";
   
  while (true) {
    checkIn.heartbeat("job_processor");
    await processJob();
  }

  Heartbeats are deduplicated and sent asynchronously, without blocking the current thread. Regardless of how often the .heartbeat method is called, at most one heartbeat with the same identifier will be sent every ten seconds.

  Pass {continuous: true} as the second argument to send heartbeats continuously during the entire lifetime of the current process. This can be used, for example, after your application has finished its boot process:

  JavaScript

  import { checkIn } from "@appsignal/nodejs";
   
  function main() {
    checkIn.heartbeat("job_processor", { continuous: true });
    startApp();
  }

Changed

• Send check-ins concurrently. When calling Appsignal.checkIn.cron, instead of blocking the current process while the check-in events are sent, schedule them to be sent in a separate process.
• Do not block Node.js shutdown. It is no longer necessary to call Appsignal.stop for the Node.js engine to allow itself to shut down. It should still be called and awaited in production scenarios and at the end of scripts, as it ensures that scheduled check-ins are delivered.

View the Node.js package v3.5.0 changelog for more information.

Changed

• Rename heartbeats to cron check-ins. Calls to Appsignal.heartbeat and Appsignal.Heartbeat should be replaced with calls to Appsignal.checkIn.cron and Appsignal.checkIn.Cron, for example:

  JavaScript

  // Before
  import { heartbeat } from "@appsignal/nodejs";
   
  heartbeat("do_something", () => {
    do_something();
  });
   
  // After
  import { checkIn } from "@appsignal/nodejs";
   
  checkIn.cron("do_something", () => {
    do_something;
  });

Deprecated

• Calls to Appsignal.heartbeat and to the Appsignal.Heartbeat constructor will emit a deprecation warning.

Fixed

• Prevent internal AppSignal requests from being instrumented and appearing in the "Slow API requests" panel.

View the Node.js package v3.4.9 changelog for more information.