什么样的日志记录对您的应用程序来说是好的日志记录？
因此，我们已经讨论了在我的工作地点进行登录，我想知道这里的一些人是否可以给我一些关于你们的方法的想法？
通常我们的场景是，根本没有日志记录，并且大多数是 .NET 应用程序、winforms/WPF 客户端通过 Web 服务进行通信或直接与数据库进行通信。
所以，真正的问题是，您将在哪里记录或记录什么？ 目前，我们有用户报告错误消息 - 所以我假设日志启动/关闭、异常...
您是否将其用于对 Web 服务或数据库的调用？ 页面加载？
您如何很好地了解用户当时想要做什么？
是最好一路记录多次尝试/天的所有内容，还是只记录您需要的内容（考虑到硬盘很便宜）。
我想这是几个问题，但我想更多地了解大型商店的实际做法是什么！
So we've discussed logging in passing at my place of work and I was wondering if some of you guys here could give me some ideas of your approaches?
Typically our scenario is, no logging really at all, and mostly .NET apps, winforms/WPF clients talking through web services or direct to a db.
So, the real question is, where or what would you log? At the moment we have users reporting error messages - so I would assume log startups/shutdowns, exceptions...
Do you take it to calls to the web services or db? Page loads?
How do you get a good idea of what the user was trying to do at the time?
Is it better to go all the way and log everything across multiple attempts/days, or log only what you need to (given hdd is cheap).
I guess that's a few questions, but I wanted to get more of an idea of what the actual practice is out there in larger shops!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
对于典型的桌面应用程序，我会存储当前会话中的所有内容，并且可能存储过去 n 个会话或最多 x 大小的信息消息。
我假设您的消息是有组织的。 我们使用 4 个类别； 错误、警告、信息和跟踪。 我们仍在弄清楚什么会发生在哪个级别。 当我习惯解析日志文件时，我通常会说“记录更多”。 不要担心可读性，您可能需要先处理一下日志文件，然后才能使用它。
最后，找到一个好的日志记录框架，允许您控制 spool 使用的生命周期和存储空间，以及一个适当的 api，最大限度地减少对代码的影响。 理想情况下，您只需输入
info("waaah")或warning("waah")，API 就会为您完成所有精美的标记。For a typical desktop app, I'd store everything on the current session, and maybe store info messages for the past n sessions or up to x in size.
I'm assuming that your messages are organized. We use 4 categories; errors, warnings, info, and trace. We're still figuring out what goes at which level. As I'm getting used to parsing log files, I generally say "log more". Don't sweat readability, you're probably gonna have to process the log file a bit before you can use it.
In the end, find a good logging framework that allows you to control your spool usage on lifetime and storage space, and a proper api that minimizes the effect on your code. Ideally you just type
info("waaah")orwarning("waah")and the API does all the fancy tagging for you.作为一个快速回答，我会说提出一系列类别并具有可切换的日志记录级别，例如信息、警告、错误、严重等。
然后可以轻松设置日志记录级别以调整您需要的详细程度。 通常，在配置文件中设置日志记录级别并停止并重新启动应用程序。
我还会向开发人员宣传每个级别的含义。
编辑：我还会建立一个系统来定期轮换、压缩和归档日志文件，也许每晚一次。
As a quick answer I would say to come up with a series of categories and have switchable logging levels, e.g. info, warning, error, critical, etc.
Then make it easy to set the logging level to tune the level of detail that you need. Typically, set the logging level in a config file and stop and restart the app.
I would also publicize to the developers what the meaning is for each of the levels.
edit: I would also set up a system to rotate out, compress and archive log files on a regular basis, maybe nightly.
谢谢大家，很多好信息，但马丁给了我更多关于如何继续的细节。 我会给他答案，因为看起来现在我们已经离开了前面几页的答案将会消失。
Thanks guys, lot of good info, but Martin has given me a bit more detail on how to proceed. I'll give him the answer, as it seems like now we're off the front few pages answers will drop off.
硬盘驱动器很便宜这一事实确实不是详细记录所有可能的内容的好理由，原因有几个。一方面，对于非常繁忙的应用程序，您真的不想放慢速度并束缚光盘写入写入日志（硬盘驱动器非常慢）。 第二点，也是更重要的一点 - 从 TB 级的日志中获得的收益非常少。对于开发来说，它们可能很有用，但您不需要保留超过几分钟的日志。
一些日志记录当然很有用，拥有不同的级别是唯一的方法 - 例如 debug() info() 仅在请求时才会记录（在配置或命令行标志中），然后可能是 warning() 和 error( ）被发送到日志文件
对于我写的大部分内容（小脚本），我通常只有一个 debug() 函数，它检查 --verbose 是否设置，并打印消息。这样我就可以推debug("some value: %s" % (avar)) 在需要时，不必担心返回并删除调试 print() 语句。
对于 Web 应用程序，我通常只使用 Web 服务器日志进行统计，以及错误日志。 我在需要时使用 mod_rewrite 的日志之类的东西，但在开发之外启用此功能是愚蠢的（因为它在每个页面请求上创建许多行）
我认为这取决于应用程序本身，但通常，对于大型应用程序使用多个级别可以在需要时激活的日志。 对于较小的事情，对于 Web 应用程序、日志错误和（在某种程度上）日志命中，可以使用 --verbose 标志或等效标志。
基本上，在“生产”日志中仅记录您可以使用的信息，在开发日志中记录您可能需要解决问题的所有信息。
The fact harddrives are cheap really isn't a good reason to verbosely log everything possible, for a few reasons.. For one, with a very busy application, you really don't want to slow it down and tie up disc-writes writing logs (harddrives are pretty slow). The second point, and the more important one - there's really very little to gain from terabytes worth of logs.. For development, they can are useful, but you don't need to keep more than a few minutes of them..
Some logging is of course useful, having different levels is about the only way to go about it - for example debug() info() only get logged if requested (in a config, or command line flag), then maybe warning() and error() get sent to a log file
For most of the things I've written (smallish scripts) I generally just have a debug() function, that checks if --verbose is set, and prints the message.. That way I can shove debug("some value: %s" % (avar)) when needed, and not have to worry about going back and removing debugging print() statements everwhere.
For web applications, I generally just use the web-server logs for statistics, and the error log. I use things like mod_rewrite's log when needed, but it would be idiotic to leave this enabled beyond development (as it creates many many lines on each page request)
I suppose it depends on the application itself, but generally, for big applications use multiple levels of logs that can be activated when needed. For smaller things, a --verbose flag or equivalent, for web applications, log errors and (to a point) log hits.
Basically, in "production" log only the information you can use, in development log everything you could possible need to fix problems.
highscalability.com 上的这篇文章提供了有关大型分布式系统中日志记录的良好视角。 （巧合的是，它首先提到了 JoelOnSoftware 上的一篇文章）。
This post on highscalability.com provides a good perspective on logging in a large scale distributed system. (And coincidentally it starts out by mentioning a post on the JoelOnSoftware).
作为一名管理员，我真的很欣赏那些记录到事件日志（最好是他们自己的，否则应用程序日志）的应用程序，以记录除跟踪日志之外的所有日志记录。 通过记录到事件日志，您可以使管理人员更有可能在警告或错误成为主要问题之前发现并解决它们（如果这是他们可以解决的问题），或者允许他们联系与开发人员一起，他们可以使用跟踪日志来进一步解决问题。
我现在支持自定义 .NET 应用程序的最大痛点是，同一供应商有 8 个不同的应用程序（一些控制台应用程序、一些 winform 和一些 Web）。 它们都不记录到事件日志，它们都有自己的自定义日志文件。 但对于所有 winforms 和控制台应用程序，它们在运行时保持文件打开，因此我无法监视它是否存在问题。 此外，日志的编写方式都略有不同，因此我必须以不同的方式解析它们才能获取有用的信息。
这迫使我监视应用程序的外观（它是否在其活动的端口上响应，进程工作集是否变得太高，等等），而不是应用程序的实际状态。
请考虑在部署后维护您的应用程序并提供他们可以使用的日志记录的人员。 谢谢！
Being an admin, I really appreciate apps that log to the Event Log (preferably their own, otherwise the application log) for all logging but trace logs. By logging to the event log, you make it much more likely that warnings or errors can be found and addressed by the admin staff before they become a major problem (if it is a issue they can address), or allows them to get in contact with the devs, who can use the trace logs to further troubleshoot the issue.
My biggest pain point in supporting a custom .NET app right now is that there are 8 different applications (some console apps, some winforms, and some web) from the same vendor. None of them log to the event log, they all have their own custom log files. But for all the winforms and console apps, they keep the file open while they are running, so I can't monitor it for issues. Also, the logs are all written slightly differently, so I would have to parse them a bit differently to get useful information.
This forces me to monitor the appearance of an application (is it responding on the ports it is active on, is the process working set getting too high, etc..), rather than what the state of the application really is.
Please, please consider the folks who maintain your application after it is deployed and provide logging they can use. Thanks!
日志记录的关键是良好的规划。 我建议您查看企业库异常和日志记录应用程序块（http: //msdn.microsoft.com/en-us/library/cc467894.aspx）。 虽然有一点学习曲线，但效果很好。 我目前赞成的方法是定义 4 个优先级。 4=未处理的异常（事件日志中的错误），3=已处理的异常（事件日志中的警告），2=访问外部资源，例如 Web 服务、数据库或大型机系统（事件日志中的信息），1=详细/其他任何内容感兴趣的（事件日志中的信息）。
使用应用程序块可以很容易地调整您想要记录的优先级。 因此，在开发中，您会记录所有内容，但是当您在生产中获得稳定的系统时，您可能只对未处理的异常和可能已处理的异常感兴趣。
更新：为了清楚起见，我建议您登录 winform/wpf 应用程序和网络服务。 在 Web 场景中，我过去遇到过一些问题，很难将客户端上的错误连接回应用程序服务器。 主要是因为通过 Web 服务的任何错误都会被包装为 SOAP 异常。 我记不清了，但我认为如果您使用自定义异常处理程序（这是企业库的一部分），您可以将数据添加到异常中，例如来自应用程序服务器的异常的处理实例 ID。 这使得使用 LogParser (http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en) 。
第二次更新：我还喜欢为每个不同的事件提供单独的事件 ID，并在源代码管理下的文本文件或电子表格中跟踪该事件。 是的，这很痛苦，但如果您足够幸运，有一个 IT 团队在生产中照顾您的系统，我发现他们倾向于期望不同的事件具有不同的事件 ID。
The key thing for logging is good planning. I would suggest that you look into the enterprise library exception and logging application block (http://msdn.microsoft.com/en-us/library/cc467894.aspx). There is a wee bit of a learning curve but it does work quite well. The approach I favour at the moment is to define 4 priority levels. 4=Unhandled exception (error in event log), 3=Handled exception (warning in event log), 2=Access an external resource such as a webservice, db or mainframe system (information in event log), 1=Verbose/anything else of interest (information in event log).
Using the application block it's then quite easy to tweak what level of priority you want to log. So in development you'd log everything but as you get a stable system in production, you'd probably only be interested in unhandled exceptions and possibly handled exceptions.
Update: For clarity, I would suggest you have logging in both your winform/wpf app and your webservices. In a web scenario, I've had problems in the past where it can be difficult to tie an error on the client back through to the app servers. Mainly because any error through webservices gets wrapped up as a SOAP exception. I can't remember off the top of my head, but I think if you use a custom exception handler (that is part of the enterprise library) you can add data onto exceptions such as the handlinginstance id of the exception from the app server. This makes it easier to tie up exceptions on a client back to your app box by using LogParser (http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en).
Second Update: I also like to give each different event a seperate event id and to track that in a text file or spreadsheet under source control. Yes, its a pain but if you're lucky enough to have an IT team looking after your systems in production, I find they tend to expect different events to have different event ids.