During the last few months, we've been working hard on improving our Node.js integration. We've released loads of quality fixes and improvements to our diagnose command, configuration, and general package structure. Today, we'd like to highlight some of the enhancements and fixes that we've recently released.

Config Options

enableStatsd (since 2.2.2)

The AppSignal agent can run a StatsD server on localhost:8125 by default, allowing you to compile metrics from all the components of your infrastructure. These custom metrics can be displayed within AppSignal.

If you, like us, prefer to have all your app monitoring in the same place while keeping it simple, this feature may help you do that. It allows you to send your custom gauges, counters, and timers to the StatsD server, and the Agent will take care of sending it to AppSignal so you can build custom dashboards with the information.

The StatsD server is disabled by default.

Check our docs for usage instructions.

filterParameters & filterSessionData (since 2.2.5)

If you're a long-time user of our AppSignal integration, you might remember that these two options were documented before this version. Sadly, they were not working as expected, so we revisited them and made a few fixes here and there.

The two options allow you to provide a list of parameters from web requests and session data that you don't want shown on AppSignal.

Example:

const appsignal = Appsignal.new({
  // other config options
  filterParameters: ["password", "password_confirmation"],
  filterSessionData: ["token", "name"],
});

This configuration example will ensure that if your web requests contain those parameters and/or session data, they'll be completely filtered from our systems. When looking at your requests within AppSignal, filtered fields will be displayed as password: [FILTERED].

Read more about parameter filtering and session data filtering on AppSignal docs.

requestHeaders (since 2.2.5)

This config option is an allowlist that will take the defined HTTP headers from your web requests to display them in AppSignal. It includes a list of the most common HTTP headers by default.

As with filterParameters and filterSessionData, the requestHeaders option works by deciding what request headers to filter or not. Note that as this one is an allowlist, the values configured are the ones that you actually want to be displayed in AppSignal.

Example:

const appsignal = Appsignal.new({
  // other config options
  requestHeaders: ["user-agent", "accept"],
});

With this config, you'll only see the values of the user-agent and accept headers from your app's requests in AppSignal. The rest will be displayed as [FILTERED].

Check the requestHeaders option docs for usage instructions.

sendParams (since 2.2.8) & sendSessionData (since 2.2.9)

If you want to completely filter all the request parameters and session data for privacy—or you just consider it non-relevant information—these two options will help with that.

Both are enabled by default.

Example:

const appsignal = Appsignal.new({
  // other config options
  sendParams: false,
  sendSessionData: false,
});

This config will completely filter out all params and session data. Note that if you have some values on filterParameters or filterSessionData, they'll be ignored as this config option has more priority.

Check the sendParams option docs for usage instructions.

active and enableMinutelyProbes from Environment Variables (since 2.3.0)

Before this minor version, setting these config options using the documented APPSIGNAL_ACTIVE and APPSIGNAL_ENABLE_MINUTELY_PROBES environment variables had no effect.

Minutely probes are great if you want to check up on your resources setting gauges that will be sent to AppSignal every minute after the probe is created. Check our docs on the active config option and the enableMinutelyProbes config option for usage instructions.

Fixed Behavior and General Improvements

AppSignal Logs Available on Heroku and Dokku (since 2.2.5)

Previously, when the host was detected as a Heroku dyno, the log output wasn't sent to "stdout". Now, the behavior has been fixed and it properly sends the log to "stdout" when on a Heroku dyno. This way, it's easier to access AppSignal logs within Heroku and Dokku.

For more information, see our log config option docs.

AppSignal Extension Is No Longer a Separate Dependency (since 2.3.0)

Before this minor version, the AppSignal Extension was installed as an optional dependency of the Node.js library. That meant that if the extension installation failed for some reason, the package would not be installed at all. That was problematic, as the library fetched some essential debug and diagnostic data from that package, that was not available if the package failed to install. This made our support more difficult.

With the extension package merged into the core Node.js package, the two most important benefits are:

• The extension installation no longer fails on unsupported systems, or when it encounters an unexpected error that caused the package to be removed from the file system.
• All important values are now present within the same package, so the diagnose report always includes all report values.

We’re Still Working on More Improvements

We'll keep you updated on more important changes in the Node.js library. In the meantime, we are eager to hear your suggestions and to fix possible issues, so don't hesitate on contacting our support team whenever you want to.

Track Your Node.js Errors with a Stroopwafel by Your Side 🍪

If you haven't yet tried AppSignal for monitoring your Node.js apps, take five minutes and check it out. Here's what you need to know:

• Error monitoring is included alongside all of our features.
• We have a free trial option that doesn't require a credit card.
• AppSignal supports Node.js, Ruby, and Elixir projects.
• We're free for open source & for good projects.
• We ship stroopwafels to our trial users on request.