New Feature: Add Custom Metrics For Node.js in AppSignal

Stefan Stefan Verkerk on

You can now monitor any metrics you’d like in your Node.js app with AppSignal. With custom metrics and minutely probes by your side, you’ll now have an excellent overview of your app.

If you’ve ever thought “I wish we measured this specific thing so I could monitor better what is going on…”, then this feature is perfect for you.

Easy to Set Up and Customize

We design and build AppSignal in such a way that it makes it the easiest to use APM. We always aim to build something very smooth and then give you the same building blocks we used. This way, you can further customize your monitoring, dashboards, and alerts if you want to.

In the last weeks and months, we’ve added auto instrumentation and magic dashboards to the Node.js integration of AppSignal. Today, we are talking about the power of the Custom Metrics feature we added.

Custom Metrics In Short

In all the languages and frameworks AppSignal supports, we let you send any type of metric you need. Those can be gauges, counters, or measurements. We support tags so you can model your use case perfectly. You can use these metrics in graphs, build these graphs in Dashboards, and finally set up alerting on these metrics.

Using Custom Metrics to Dive Deeper

Custom Metrics revolve around being able to add your domain knowledge into what you measure with AppSignal. Not everything is connected to measuring errors per se, or a queue time, or load in part of your architecture: we aim to automatically set up those for you. Custom Metrics are about things that are important indicators for your particular setup.

Let’s take a case where - not so randomly - you are running a Node.js app with a PostgreSQL database that has customers, items, and orders. You suddenly notice peaks in load times, and though technically there were no errors, and nothing literally broke, you wonder “what the %!! stroopwafel” happened.

It turns out someone’s browser accidentally added a million items to their basket, leading to all sorts of long queries when checking out. You then decide that you want to measure the number of items in all baskets active at a certain point. The next time something similar happens, you can get an alert for it.

Diving Into Custom Metrics

With custom metrics, you can add metrics of different kinds: you can add gauges, measurements, or counters. We will go through what each of these are, so we know which one makes the most sense in our example. These metrics can be used for graphs that you can combine in a single dashboard, similar to the following one.

example AppSignal dashboard

Measurement

Measurements are best for things like response times. This lets you track a metric that can have a lot of variation in values, and summarize those variations in their average and 90th as well as 95th percentiles.

A measurement metric will create the following metric fields:

COUNT, which counts how many times the helper was called. MEAN, the average metric value for the point in time. P90, the 90th percentile of the metric value for the point in time. P95, the 95th percentile of the metric value for the point in time.

In our example with articles in baskets, your code could look like this:

1
2
3
4
5
6
7
8
9
const meter = appsignal.metrics()

// The first argument is a string, the second argument a number
// meter.addDistributionValue(metric_name, value)
meter.addDistributionValue("article_count_inbasket", 100)
meter.addDistributionValue("article_count_inbasket", 2)

// Will create a metric "article_count_basket" with the mean field value 51
// Will create a metric "article_count_basket" with the count field value 2

Gauge

The second metric you can use is gauge: a metric value, as measured on a specific time.

Gauges can be used to track sizes of databases, disks, or other absolute values like CPU usage, a number of items (users, accounts, etc.), and things like that. Under the hood, the AppSignal host metrics are stored as gauges for example.

1
2
3
4
5
6
7
8
const meter = appsignal.metrics()

// The first argument is a string, the second argument a number
// meter.setGauge(metric_name, value)
meter.setGauge("database_size", 100)
meter.setGauge("database_size", 10)

// Will create the metric "database_size" with the value 10

Counter

The third metric you can set is the counter: it stores a numeric value for a time frame.

These values are combined to the sum of the values for the selected time frame. So, when you view a graph with resolution by minutes it will combine the values of the given minute. But when you set the graph to a resolution of hours, you will see the sum per hour.

Counters are best to track events. Whereas a gauge is great to track how many users there are at a specific time, with counters you can track how many events occurred at a specific time (users signing in, comments being made, etc.).

When the helper is called multiple times, the sum of the values in the calls is kept. Whereas with a gauge, the last value is kept.

Here is an example of how you call a counter:

1
2
3
4
5
6
7
8
const meter = appsignal.metrics()

// The first argument is a string, the second argument a number
// meter.incrementCounter(metric_name, value)
meter.incrementCounter("article_added_count", 1)
meter.incrementCounter("article_added_count", 1)

// Will create the metric "article_added_count" with the value 2 for a point in the minutely/hourly resolution

Let’s Play With Lego AppSignal Blocks!

Now that we have these metrics in, we have the building blocks to build more. We can then build graphs (which just got way smoother), combine these in a dashboard and set up alerting. Enjoy playing!

In the next weeks and months, we will make AppSignal for Node.js even smoother with more auto instrumentation and dashboards. It is already pretty smooth: Go and check it out!

10 latest articles

Go back
Ruby magic icon

Subscribe to

Ruby Magic

Magicians never share their secrets. But we do. Sign up for our Ruby Magic email series and receive deep insights about garbage collection, memory allocation, concurrency and much more.

We'd like to set cookies, read why.