ArrayIndexOutOfBounds异常。日志只记录了异常类型，这几乎没有用（但是，哦，可怜的旧应用程序，我们仍然喜欢你，大部分时间）。我重新部署了应用程序，并更改了日志记录方式以记录异常处理时的堆栈跟踪（并立即找到了问题的根本原因），想知道为什么之前没有其他人做过这个。您一般是否记录堆栈跟踪，有没有任何理由不这样做？一些日志可能包含敏感数据，日志设施不一定足够安全以在生产环境中追踪该数据。
过多日志记录会导致信息过载，即对系统管理员来说根本没有任何信息可用。如果日志充满了调试消息，他们将无法识别可疑的模式。(多年前我看到一个为安全原因记录所有系统调用的系统。有这么多日志，当一些非特权用户开始成为root时，没有人注意到它。)
最好的方法是记录所有适当的日志级别，并能够在生产环境中设置日志级别（至少在Java中不是一个大问题）。
通常我会记录堆栈跟踪，因为它包含了故障排除和调试问题所需的信息。它是仅次于迷你转储的最佳选择，并且通常通过代码检查和识别问题来找到解决方案。
顺便说一下，我同意sibidiba关于完整堆栈可能泄露应用程序内部信息的观点：函数名称以及堆栈调用序列可以向受过教育的读者提供很多信息。这就是为什么有些产品只记录堆栈上的符号地址，并依靠开发人员从内部pdb中解析地址到名称。
但在我看来，将文本记录到包含1行错误和14行堆栈的文件中会使错误日志非常难以导航。它还会在高并发应用程序上引起问题，因为锁定日志文件的时间更长（或更糟糕的是，日志文件会交错）。在支持和故障排除我的自己的应用程序部署时遇到了这些问题，这促使我实际上创建了一个服务来记录错误，网址是bugcollect.com。在设计错误收集策略时，我选择每次收集堆栈转储，并将堆栈用作桶键的一部分（将发生在相同堆栈上的错误分组到同一个桶中）。
在开发人员记录过于自由和系统管理员发现应用程序一旦被放置在生产负载下，就会崩溃并填充大量日志文件时，通常会实施有关记录的限制。然后很难说服他们相信你已经看到了自己的错误，并已经足够减少了记录（或调整了日志级别），但是确实需要这些剩余的日志条目。
我经常看到的是像这样记录异常的代码：
LOG.error(ex);
因为log4j接受一个对象作为第一个参数，它将记录异常的字符串表示形式，通常只是类的名称。这通常只是开发人员疏忽了。最好像这样记录和报错：
LOG.error("发生错误", ex);
...这样，如果配置正确，日志框架将记录堆栈跟踪。
Log4J？如果是，它是否使用了org.apache.log4j.RollingFileAppender？我在银行应用程序中使用它（是的，这个系统非常庞大），但我完全没有遇到任何问题。 - Buhake Sindilogger.info()或logger.debug()将“有用”的信息传递到日志中。因此，记录必要/不必要的数据（取决于您的观点）可能是有争议的。我之所以问这个问题，是因为似乎有太多的信息传递到了记录器中，而且开发人员似乎从未充分利用记录器的效率。 - Buhake Sindi