4

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

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

典型例子：

消息客户端

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!");
   }
}

消息服务

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 所说的那样，检查并分析打印“不必要”日志消息的应用程序的业务规则。

结案！感谢大家的大力投入和良好的建议。

4

5 回答 5

3

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

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

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

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

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

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

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

于 2012-10-27T17:27:11.890 回答
2

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

与具有访问日志和错误日志的 Web 服务器进行比较。我同意你的团队的观点，除非你有其他方法来遵循流程，否则你不能在生产中禁用这些消息。

于 2012-10-28T09:44:53.777 回答
1

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

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

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

之后，也许，在一年之后，你删除了其余的。

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

于 2012-10-26T21:58:57.860 回答
1

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

不过，您似乎正在做比这更多的信息记录。您可以考虑更改其中的一些以调试日志记录，然后将其禁用，或者将其写入单独的日志文件以显示错误和警告。

但是，拥有大型日志文件是否有问题？你的磁盘用完了吗？您是否难以在其中找到有用的信息？如果没有，那就让事情保持原样。如果您的问题是寻找有用的信息，那么我将集中精力寻找处理大型日志文件的方法，而不是试图使它们更小。详细日志中的信息在各种方面都非常有用，并且没有根本原因认为大小应该是一个问题。

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

于 2012-10-27T13:00:53.863 回答
0

对于生产环境，最好为记录器级别TRACE和ERROR.

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

于 2017-07-31T06:27:02.197 回答