Question

我目前正在开展一个大型项目，其中包含许多相互通信的应用程序。

我和我的团队通过必要的错误修复和更改请求来管理和调整系统中的应用程序。系统正在大量使用，应用程序使用大量日志记录。

典型示例：

MessageClient

public void save(final Message message) {
   logger.info("Trying to save message: {}", message);

   boolean result = false;
   try {         
     result = messageService.save(message);
   } catch (final MessageStoreException e) {          
      logger.warn("Unable to save message {}", message, e);
      throw e;
   } catch (final Exception e) {
      logger.error("Unknown error when trying to save message!", e);
   }

   if (!result) {
      logger.warn("Could not save the message!");
   }
}

MessageService

public boolean save(final Message message) throws MessageStoreException {  
   if (message == null) {
      throw new IllegalArgumentException("message!");
   } 

   final boolean result = messageStore.store(message);
   if (result) {
      logger.info("Stored: {}", message.getId());
   } else {
      logger.warn("Unable to store: {}", message.getId());
   }

   return result; 
}

注意：我知道示例代码没有最佳的错误处理，但这就是我们管理的许多应用程序中的样子。

当然，这使得日志文件非常大。

我想在生产环境中关闭日志级别info和日志级别warn，并且只打开error级别，以便日志文件只包含意外错误需要注意，别无其他。

其他开发人员不喜欢这个想法，因为他们在查看搜索错误和错误的日志文件时不知道如何遵循“应用程序流”。

我理解这些论点，我觉得我需要来自社区的一些意见。

那么，这里的最佳做法是什么？我们应该在生产环境中使用info / warn日志级别还是应该只使用错误日志记录？或者两者兼而有之？

谢谢！

更新：应用程序在多个服务器上运行，我们当前将所有内容记录到文件中（通常每个应用程序有一个日志文件RollingFileAppender）。开始登录数据库需要做很多工作，所以这不是一个选择。

结论： 记录并非完全无足轻重。我们不会关闭信息和警告级别（这是一个非常激烈的操作），但就像@jgauffin所说的那样，通过并分析打印“不必要的”日志消息的应用程序的业务规则。

案件结案！感谢大家提供了很好的意见和建议。

Answer 1

我想在生产环境中关闭日志级别信息和日志级别警告，并且只保留错误级别，以便日志文件仅包含需要注意的意外错误，而不包含任何其他内容。

其他开发人员不喜欢这个想法，因为他们在查看搜索错误和错误的日志文件时不知道如何遵循“应用程序流”。

这是一个典型的问题。让我们分析一下日志记录：

final boolean result = messageStore.store(message);
   if (result) {
      logger.info("Stored: {}", message.getId());
   } else {
      logger.warn("Unable to store: {}", message.getId());
   }

这确实是一个问题，因为团队似乎并不确定是否可以存储消息的域规则。我很可能会说，无法存储消息确实应该是一个例外（因此应抛出异常）。但话说回来，我对域/业务规则一无所知。

然而，这样的记录通常表明业务规则不明确。因此，一个更好的解决方案可能是让团队分析为什么日志记录如此繁重。应用程序是否会产生大量维护？然后，最好删除日志记录和更多错误检查（比如验证方法参数），而不是转换日志级别。

团队注意到他们无法遵循流程而没有日志记录表明相同的事情：不检查参数，以便在应用程序的早期而不是早期引入错误。

Answer 2

您是否考虑过将不同的内容记录到不同的日志中一个日志中的事务数据，您可以在其中跟踪事务并将错误记录到另一个日志中。这将允许您跟踪消息的状态，并有一个日志，很容易看出出现了什么问题。

与具有访问日志和错误日志的Web服务器进行比较。我同意你的团队，在你有其他方法跟踪流程之前，你不能在生产中禁用这些消息。

Answer 3

您可以登录数据库。（应该不难设置一个像样的日志框架。）

从那里，您可以根据级别和年龄删除条目。 更新：首先记录所有内容（如果您愿意，还可以包括DEBUG）。比如说，一周后你删除了DEBUG消息。一个月后，您删除INFO消息。此时，您已将所有内容存储在您的文件中。

奖励：如果怀疑有错误，您暂时暂停删除。

之后，也许，在一年之后你会删除其余部分。

通过这种方式，您应该能够满足这两种需求：所需空间和保留信息。这可以根据需要进行调整。

Answer 4

我使用的大多数安装都在生产中启用了信息，警告和错误日志记录。我们期望在系统启动时看到一堆信息级别的日志记录，之后相当少。我们希望在正常操作期间看不到错误或警告记录 - 如果有的话，那是因为有些问题需要调查。

但是，您似乎正在进行比这更多的信息记录。您可以考虑更改其中一些以调试日志记录，然后禁用它，或者将其写入单独的日志文件中以查找错误和警告。

但是，拥有大型日志文件是否有问题？你的磁盘用完了吗？您是否难以在其中找到有用的信息？如果没有，那就保持原样。如果您的问题是找到有用的信息，那么我将集中精力寻找处理大型日志文件的方法，而不是试图让它们变小。详细日志中的信息可以通过各种方式非常有用，并且没有根本原因导致大小问题。

我现在在哪里工作，我们正在努力将越来越多的东西放在我们的日志中。目前通过监控系统处理的事情（处理的消息数量，数据库查询的时间等）正在转移到日志中。然后，我们只需将所有日志发送到中央logstash实例，这样我们就可以轻松搜索和分析它们。我们甚至可以从日志流中生成指标和警报，而不必在应用程序中处理此问题。

Answer 5

对于生产环境，最佳做法是为记录器级别TRACE和ERROR保留单独的日志文件。

在TRACE日志文件中，您可以识别不需要的邮件，删除这些邮件。

有关应用程序日志级别的建议

5 个答案: