const promBundle = require('restify-prom-bundle');
const restify = require('restify');

const server = restify.createServer({ /* options */ });

server.pre(promBundle.preMiddleware(server, { /* options */ }));

server.get('/api', (req, res) => {
  // Custom metrics can be added by using the client.
  const counter = new promBundle.client.Gauge(
    'my_custom_counter',
    'My custom counter'
  );

  counter.inc();
  res.end('OK');
});

server.listen(8000);

// The /metrics route is now available with metrics.

Since prom-client is a singleton, it can be accessed from everywhere by just require'ing / import the module, aggregated metrics will be exposed on the route.

Creates the restify pre-middleware to

• Creates the expose route used by prometheus server to index metrics
• Setup default metrics you want to measure

Options :

Default metrics :

duration metrics precision will depends on the pre-middleware registering order, the sooner you register (first server.pre() call), the better it will be.

Singleton instance of prom-client to set custom metrics.

If a huge number of different non-routed requests (404) are sent to the server, the process will have to keep a restify_path_count label for each one and the process memory will increase undefinitively. In addition, the prometheus (and grafana) service that uses this probes will be flooded. To prevent this situation, number of measured paths are limited to maxPathsToCount.

This does not affect restify_path_duration as it only measures the restify-defined paths, nor restify_status_codes as it's limited to HTTP status codes.

Once maxPathsToMeasure paths are measured, every new paths will be ignored for restify_path_duration and restify_path_count.

A sample grafana dashboard can be found here .