![如何限制生产中的异常日志记录](https://linux22.com/image/778194/%E5%A6%82%E4%BD%95%E9%99%90%E5%88%B6%E7%94%9F%E4%BA%A7%E4%B8%AD%E7%9A%84%E5%BC%82%E5%B8%B8%E6%97%A5%E5%BF%97%E8%AE%B0%E5%BD%95.png)
首先,请注意这可能是一个 JavaScript 问题(在 Node 或浏览器上),也可能是一个 Ruby 问题(日志记录是在文件中还是在数据库中),等等。这就是为什么我要问服务器故障;因为我认为这里的许多人都关心监控生产中的应用程序!如果有另一个 Stackexchange 网站,请询问,我会将其移植到那里。
记录时如何处理长异常消息。有两种类型的异常:您自己引发的异常(并且对其消息有相对良好的控制)和依赖项引发的异常。
我个人在生产方面的经验有限,但我正在考虑:
- 将日志记录限制在 error.message 中(而不是整个堆栈)
- 简单地对消息长度进行严格限制(
err.message.split(0, 100)
例如)
接下来,我认为是一个雄心勃勃但完全不确定的解决方案,就是用一个通用的自制解决方案来包装任何异常,这样可以删除长消息,降低堆栈的深度,甚至可以处理陷入循环的异常日志(放置一个计时器和一个计数器或每个引发的异常)。
直到现在,我才意识到日志记录是一个真正的问题,也许我把事情复杂化了。
答案1
最佳实践是避免/禁止在编程中重复记录日志。例如,如果自动重新连接是一项功能,则连接被拒绝错误将持续存在。我一直强调,无连接是一种状态,只需记录一次,而连接会导致另一条日志,总共两条日志就足够了,而不是一行行地无休止地记录无连接。但是,如果你不能强制程序员为你做这件事,你所能做的就是按计划用你自己的脚本过滤和分析日志,并删除原始日志。
答案2
我制造了一个通用解决方案对于我的环境,即 JavaScript。它是一个错误(异常)包装器,根据用户选项,限制消息的长度,并可选地用非常小的哈希值替换抛出的相同错误(如果在某个时间窗口内引发,则具有相同的类型和消息和堆栈)。
不过,我不建议在没有经过适当测试的情况下使用它。