2016-12-29 5 views
4

В моем приложении node.js всякий раз, когда я получаю запрос, я хотел бы «штамповать» его с помощью некоторого уникального идентификатора и отслеживать все действия (заявления журнала), связанные с этим запрос по этому идентификатору. Поэтому, когда приходит запрос, и я передаю его передачу в нижние уровни приложений (службы, вызовы базы данных и т. Д.), Я хочу, чтобы собрать все журналы, соответствующие данному идентификатору запроса, для восстановления своего путешествия через приложение.отслеживание потока запросов по ID в node.js

Итак, имея этот снимок, теперь я использую модуль request-local, но он совершает какую-то тяжелую магию, которая только что сбила меня (журналы из нескольких запросов получают одинаковый идентификатор).

Этот код в основном основан на Promises (не обычные обратные вызовы старого узла), и я использую функции более высокого порядка для обеспечения зависимостей от моих фактических функций (с созданием дерева приложений во время запуска).

Первое и вполне очевидное решение состоит в том, чтобы передать этот идентификатор запроса каждой вызываемой функции, но это катастрофа, и я не собираюсь этого делать.

Как вы (надежно) выполняете такое отслеживание запросов, явно не передавая этот id/context в качестве дополнительного аргумента для работы на всех уровнях вниз?

+0

Что вы собственно вопрос? –

+0

Да, не было достаточно явным. Отредактировано сейчас. –

ответ

0

Я считаю, что то, что вы ищете, является логическим идентификатором потока, который должен быть уникальным и сгенерирован при каждом новом запросе на вашем бэкэнде. Если это предположение верно, то, что я обычно делаю, это создать промежуточное ПО на моем экспресс-маршрутизаторе для генерации нового и случайного идентификатора потока (с randomstring). Чтобы убедиться, что этот идентификатор потока уникален, я добавляю к нему временную метку. Для того, чтобы передать этот идентификатор потока к следующему, мы должны промежуточному программному хранить его под res.locals (here the documentation) Ваших промежуточный слой может выглядеть следующим образом:

//middleware flow.js 
var random = require('randomstring'); 

var generate = function(){ 
    var dt = new Date(); 
    return random.generate() + dt.toISOString(); 
} 
module.exports.createID = function(req, res, next){ 
    //store flowid in res - this hold state over the request life time 
    res.locals.flowid = generate(); 
    next(); 
} 

Теперь мы можем вводить это промежуточное программное обеспечение на приложении с помощью:

var flowcontrol = require('flow.js'); 
var middleware = require('middleware.js'); 

app.use(flowcontrol.createID); 

//route example 
app.get('/api/awesomeresource', middlewares.first, middlewares.second); 

Используя этот подход, вы сможете войти и тот же идентификатор потока на каждом промежуточном типе:

//middleware.js 
module.exports.first = function(req, res, next){ 
    console.log(res.locals.flowid + " - First i did this..."); 
    //your logic here 
    next(); 
} 
module.exports.second = function(req, res, next){ 
    console.log(res.locals.flowid + " - Second i did this..."); 
    //your logic here before the response 
    res.sendStatus(200); 
} 

результат GET /api/awesomeresource HTTP/1.1 будет следующий лог консоли:

> R90A56nEmZWYK73NOEVbWv2RS6DolO4D2017-12-07T10:29:39.291Z - First i did 
> this... 
> R90A56nEmZWYK73NOEVbWv2RS6DolO4D2017-12-07T10:29:39.291Z - 
> Second i did this... 

Это означает, что вы можете отслеживать какие-то файлы журналов с помощью этой марки и отладки серверной логики при необходимости.

Приветствие

2

Я сделал подход, в котором идентификатор будет уникален по запросу и вам не нужно будет проходить какой-либо объект (REQ, ID ...) среди различных вызовов и модулей. Это подразумевает использование одной библиотеки для создания уникальных идентификаторов, я выбрал node-uuid и другую библиотеку для обмена переменными контекста среди разных модулей (продолжение-локальное хранилище), но с использованием пространств имен по запросу, чтобы сохранить идентификатор для всех звонки (даже асинхронные). Кроме того, я завернул библиотеку Winston, чтобы распечатать идентификатор запроса в каждом журнале. С этим вы сможете отслеживать все журналы одного запроса.

Я написал полное объяснение с кодом примера здесь https://solidgeargroup.com/express-logging-global-unique-request-identificator-nodejs

Смежные вопросы