Logging 如果可以'；不能有效地映射回？

我最近遇到了最愚蠢的应用程序日志实现，开发人员实际上将日志分为验证日志文件+业务逻辑日志文件

例如，对于一个正常的流程，用户将购买一些计划，并进行某种验证，然后对其进行处理（例如保存到数据库中）

因此，对于分离的日志，它会

进入business.log查找事件序列，然后跳转到validation.log查找与用户相关的验证日志，然后跳回business.log查找延续

更糟糕的是，除了猜测时间戳，可能还有在日志之间传递的输入值（名称），没有确定的方法在日志之间映射

因此，在调试生产bug时，在这两个文件之间切换会变得非常混乱

---

问题是，有许多用户和事务同时进行。当询问开发人员这样做的意图时，他们的回答是，日志被正确分割。我觉得这个理由很可笑，有没有人见过一些有效日志记录的参考资料？或者有人认为这种记录方式在企业中很正常吗？

如果日志有正确的时间戳，则没有什么区别。如果需要，您可以轻松地将它们合并到单个文件中。如果它们的时间戳不够详细，你不能把它们结合起来，那么我同意你的观点，这是荒谬的。你需要能够计算出事件的顺序

---

坦率地说，日志文件需要跟上进度。它们应该使用灵活的查询语言（如SQL）存储在数据库中。您可以根据需要将数据库简单地转换为一个或多个文件，以供仍希望这样做的人使用。

IMHO有合理的理由分离日志。也许其中包含敏感信息。也许其中一个写得更频繁，很少使用。为了简单或安全起见，也许可以打开/关闭一个

---

不管是什么原因，在每条消息中记录一个事务ID或用户ID肯定会有帮助。

我同意你的看法，但是如果有那么多事务在进行，那么在一秒钟内，可能会有10个用户的验证日志交织在一起并同时进行？如果是在两个日志或一个日志中，我不认为这会更容易或更难，假设您可以根据需要按时间戳组合日志。你不能在一个文件中按用户来分隔日志，你会有太多的文件。这是DB的另一个好处，您可以在DB中按用户进行分离。David，如果日志包含在一个文件中，那么事件的顺序对于跟踪目的来说是非常连续的，如果您了解我的话。如果它们有时间戳（或顺序），它们可以从多个文件中轻松组合。我同意，如果他们没有为您提供足够的信息来轻松确定记录到单独文件中的从属事件的顺序，那么日志记录就被破坏了。