在我过去的日子里,我曾经在企业界担任开发人员、技术主管、架构师等工作。在那些日子里,我很少担心我们应该如何进行日志记录和监控。我们总是有工具、手段和方法来获得 end 2 end 的可见性。

后来,我和合伙人共同创办了一家初创公司,我不得不选择我们的技术堆栈。我永远是一个 .net 人,而他是一个 laravel 专业人士,我们继续使用 node.js 🙂(出于多种原因,但这是另一个故事)。

回到日志记录,我们需要的是能够保存传入请求的整个生命周期。这意味着请求正文/标头信息、服务层调用和相应的响应、数据库调用等。此外,我们当时想使用微服务(同样,另一个故事有很多优点和缺点)。所以整个生命周期还包括微服务之间的来回通信。所以我们需要一个请求 id,用它我们可以过滤日志并按时间排序。让我将其分解为单独的步骤:

UI:我们在前端使用 SPA。 UI 对我们的 API 进行 HTTPs 调用。

API 层:我们在 API 中的业务服务是使用注入依赖项的工厂实例化的。所以理论上你可以创建一个自定义记录器,用“request-id”丰富它,并将记录器注入到业务服务中供开发人员使用,这样他们就可以在需要的时候进行记录。但是感觉日志记录不是我们可以根据自己的喜好决定的。我们需要的是一种自动刷新数据的方法。此外,日志还会降低可读性,并且可能会导致错误。 (理论上,业务逻辑代码不应该被额外的日志代码“污染”)。为了完成这项任务,我们的工厂不是将记录器注入到服务中,而是使用自我记录功能(使用内部记录库)包装服务功能,这只是添加了另一层 Javascript 承诺来捕获输入参数和解析响应对象。这样,所有输入和返回值都可以在内部日志库中使用,用于丰富(方法名称、函数开始/结束时间、服务器 ip、微服务名称、经过的持续时间等)和日志记录。作为开发人员,我们不必担心它,并且知道系统将以格式良好的方式捕获所需的所有内容。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--sxGYsa2F--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https:// dev-to-uploads.s3.amazonaws.com/uploads/articles/wluf00wgsfw7ycarv0cm.png)

微服务通信:我们创建了另一个内部库,即“Request Promise Native”的分叉版本。它可以帮助我们的开发人员注入带外请求 ID 信息,以便目标微服务可以在其底层服务的整个生命周期中读取和使用它。这意味着,我们所有的微服务都能够读取传入的请求 ID 并将其转发给传出的微服务调用。

记录器:请注意,请屏蔽您的消息,不要记录任何敏感数据!我过去看过带有 PII 或信用卡信息的日志,请不要这样做。您的用户依赖于您,这是您的责任!无论如何,那里有大量优秀的日志库。我们决定使用 Winston,因为,

1-温斯顿很好

2-它支持 Graylog2,这将我们带到下一个项目:

日志存储库:在过去 10 年左右的时间里,我不记得有一次我必须检查服务器日志文件以进行监控/调试。在其他所有来自不同请求的文件之后,用一行日志遍历这些文件是不切实际的。它根本无济于事,实际上在我曾经工作过的一家美国银行中,Devops 的人建议我们可以简单地停止创建它们。当然,这并不意味着您可以停止记录。 “Au contraire!”,拥有一个日志存储库非常重要,您可以在其中搜索、过滤、导出和管理您的日志。因此,我们将选项减少到以下工具:

-Splunk

-灰色日志

我们选择 Graylog 是因为我们有管理 Graylog 服务器的经验,它是一个开源工具(意味着成本要低得多,因为它只需要一个中型服务器)并且可以完成这项工作。

您的日志将向您展示有关您的应用程序的大量见解,并可能帮助您发现错误。我的团队会在每次发布之前定期检查日志,以了解我们是否要引入任何新的意外错误。使用 Graylog 之类的工具,您可以为不同的场景(http 响应代码、应用程序错误代码等)创建警报,这样您甚至可以在客户看到错误消息之前就知道存在问题。您的 QA 团队可以在工单中插入请求 ID,以便开发人员可以跟踪测试时究竟发生了什么。如果您想深入了解,我记得使用 Splunk 日志通过近实时和批量分析来缓解欺诈行为。无论出于何种原因,我们使用日志,我们想要它们,拥抱它们,爱它们:)