我应该在我的网络应用程序中记录哪些信息？
我完成了一个网络应用程序，并尝试实现一些日志记录。 我从未见过任何关于记录内容的好例子。 难道只是例外吗？ 还有其他我应该记录的事情吗？ 您认为什么类型的信息对于查找和修复错误有用。
寻找一些具体的指导和最佳实践。
谢谢
跟进
如果我要记录异常，我应该具体记录哪些信息？ 我应该做的不仅仅是 _log.Error(ex.Message, ex); 吗？
I finishing up a web application and I'm trying to implement some logging. I've never seen any good examples of what to log. Is it just exceptions? Are there other things I should be logging? What type of information do you find useful for finding and fixing bugs.
Looking for some specific guidance and best practices.
Thanks
Follow up
If I'm logging exceptions what information specifically should I be logging? Should I be doing something more than _log.Error(ex.Message, ex); ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
以下是我对应用程序中可以记录的内容、您可能想要记录的原因以及如何进行记录的逻辑细分。 不管怎样，我都会建议在实现时使用 log4net 这样的日志框架。
异常记录
当其他一切都失败时，这不应该。 拥有一个捕获所有非手动异常的中央方法是一个好主意。 这不应该
除非您使用的不仅仅是线程，否则将整个应用程序包装在一个巨大的 try/catch 中要困难得多。 工作并没有结束
不过，因为如果您等到异常到达时，许多有用的信息就会超出范围。 至少你应该
尝试收集应用程序状态的特定部分，这些部分可能有助于堆栈展开时的调试。 您的应用程序应始终准备好生成此类日志输出，尤其是在生产中。 如果您还没有看过ELMAH，请务必查看一下。 我还没有尝试过，但我听到了很棒的事情
应用程序日志记录
我所说的应用程序日志包括捕获有关您的应用程序在概念级别上执行的操作的信息的任何日志，例如“已删除的订单”或“用户登录”。 此类信息可用于分析趋势、审核系统、锁定系统、测试、安全和检测粗略错误。 计划在生产中保留这些日志可能是一个好主意，也许是在不同的粒度级别上。
跟踪
日志记录 对我来说，跟踪日志记录代表了最精细的日志记录形式。 在这个级别，您较少关注应用程序正在做什么，而更多地关注它是如何做的。 这比实际逐行浏览代码高出一步。 它可能在处理并发问题或任何难以重现的问题时最有帮助。 您不会希望始终运行它，可能只在需要时才打开它。
最后，与通常只能在最后解决的许多其他问题一样，考虑日志记录的最佳时间是在项目开始时，以便在设计应用程序时考虑到它。 很好的问题！
Here is my logical breakdown of what can be logged within and application, why you might want to and how you might go about doing it. No matter what I would recommend using a logging framework such as log4net when implementing.
Exception Logging
When everything else has failed, this should not. It is a good idea to have a central means of capturing all unhanded exceptions. This shouldn't
be much harder then wrapping your entire application in a giant try/catch unless you are using more than on thread. The work doesn't end here
though because if you wait until the exception reaches you a lot of useful information would have gone out of scope. At the very least you should
try to collect specific pieces of the application state that are likely to help with debugging as the stack unwinds. Your application should always be prepared to produce this type of log output, especially in production. Make sure to take a look at ELMAH if you haven't already. I haven't tried it but I have heard great things
Application Logging
What I call application logs includes any log that captures information about what your application is doing on a conceptual level such as "Deleted Order" or "A User Signed On". This kind of information can be useful in analyzing trends, auditing the system, locking it down, testing, security and detecting bugs of coarse. It is probably a good idea to plan on leaving these logs on in production as well, perhaps at variable levels of granularity.
Trace Logging
Trace logging, to me, represents the most granular form of logging. At this level you focus less on what the application is doing and more on how it is doing it. This is one step above actually walking through the code line by line. It is probably most helpful in dealing with concurrency issues or anything for that matter which is hard to reproduce. You wouldn't want to always have this running, probably only turning it on when needed.
Lastly, as with so many other things that usually only get addressed at the very end, the best time to think about logging is at the beginning of a project so that the application can be designed with it in mind. Great question though!
要记录的一些内容：
有些事情不要记录：
Some things to log:
Some things to NOT to log:
也许您应该记录应用程序中尚未定义但客户端请求的页面/资源访问。 这样，您也许能够发现漏洞。
Maybe you should log page/resource accesses which are not yet defined in your application, but are requested by clients. That way, you may be able to find vulnerabilities.
这取决于应用程序及其受众。 如果您正在管理销售或交易股票，您可能应该记录比个人博客更多的信息。 当您最需要日志时，就是生产环境中发生错误，但无法在本地重现错误时。 在这种情况下，拥有日志级别和日志层次结构会有所帮助，因为您可以动态提高日志级别。 请参阅 log4j 的文档 和 log4net。
It depends on the application and its audience. If you are managing sales or trading stocks, you probably should log more info than say a personal blog. When you need the log most is when an error is happening in your production environment, but can't reproduce it locally. Having log level and log hierarchy would help in such situations, because you can dynamically increase the log level. See log4j's documentation and log4net.
我的几分钱。
除了正确使用日志严重性和异常之外，还可以考虑构建日志语句，以便将来可以轻松查看日志数据。 例如 - 快速提取有意义的信息，进行查询等。生成大量日志数据没有问题，问题是将这些数据转换为信息。 因此，预先构建和定义它有助于以后的使用。 如果您使用 log4j，我还建议使用映射诊断上下文 (MDC) - 这对于跟踪会话上下文有很大帮助。 除了跟踪和信息之外，我还会使用通常保持温度的调试级别。 项目。 不需要时可以过滤掉或禁用它们。
My few cents.
Besides using log severity and exceptions properly, consider structuring your log statements so that you could easily look though the log data in the future. For example - extracting meaningful info quickly, doing queries etc. There is no problem to generate an ocean of log data, the problem is to convert this data into information. So, structuring and defining it beforehand helps in later usage. If you use log4j, I would also suggest using mapped diagnostic context (MDC) - this helps a lot for tracking session contexts. Aside from trace and info, I would also use debug level where I usually keep temp. items. Those could be filtered out or disabled when not needed.
您可能不应该在这个阶段考虑这一点，相反，日志记录有助于在开发的每个阶段考虑，以帮助在潜在错误出现之前消除它们。 根据您的程序，我会尝试捕获尽可能多的信息。 记录一切。 如果您没有足够地引用该数据，您可以随时停止记录某些组件或进程。 没有太多的信息。
根据我（有限的）经验，如果您不想为每种可能的错误类型创建特定的错误表，请构造一个通用数据库表，该表接受一般信息以及可以在过程中填充异常数据、确认消息的字符串。成功但重要的过程等。我为此使用了带有参数的通用函数。
您还应该考虑在必要时关闭日志记录的能力。
希望这可以帮助。
You probably shouldn't be thinking of this at this stage, rather, logging is helpful to consider at every stage of development to help diffuse potential bugs before they arise. Depending on your program, I would try to capture as much information as possible. Log everything. You can always stop logging certain components or processes if you don't reference that data enough. There is no such thing as too much information.
From my (limited) experience, if you don't want to make a specific error table for each possible error type, construct a generic database table that accepts general information as well as a string that you can populate with exception data, confirmation messages during successful yet important processes, etc. I've used a generic function with parameters for this.
You should also consider the ability to turn logging off if necessary.
Hope this helps.
我相信当您记录异常时，您还应该保存当前日期和时间、请求的 url、url 引用者和用户 IP 地址。
I beleive when you log an exception you should also save current date and time, requested url, url refferer and user IP address.