如何减少网络应用程序的冗余日志消息？
有人对如何最小化网络应用程序的日志有任何建议吗？
现在，我正在记录每个错误。 因此，如果每个请求都发生错误（例如数据库连接问题），则可能会在每个请求上为每个用户记录错误。 正如您可以想象的那样，不需要太多用户做太多事情就可以开始积累带有冗余日志错误的巨大日志文件。
我想到创建某种类型的标记机制，以便在 N 分钟内不记录相同的错误。 我不喜欢这个有两个原因； 1）它可能隐藏其他问题中最重要的问题，2）级联错误可能无法正确记录其错误轨迹，忽略以前记录的错误，可能会导致我的初步诊断失败。
我确信我不是第一个遇到这个问题的人...有人对如何减少网络应用程序的冗余日志消息有任何建议吗？
Does anybody have any advice on how to minimize my logs for a web application?
Right now, I'm logging every error. So if there is a situation where an error occurs on every request (a db connection problem for example), it might get logged for every user on every request. As you can imagine, it doesn't take too many users doing too many things to start amassing a huge log file with redundant log errors.
It has occurred to me to create some type of flagging mechanism to not log the same error within N minutes. I don't like this for 2 reason; 1) it could hide the most significant problem amongst the others and 2) cascading errors may not log their error trail properly, omitting previously logged errors, potentially throwing off my initial diagnosis.
I'm sure I'm not the first person to have this issue ... does anybody have any advice on how to reduce redundant log messages for a web-app?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以创建一个记录到数据库的日志系统，并设置一个标志来确定是记录单个条目，还是只记录基本日志条目的计数器。 通过统计，您可以看到错误总数，但没有爆炸性的日志文件。
You could create a logging system that logs to a DB, and have a flag set to determine whether to log individual entries, or just tally a counter for a base log entry. By tallying, you see the gross number of errors, but don't have an exploding log file.
您可以尝试将最后一个条目与要放入日志中的错误进行比较。 如果这是相同的类型和来源，则在末尾附加一个字符串“（重复n次）”。
每当记录器看到这样的字符串并且错误匹配时，它就可以增加 n 直到出现另一种类型的错误。
You could try comparing the last entry with the error you're about to put in the log. If this is the same type and source, append a string "(repeated n times)" at the end.
Every time the logger sees such a string and the errors match, it can increase the n until another type of error comes in.
为了回答您在评论中提出的问题，据我所知，没有现成的解决方案包含此类功能。
另一个需要考虑的想法（我意识到此时您已经接受了自己的答案）是为系统中的每个错误记录点分配一个 ID。 记录错误时，您可以保留一个简单的哈希表，其中包含错误 ID 和记录错误的时间。 然后，在处理日志记录时，如果错误已存在于哈希中，并且发生在 5 分钟内（或您决定的任何时间），那么您可以简单地中止日志记录并更新时间戳。
我不确定让用户发送错误消息请求是否会解决您的问题，因为如果您的所有用户都提交该消息，它将与错误日志相同，只有您的收件箱会被淹没，而不是简单地监视日志文件本身。
To answer the question you had in the comment, to my knowledge there are no out of the box solution that encompasses this type of functionality.
One other idea to consider (I realize at this point you've accepted your own answer) would be to assign an ID to each error logging point in the system. When the error is logged, you can keep a simple hash table of the error Id and what time the error was logged. Then when processing the logging, if the error already exists in the hash and it has been within 5 minutes (or whatever time you decide) then you can simply abort the logging and update the timestamp.
I'm not sure if having the users send the error message request will resolve your issue, because if all your users submit the message, it'll be just the same as the error logs, only your inbox will get flooded as opposed to simply monitoring the log file itself.
我已将其与用户错误消息合并在一起，因此当向用户显示错误消息时，他们可以单击“确定”或“发送给支持人员”。 然后是完整的错误、调用堆栈、& 完整的请求信息被输入到错误跟踪器中。
该功能尚未发布，因此我们尚未确定这是否是一个好主意……我们会及时通知您。
PS-我已经回答了我自己的问题作为记录，并选择了它，因为其他答案不能满足我的需求。
I've combined it with my user error message, so when the error message is shown the user, they can either click, OK or Send to Support. Then the complete error, call stack, & complete request information is entered into the bug tracker.
This hasn't been released yet, so we've yet to see if this is a good idea ... will keep you posted.
PS-I've answered my own question as a for the record, and selected it since the other answers did not meet my needs.