随着时间的推移记录计划的过程

Question

我们在其中一个计划每小时运行的系统中实施了一个流程。该流程应运行从遗留系统导入的一些记录，进行一些资格更改，并更新记录状态和资格说明。

以下是有关此过程的一些事实：

1. 每天可以处理 1000 条记录。
2. 限定单个记录涉及复杂的逻辑路径。在某些时候，我们需要调试并了解特定记录是如何合格或不合格的。获得合格或不合格的逻辑路径。

我想知道：

1. 如果有任何设计模式或架构可用于为此类计划进程应用有效的日志记录。
2. 在为此流程实施我们的日志记录机制时，哪些信息被认为是必不可少的？
3. 在这种情况下哪个更好：将日志存储在数据库或文件系统中？如果数据库日志记录更好，是否有任何首选设计？

如果有任何文章或参考资料可以提供有关记录计划进程操作的最佳实践的更多详细信息，我将不胜感激。

Answer 1

为了回答您的问题，我需要知道日志的用途是什么。我会做一些猜测，但如果你能扩展你的问题，那会有所帮助。

通常，在应用程序中包含登录功能有 2 个原因。

应用监控

对于这些无人参与的进程，您需要确保它们仍在运行，并且如果他们没有运行，则通知某人。当然，这有一个 catch-22 - 如果应用程序没有启动，它如何记录任何内容？

大多数 IT 部门都有一个监控工具，可以让他们从远处监视他们的系统 - Microsoft 有 Operations Manager。因此，您的“心跳”日志应该与监控工具配合得很好；这种日志记录的最佳位置是 Windows 事件日志。事件日志不会死在你身上（就像数据库一样），可以从其他机器读取而无需设置文件共享等，并与各种监控工具开箱即用地集成。

心跳监测可能包括：

• 作业开始。
• 作业已完成，x 条记录已处理，y 条合格，z 条不合格
• 异常和错误

然后，您的监控工具可以密切关注工作，并确保“x、y 和 z”在预期范围内。

也将异常记录到事件日志中 - 这样，您的监控工具可以在出现问题时告诉您，而无需您每天解析日志文件。

调试

当然，您还希望能够调查出现问题时会发生什么。这通常不会进入事件日志 - 调试日志可能包含敏感信息，运营团队很少使用它们。

我通常将调试日志写入磁盘，使用滚动附加程序来确保它们不会占用太多磁盘空间。

我通常在“INFO”级别登录这些文件，并带有通过配置切换到 DEBUG 的选项。

您记录的内容很大程度上取决于应用程序设计。您绝对应该记录“输入”数据，以便开发人员可以使用您尝试调试的输入重新运行代码。如果流程需要运行外部数据，还要记录该数据（例如，如果您使用 Web 服务来获取决定结果的信息）。我不会在“信息”级别记录决策树中的每一步——它太冗长，而且难以追踪。

审核

如果您有审核要求，则事件日志是合适的位置 - 您可以设置安全性，以使未经授权的人员无法操纵数据。

我假设您已经在使用众多日志框架之一 - Log4Net 是我的最爱。

在 cmets 中，您提到日志记录要求的主要目的是能够跟踪和解释过程的结果。老实说，我不会称其为“日志记录”——这听起来像是业务领域的一流要求，而日志记录通常是为了满足技术要求。日志文件适用于技术人员，通常保留在运行作业的（安全）机器上 - 您的要求听起来像是面向客户的。

我会重新审视应用程序设计，看看满足业务需求的最佳方法是什么。有许多设计模式可能会有所帮助 - "Chain of responsibility" 是对这种决策树进行建模的一种巧妙方法，您可以轻松地将其扩展为包含链的日志。

Answer 2

在同样的情况下，我会记录以下内容：

• 计划作业已开始
• 计划作业找到需要处理的记录数
• 每条记录处理的调试信息
• 关于已处理的记录数量和处理结果的统计信息

通常这种类型的日志记录是在文件中完成的。记录到数据库的问题是，如果数据库出现故障，您的记录就会停止。