日志记录策略与性能
我正在开发一个必须支持大量并发请求的 Web 应用程序，并且我希望保持足够快。我现在必须实施日志记录策略，我将使用 log4net，但是......我应该记录什么以及如何记录？我的意思是：
- 日志记录如何影响性能？是否可以/推荐使用异步调用进行日志记录？
- 使用文本文件还是数据库更好？有条件的话可以吗？例如，默认将日志记录到数据库，如果失败，则切换到文本文件。
- 那么多线程呢？使用 log4net 时我应该关心同步吗？或者它是开箱即用的线程安全的？
在需求中，应用程序应该为每个请求缓存一些内容，我担心这会对性能产生影响。
干杯。
I'm developing a web application that has to support lots of simultaneous requests, and I'd like to keep it fast enough. I have now to implement a logging strategy, I'm gonna use log4net, but ... what and how should I log? I mean:
- How logging impacts in performance? is it possible/recomendable logging using async calls?
- Is better use a text file or a database? Is it possible to do it conditional? for example, default log to the database, and if it fails, the switch to a text file.
- What about multithreading? should I care about synchronization when I use log4net? or it's thread safe out of the box?
In the requirements appear that the application should cache a couple of things per request, and I'm afraid of the performance impact of that.
Cheers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
进行日志记录/跟踪非常有价值 - 至少您应该记录错误，否则您永远不会知道它们。大多数日志记录 API 允许您打开和关闭需要记录的详细信息级别。
不要担心性能，直到它成为问题。这并不像您正在建造月球火箭并希望通过测试来了解它可以承载多少重量 - 它只是代码，删除淹没您的日志的日志记录语句，并在出现问题时重新编译。
Having logging/tracing is extremely valuable - at the very very least you should log errors, or you'll never know about them. Most logging apis let you turn on and off the level of detail you need logged.
Don't worry about performance until it becomes a problem. It's not like you're building moon rockets and wants to see how much weight it can carry by testing it - it's just code, remove the logging statements that flood your logs and recompile if it ever becomes a problem.
我想说你在这篇文章的早期就担心性能，以一种很容易稍后关闭或自定义的方式使用 log4net（例如：使用定义日志级别 NONE、ERROR、WARN、DEBUG、INFO 的conf 文件，全部，详细等...），
但是您的其他两个问题是有效的，对于问题2，我会选择纯文件，因为它们可以轻松读取和访问，而不是数据库。此外，写入文件末尾的性能优于数据库。
是的，正如 nos 所说，log4net 是线程安全的。
一条一般性建议，如果您的项目很大，并且您希望拥有如上所述的可配置日志级别，那么您确实需要在团队内部就不同级别的日志内容达成一致的编码标准。
I would say you are worrying about performance to early on in the piece, use log4net in a way that is very easy to turn off later or customize (eg: use of conf file that defines log level NONE, ERROR, WARN, DEBUG, INFO, ALL, VERBOSE etc ...),
However your two other concerns are valid, for question 2, I would go for plain file as they can be easily read anc accessed as opposed to database. Also the performance of writing to the end of a file is better than a db.
And yes as nos has stated log4net is threadsafe.
One piece of general advice, If your project is a large and you want to have any hope of ever having configurable log levels as I described above, then you really need to agree on a coding standard within your team on what to log at different levels.
我完全同意 hafez 和 nos 所说的。您将使用日志包走正确的道路，而不是尝试推出自己的日志包。它更干净、更容易正确。从长远来看，记录到文本文件比数据库记录更容易管理（考虑到典型的项目技能集），但如果您计划对报告的数据进行任何复杂的分析，有时将其存储在数据库中会更容易。
如果调试是您实现日志记录解决方案的既定目标之一，那么您必须预先标准化所有日志级别并将其作为代码审查过程的一部分。粒度上有足够的差异，以便您可以通过进入下一个级别逐渐增加报告的深度。解决 PROD 问题是非常令人沮丧的，没有足够的日志信息来查看问题，然后增加到下一个级别的日志记录，并用如此多的喷涌完全淹没日志，以至于你看不见树木（并且由于容量的原因，您的日志每 5 分钟滚动一次）。我已经看到它发生了。
在大多数文本文件记录情况下，性能不应该成为问题。数据库日志记录有点棘手。执行插入仅比附加到文本文件稍微密集一些，但每单位时间的体积使其在规模上变得更加丑陋。
另外，如果您要进行任何离线日志分析，您应该选择一种易于扩展的日志文件格式，并且如果您需要向日志添加某些内容，则不需要对分析代码进行巨大的更改。远离嵌套的、多部分的消息结构。解析这些会很痛苦。
祝你好运！
I agree completely with what hhafez and nos said. You're going down the right path with a logging package instead of trying to roll your own. It's much cleaner and easier to get right. Logging to a text file is much easier to manage long term (given typical project skill sets) than DB logging, though if you're planning any complex analysis of reported data, sometimes it's easier just having it already in a DB.
If debugging is one of your stated objectives for implementing a logging solution, then it's imperative that you standardize all your log levels up front and make that part of your code review process. Have enough differences in granularities so that you can gradually increase the depth of reporting by going to the next level. It's very frustrating to be troubleshooting a PROD problem, not have enough log info to see the problem, then increase to the next level of logging and completely swamp the logs with so much spew that you can't see the forest for the trees (and your logs roll every 5 minutes because of the volume). I've seen it happen.
In most cases of text file logging, performance should not be an issue. It's a little trickier with DB logging. Doing an insert is only slightly more intensive than appending to a text file, but it's the volume-per-unit-time that makes it much uglier at scale.
Also, if you're going to do any offline log analysis, you ought to pick a log file format that's easily extensible and won't require tremendous changes to the analysis code if you need to add something to the log. Stay away from nested, multi-part message structures. Parsing those gets to be a pain.
Good luck with it!