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

我目前正在一个大型项目中工作，其中有许多应用程序正在相互通信

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

典型示例：

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

级别，以便日志文件只包含需要注意的意外错误，而不包含其他错误

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

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

那么，这里的最佳实践是什么？ 我们应该在生产环境中使用信息/警告日志级别，还是只使用错误日志？或者两者兼而有之

谢谢

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

结论： 日志记录并不完全是琐碎的。我们不会关闭信息和警告级别（这是一个相当激烈的行动），而是像@jgauffin所说的那样，检查并分析打印“不必要”日志消息的应用程序的业务规则

---

案件结案！感谢大家的宝贵意见和建议。

您可以登录数据库。（用一个像样的日志框架进行设置应该不会那么困难。）

从那里，您可以根据级别和年龄删除条目更新：首先记录所有内容（如果愿意，包括调试）。比如说，一周后删除调试消息。一个月后，您将删除信息消息。在这一点上，您已经拥有了现在存储在您的文件中的所有内容

额外好处：当怀疑有bug时，您暂时暂停删除

也许在这一年之后，你会删除剩下的部分

---

这样，您应该能够满足两个需求：所需的空间和保留的信息。这可以根据需要进行调整。

我使用过的大多数安装都在生产中启用了信息、警告和错误记录功能。我们希望在系统启动时看到大量信息级别的日志记录，而在系统启动后很少看到。我们希望在正常运行期间不会看到任何错误或警告日志记录-如果有，那是因为存在需要研究的问题

不过，看起来你要做的信息记录要比这多得多。您可以考虑更改其中的一些来调试日志记录，然后禁用日志记录，或者将其写入单独的日志文件中，以进行错误和警告。

但是，拥有大型日志文件是否存在问题？你的磁盘快用完了吗？你在它们里面找不到有用的信息吗？如果没有，那就保持现状。如果您的问题是查找有用的信息，那么我将集中精力寻找处理大型日志文件的方法，而不是尝试将其缩小。详细日志中的信息在各种方面都非常有用，并且没有根本原因认为大小会成为问题

在我目前工作的地方，我们正朝着把越来越多的东西放进日志的方向前进。当前通过监控系统处理的事情（处理的消息数量、数据库查询的计时等）正在转移到日志中。然后，我们只需将所有日志发送到一个中心实例，这样我们就可以轻松地搜索和分析它们。我们甚至可以从日志流生成度量和警报，而不必在应用程序中处理

我希望在生产环境中打开日志级别信息和日志级别警告，只打开错误级别，以便日志文件只包含需要注意的意外错误，而不包含其他内容

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

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

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

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

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

---

团队指出，如果没有日志记录，他们就无法遵循流程，这表明了同样的情况：参数不会被检查，因此错误会在应用程序的深层而不是早期被引入。

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

与具有访问日志和错误日志的web服务器进行比较。我同意你的团队，除非你有其他方法