异常日志子系统的吞吐量是否应该受到限制？如果是，怎么办？
我们遇到过异常进入某种无限循环的情况。 堆栈跟踪非常大，我们将其全部记录下来。
这会淹没我们的 Oracle 数据库，当重做日志达到其大小限制时，数据库就会停止。
编辑：当然，最重要的是找到无限循环的原因并纠正系统中的错误。我们已经这样做了，这不是这里的问题。 系统可能存在更多类似的错误（它是一项 Windows 服务，并且不断运行），在这种情况下，一个应用程序会破坏整个数据库，即该 Oracle 数据库上的所有应用程序。
我最感兴趣的是你在建筑方面的经历。还有其他日志框架（如 log4net、log4j 等）。他们如何处理大量的异常？就像处理所有其他异常一样处理它们吗？
We had a case when exceptions had gone in some kind of infinite loop.
Stack traces were very big and we log all of them.
That flood our Oracle database and when redo logs reached their size limit db stopped.
EDIT: Of course that the most important thing is to find the cause of infinite loop an correct the bug in the system. We already did that and that is not the question here.
The system could have more bugs like that (it's an windows service and it's running constantly) and in that case one app broke the whole DB, meaning all applications on that Oracle DB.
I'm mostly interested in your experiences, architecturally. And that from other logging frameworks like log4net, log4j and others. How do they handle flood of exceptions ? Just handle them like all other exceptions ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为你的情况说明肯定应该有某种机制来防止异常日志在任何地方导致拒绝服务，就像这样。
如果您使用 Windows 事件日志，这可以自动为您处理，因为当日志已满时，旧记录可以自动删除。您也可以编写一个基于数据库的系统来完成同样的事情。
当然，您也希望尽可能在第一时间尽一切努力消除此类错误！
另一种选择可能是检测并忽略同时发生的多个连续错误...也许只是更新
count属性/字段。I think your situation illustrates that there should definitely be some mechanism in place to prevent exception logs from causing a denial-of-service anywhere, as this has done.
If you use the Windows event logs, this can be handled for you automatically, as old records can automatically be wiped out when the log is full. You could code a DB-based system to do the same thing, as well.
Of course, you want to do everything you can to eliminate such errors in the first place where ever possible, too!
Another option may be to detect and ignore multiple, consecutive errors of the same time... perhaps simply updating a
countproperty/field instead.我更担心无限循环的根本原因，而不是限制日志记录。
我会检查您的代码中是否有捕获异常、记录堆栈跟踪并重新抛出的方法。我认为捕获和重新抛出不是异常处理。如果一个类确实无法处理异常，那么最好让它简单地冒泡，直到它达到有人可以处理它的单一点。
重做日志？你多久冲洗一次？你肯定没有一笔大交易吧？
I'd worry more about the root cause of the infinite loop then I would about limiting logging.
I'd check your code for methods that catch an exception, log the stack trace, and re-throw. I'd argue that catching and re-throwing is not exception handling. If a class truly can't handle the exception, it's better to let it simply bubble up until it reaches a single point where someone can deal with it.
Redo logs? How often do you flush those? Surely you don't have one big transaction, do you?
您可以在没有重做日志的情况下将日志记录到不同的数据库吗？这将保护生产数据库。
在我们的应用程序中，有一个中央异常处理程序，所有异常都通过
该处理程序可以决定如何记录，并且在调试时您有一个断点的中央位置
Can you do the logging to a different database with no redo logs? That will protect the production database.
In our applications whe have a central exceptionhandler where all execeptions go through
that handler can decide how to log and you have a central location for breakpoint when debugging