View the Node.js package v3.4.8 changelog for more information.
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.
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.
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.
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 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.
ignoreLogs
configuration optionAdd 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 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.
Appsignal.stop()
must be awaitedAppsignal.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.
See the Node.js 3.2.0 package changelog for more information.
See the Node.js 3.3.0 package changelog for more information.
appsignal
configuration file.See the Node.js 3.1.0 package changelog for more information.
df --local
command fails.appsignal_set_host_gauge
and appsignal_set_process_gauge
extension functions. These functions were already deprecated and did not report any metrics.demo_sample
tag was set incorrectly as an attribute.See the Node.js 3.0.30 package changelog for more information.
See the Node.js 3.0.29 package changelog for more information.
Remove route
tag from HTTP server spans. Since the span will already have the route attribute as part of its name, the tag is redundant.
Filter more disk mountpoints for disk usage and disk IO stats. This helps reduce noise in the host metrics by focussing on more important mountpoints.
The following mountpoint are ignored. Any mountpoint containing:
/etc/hostname
/etc/hosts
/etc/resolv.conf
/snap/
/proc/
method
tag extracted from an incoming HTTP request span would be overriden with the method used for an outgoing HTTP request span.df
) on Alpine Linux. This host metric would report an error on Alpine Linux.See the Node.js 3.0.27 package changelog for more information.
See the Node.js 3.0.28 package changelog for more information.
See the Node.js package 3.0.26 changelog for more information.
initializeOpentelemetrySdk
configuration optionThe initializeOpentelemetrySdk
configuration option allows those who
would rather take control of how OpenTelemetry is initialised in their
application to skip AppSignal's initialization of the OpenTelemetry SDK.
Additionally, add an opentelemetryInstrumentations
method on the client,
which returns AppSignal's default OpenTelemetry instrumentations, already
configured to work correctly with AppSignal. The provided list of
instrumentations will follow the additionalInstrumentations
and
disableDefaultInstrumentations
config options, if those are set.
This is not the recommended way to use AppSignal for Node.js. Only use this config option and this method if you're really sure that you know what you're doing.
When initialising OpenTelemetry, it is necessary to add the AppSignal span processor in order for data to be sent to AppSignal. For example, using the OpenTelemetry SDK:
import { SpanProcessor, Appsignal } from "@appsignal/nodejs"; // or: const { SpanProcessor, Appsignal } = require("@appsignal/nodejs") const sdk = new NodeSDK({ spanProcessor: new SpanProcessor(Appsignal.client) instrumentations: Appsignal.client.opentelemetryInstrumentations() }); sdk.start()
The above snippet assumes that the AppSignal client has been initialised beforehand.
When making use of this config option, the OpenTelemetry instrumentations
must be configured in the same way as it is done in the AppSignal integration.
In the above snippet, the instrumentations
property in the OpenTelemetry SDK
is set to the AppSignal client's list of OpenTelemetry instrumentations, which
are configured to work correctly with AppSignal.
setSqlBody
tracing helperThe setSqlBody
tracing helper sets the body attribute on a span that contains a SQL query. When using this helper the given SQL query will be sanitized, reducing the chances of sending sensitive data to AppSignal.
import { setSqlBody } from "@appsignal/nodejs"; // Must be used in an instrumented context -- e.g. an Express route setSqlBody("SELECT * FROM users WHERE 'password' = 'secret'"); // Will be stored as: "SELECT * FROM users WHERE 'password' = ?"
When the setBody
helper is also used, the setSqlBody
overwrites the setBody
attribute.
More information about our tracing helpers can be found in our documentation.
See the Node.js package 3.0.25 changelog for more information.
Updated the AppSignal agent with the following features:
memory_in_percentages
and swap_in_percentages
host metrics that represent metrics in percentages./snap/
disk mount points.Updated the OpenTelemtry Fastify integration to be compatible with Fastify v5.
See the Node.js package 3.0.24 changelog for more information.
AppSignal offers a 30-day free trial, no credit card is required. All features are available in all plans. Start monitoring your application in just a few clicks!