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.

Fixed

• Fix different spans of the same category incorrectly being reported with the same body.

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

Changed

• Update OpenTelemetry dependencies.

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

Fix an issue where a later span close time than accurate, and therefore a longer span duration, is reported to AppSignal under certain circumstances.

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

Automatic BullMQ instrumentation

Add BullMQ support through the @appsignal/opentelemetry-instrumentation-bullmq instrumentation. AppSignal will automatically instrument the use of BullMQ in your application.

Calls to functions that enqueue jobs, such as Queue.add and others, will be instrumented as an event in the event timeline for the performance sample in which it takes place.

When a BullMQ Worker processes a job, this will result in a performance sample in the background namespace.

Added

• Add basic OpenTelemetry messaging support. This adds support for any OpenTelemetry instrumentation that complies with the OpenTelemetry Semantic Conventions specification for messaging.

Changed

• Rename the hostname tag, which contains the host of the URI that an HTTP request was made against, to request_host. This fixes an issue where the hostname tag would later be internally overriden to the hostname of the machine processing the request, but notifications would still be emitted containing the previous hostname value.

• Improve the amqlib instrumentation by parsing it like other messaging spans following the OpenTelemetry messaging spec.

Fixed

• Fix an issue where Redis events are misidentified as HTTP events.

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

Instrument calls to fetch in Node.js. Requests made using Node.js' global fetch, or through the underlying undici library, will be automatically instrumented and shown as events in your performance samples' event timeline.

Support Kamal-based deployments. Read the KAMAL_VERSION environment variable, which Kamal exposes within the deployed container, if present, and use it as the application revision if it is not set. This will automatically report deploy markers for applications using Kamal.

See the Node.js package 3.4.4 changelog for more information.

Added

Added support for amqplib. All spans containing amqplib will now have child spans related to the amqplib operations.

See the Node.js package 3.4.2 changelog for more information.

Added

ignoreLogs configuration option

Add the ignoreLogs configuration option, which can also be configured as the APPSIGNAL_IGNORE_LOGS environment variable.

The value of ignoreLogs is a list (comma-separated, when using the environment variable) of log line messages that should be ignored. For example, the value "start" will cause any message containing the word "start" to be ignored. Any log line message containing a value in ignoreLogs will not be reported to AppSignal.

The values can use a small subset of regular expression syntax (specifically, ^, $ and .*) to narrow or expand the scope of lines that should be matched.

For example, the value "^start$" can be used to ignore any message that is exactly the word "start", but not messages that merely contain it, like "Process failed to start". The value "Task .* succeeded" can be used to ignore messages about task success regardless of the specific task name.

Heartbeats

Heartbeats are currently only available to beta testers. If you are interested in trying it out, send an email to support@appsignal.com!

Add heartbeats support. You can send heartbeats directly from your code, to track the execution of certain processes:

import { heartbeat } from "@appsignal/nodejs";
 
function sendInvoices() {
  // ... your code here ...
  heartbeat("send_invoices");
}

You can pass a function to heartbeat, to report to AppSignal both when the process starts, and when it finishes, allowing you to see the duration of the process:

import { heartbeat } from "@appsignal/nodejs";
 
function sendInvoices() {
  heartbeat("send_invoices", () => {
    // ... your code here ...
  });
}

If an exception is raised within the function, the finish event will not be reported to AppSignal, triggering a notification about the missing heartbeat. The exception will bubble outside of the heartbeat function.

If the function passed to heartbeat returns a promise, the finish event will be reported to AppSignal if the promise resolves. This means that you can use heartbeats to track the duration of async functions:

import { heartbeat } from "@appsignal/nodejs";
 
async function sendInvoices() {
  await heartbeat("send_invoices", async () => {
    // ... your async code here ...
  });
}

If the promise is rejected, or if it never resolves, the finish event will not be reported to AppSignal.

Changed

Appsignal.stop() must be awaited

Appsignal.stop() now returns a promise. For your application to wait until AppSignal has been gracefully stopped, this promise must be awaited:

import { Appsignal } from "@appsignal/nodejs";
 
await Appsignal.stop();
process.exit(0);

In older Node.js versions where top-level await is not available, terminate the application when the promise is settled:

import { Appsignal } from "@appsignal/nodejs";
 
Appsignal.stop().finally(() => {
  process.exit(0);
});

See the Node.js package 3.4.0 changelog for more information.

Implement CPU count configuration option. Use it to override the auto-detected, cgroups-provided number of CPUs that is used to calculate CPU usage percentages.

To set it, use the the cpuCount configuration option or the APPSIGNAL_CPU_COUNT environment variable.

Fix UNKNOWN HTTP method in Next.js 14 performance incidents.

See the Node.js 3.3.3 package changelog for more information.

In previous versions of the Node.js integration, environment variables were evaluated to read their values. This version instead parses them based on their expected values.

Added

• Add histogram support to the OpenTelemetry HTTP server. This allows OpenTelemetry-based instrumentations to report histogram data to AppSignal as distribution metrics.

Changed

• Breaking change: Normalize CPU metrics for cgroups v1 systems. When we can detect how many CPUs are configured in the container's limits, we will normalize the CPU percentages to a maximum of 100%. This is a breaking change. Triggers for CPU percentages that are configured for a CPU percentage higher than 100% will no longer trigger after this update. Please configure triggers to a percentage with a maximum of 100% CPU percentage.
• Support fractional CPUs for cgroups v2 metrics. Previously a CPU count of 0.5 would be interpreted as 1 CPU. Now it will be correctly seen as half a CPU and calculate CPU percentages accordingly.
• f99d4c5 patch - Update bundled trusted root certificates.

Fixed

• Fix (sub)traces not being reported in their entirety when the OpenTelemetry exporter sends one trace in multiple export requests. This would be an issue for long running traces, that are exported in several requests.

See the Node.js 3.2.0 package changelog for more information.

Added

• Added support for Apollo Federation Gateways. Queries sent to the supergraph will now be instrumented.

See the Node.js 3.3.0 package changelog for more information.

Added

• OpenTelemetry instrumentations that emit metrics are now automatically extracted and reported to AppSignal. The metric provider is also globally available for you to send custom metrics using OpenTelemetry. Only gauges and counters are supported at the moment.

Fixed

• An issue with boolean options not being correctly parsed in the appsignal configuration file.
• An issue with MySQL queries with leading type indicators not being correctly sanitized.

See the Node.js 3.1.0 package changelog for more information.