【问题标题】:Identify context in Nodejs在 Nodejs 中识别上下文
【发布时间】:2018-12-10 08:23:23
【问题描述】:

目前我们的项目正在通过类中的静态方法处理日志记录。我们使用事务 id 来跟踪请求的日志,不会与另一个请求的日志混淆。

但这有一个并发问题。

  1. request1 设置事务 id(静态)
  2. request2设置事务id(另一个)
  3. request1 记录,然后它使用 request2 的 id。

我们的架构师建议实例化一个记录器并将其作为参数传递给所有函数,但这很烦人,因为有很多函数调用,所以这意味着添加一个从功能角度看没有意义的新参数到数百个功能。

我认为任何其他解决方案都需要一种方法来在任何函数中区分它属于哪个上下文,我的意思是,哪个请求调用了该函数。

我是nodejs的新手,有什么全局变量或其他机制可以帮助我吗?

【问题讨论】:

  • 为什么不使用流行的日志库之一?
  • 老实说,我不知道。他们的日志系统早在我进入项目之前就已经存在。他们的类使用 log4js 进行日志记录,但将其包装起来,增加了复杂性和行为。无论如何,我不能删除这个库,但如果我能找到一种方法来区分请求,我可以使新的更改更容易。
  • 将事务ID存储在请求对象本身中怎么样?
  • 请求没有传递给大部分函数。我们通常从请求中获取信息并调用其他函数来完成任务。例如,假设我们从输入中获取身高和体重并调用函数 calculateBMI(height, weight)。我需要登录该功能,但我没有请求。 (这只是一个例子,应用程序比较复杂,有很多嵌套的函数调用)
  • 您必须通过所有函数传递该事务 id 或记录器本身,没有办法。但是,由于您可能会通过所有函数传递一些数据,因此您可以将 id 附加到该数据。 (我很好奇是否有人提出了更好的方法,我现在面临同样的问题)

标签: javascript node.js logging


【解决方案1】:

有一个blog 分享如何实现这一点。

我查看了它使用的库,它指的是cls-hooked,它使用了一些内部/实验性 Node.js 功能。

因此,不太建议在生产中使用。

已编辑

最近在学习https://zipkin.io时发现了一个库。它使用https://github.com/othiym23/node-continuation-local-storage 来跟踪线程本地存储等值。值得一看

【讨论】:

  • 你把我放在了 express-http-context 的轨道上,我认为这足以制作解决方案,但由于你对生产用途表达的担忧,我不确定。跨度>
  • @Mu_ 作为使用中的内部/实验功能,每次升级 Node.js 时都需要注意将其应用到生产环境中。如果这是一个有用的答案,我希望你能帮助标记它是有帮助的。谢谢。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-07-17
  • 2015-01-12
  • 2016-06-09
  • 1970-01-01
相关资源
最近更新 更多