Function createMetrics

lib/plugins/metrics.js:48–94

* The module includes the following plugins to be used with restify's `after` * event, e.g., `server.on('after', restify.plugins.metrics());`: * * A plugin that listens to the server's after event and emits information * about that request. * * @public * @function metrics * @param {Object} o

(opts, callback)

 * }));
 */
function createMetrics(opts, callback) {
    assert.object(opts, 'opts');
    assert.object(opts.server, 'opts.server');
    assert.func(callback, 'callback');

    return function metrics(req, res, route, err) {
        var data = {
            // response status code. in most cases this should be a proper
            // http status code, but in the case of an uncaughtException it can
            // be undefined. otherwise, in most normal scenarios, even calling
            // res.send() or res.end() should result in a 200 by default.
            statusCode: res.statusCode,
            // REST verb
            method: req.method,
            // overall request latency
            totalLatency: hrTimeDurationInMs(req._timeStart, req._timeFinished),
            latency: hrTimeDurationInMs(req._timeStart, req._timeFlushed),
            preLatency: hrTimeDurationInMs(req._timePreStart, req._timePreEnd),
            useLatency: hrTimeDurationInMs(req._timeUseStart, req._timeUseEnd),
            routeLatency: hrTimeDurationInMs(
                req._timeRouteStart,
                req._timeRouteEnd
            ),
            // the cleaned up url path
            // e.g., /foo?a=1 => /foo
            path: req.path(),
            // connection state can currently only have the following values:
            // 'close' | undefined.
            //
            // if the connection state is 'close'
            // the status code will be set to 444
            // it is possible to get a 200 statusCode with a connectionState
            // value of 'close'. i.e., the client timed out,
            // but restify thinks it "sent" a response. connectionState should
            // always be the primary source of truth here, and check it first
            // before consuming statusCode. otherwise, it may result in skewed
            // metrics.
            connectionState: req.connectionState && req.connectionState(),
            unfinishedRequests:
                opts.server.inflightRequests && opts.server.inflightRequests(),
            inflightRequests:
                opts.server.inflightRequests && opts.server.inflightRequests()
        };

        return callback(err, data, req, res, route);
    };
}

/**
 * Callback used by metrics plugin