我目前正在开发一个相当大的多层应用程序，将部署海外。虽然我希望它在部署后不会崩溃或爆炸，但我无法百分之百确定。因此，知道我可以请求日志文件来确定出了什么问题和原因是很好的。
基本上，正如标题所示，我想知道何时记录以及记录什么？我想知道这一点，以确保我有全面的日志文件，可以轻松检查以确定如果我的应用程序崩溃了发生了什么。
基本上，正如标题所示，我想知道何时记录以及记录什么？我想知道这一点，以确保我有全面的日志文件，可以轻松检查以确定如果我的应用程序崩溃了发生了什么。
6个回答
6
1 - 制作一个单一的日志，使用标准化格式。不必过于关注它是什么，但确保每个条目都具有相同的基本字段。仅仅调用"printf"可能不够（根据需要替换为System.err.println或其他内容）。
2 - 至少允许一个字段是任意字符串...开发人员会比你更清楚需要什么。
3 - 在每个条目上包括高分辨率时间戳。您最终将需要它，相信我。
4 - 如果可能，请在错误来源处包括文件和行号。在C中很容易，在Java中有点麻烦。但是它非常有用，特别是当人们开始剪切和粘贴代码，包括错误消息时。
5 - 确保日志位于任何级别的代码都可以使用的位置。
6 - 我经常使用“Primary”和“Secondary”错误标签，“Primary”表示“我是检测到问题的人”，而“Secondary”表示“我调用了报告错误的函数”。这使得查找问题的源头变得容易（“Primary：文件未找到”），并且仍然报告错误的含义（“Secondary：无法加载校准表”）。
7 - 包括一些记录非错误以及错误的能力。
我发现最困难的部分是当错误不一定是错误时。如果您使用文件调用函数，而该文件不存在，这是否应该记录为错误？有时它是关键性失败，有时它是预期的。这基本上取决于函数的API；如果函数有一种返回错误的方法，我通常会让它执行而不记录；然后由更高级别的代码来决定是否需要报告该错误或者它是否是预期的。
- Chris Arguin
6
首先，选择一个日志框架 - 你没有提到具体的语言，但任何基于Apache log4j的框架都是一个安全的选择。最重要的是该框架支持不同级别的详细程度（调试信息、警告、错误信息）。你可以在运行时配置记录器实际写入哪些消息以及写入到哪里 - 没有必要重新发明轮子来处理日志记录。
在源代码中实现你的日志框架。至少，你应该记录并“增加价值”到应用程序中可能出现的异常。将堆栈跟踪写入日志文件非常好，但很少足以诊断问题 - 考虑记录catch {}中方法参数的值等内容。
在更高层次上，你可以利用不同详细程度的能力记录应用程序中正在发生的事情。如果错误仅在生产系统上发生，而你无法连接远程调试器，这尤其有用 - 你只需增加日志框架配置文件中的详细程度级别，观察所有调试("使用参数Y调用方法X")消息出现在日志中即可。
在源代码中实现你的日志框架。至少，你应该记录并“增加价值”到应用程序中可能出现的异常。将堆栈跟踪写入日志文件非常好，但很少足以诊断问题 - 考虑记录catch {}中方法参数的值等内容。
在更高层次上，你可以利用不同详细程度的能力记录应用程序中正在发生的事情。如果错误仅在生产系统上发生，而你无法连接远程调试器，这尤其有用 - 你只需增加日志框架配置文件中的详细程度级别，观察所有调试("使用参数Y调用方法X")消息出现在日志中即可。
- iAn
1
我只想补充一点，在一个大型的关键任务应用程序中，问题只能通过客户端发送的日志来进行调查，因此在记录何时和何处进行记录方面，随着应用程序成熟度的提高，会逐渐形成良好的感觉（成熟度直接与应用程序在一个地方部署并使用的时间以及不同客户/位置的部署数量有关）。
- ayaz
0
只要性能不需要付出太多代价，日志记录就很重要。
在我的经验中，最重要的是记录那些警告、失误、合理性检查失败、雨天场景等等，这些往往在编写晴天场景时被忽略，有时会用“我们不应该到达这里”等打印语句来解决。这些问题往往不会在测试期间出现，但会在部署期间开始出现，而当然没有被捕获。
如果您记录并打算通过远程方式阅读结果，请确保捕获精确的时间戳、位置和某种会话 ID（以防同时运行多个实例并写入日志文件）。您确定哪些消息属于一个执行的过程越容易，您就越好。
错误级别和类型也很重要。还要进行搜索，以确保您没有从多个位置写入相同的消息，否则跟踪将变得困难。
最后，如果您的用户运行 Mac OS X，请非常小心地记录错误：由于某种奇怪的原因，即使在 Leopard 中，默认的日志记录机制也会被昂贵地处理，并可能占用大量 CPU。
在我的经验中，最重要的是记录那些警告、失误、合理性检查失败、雨天场景等等，这些往往在编写晴天场景时被忽略，有时会用“我们不应该到达这里”等打印语句来解决。这些问题往往不会在测试期间出现，但会在部署期间开始出现，而当然没有被捕获。
如果您记录并打算通过远程方式阅读结果，请确保捕获精确的时间戳、位置和某种会话 ID（以防同时运行多个实例并写入日志文件）。您确定哪些消息属于一个执行的过程越容易，您就越好。
错误级别和类型也很重要。还要进行搜索，以确保您没有从多个位置写入相同的消息，否则跟踪将变得困难。
最后，如果您的用户运行 Mac OS X，请非常小心地记录错误：由于某种奇怪的原因，即使在 Leopard 中，默认的日志记录机制也会被昂贵地处理，并可能占用大量 CPU。
- Uri
0
我们开发了一个大型的基于电话的系统，该系统在全球范围内使用，并且多年来一直使用我们自己的应用程序日志记录系统。调试级别非常重要，我们的应用程序默认将调试级别设置为“仅错误”，并在除了最敏感的应用程序之外的所有应用程序上启用文件记录。我们还支持将输出重定向到调试跟踪系统（这是 Windows 平台，所以只需要调用 OutputDebugString，我们的工程师就可以使用名为 DBWIN32 的调试捕获器）。这很重要，因为某些类别的错误需要您能够看到多个应用程序的输出，经过序列化。我通过应用这种技术解决了一些相当棘手的多应用程序交互错误。应用程序通常会向输出添加可读标记，以便我们可以确定哪行来自哪个应用程序。
我们通常使用的级别是：关闭、仅错误、基本、详细、“冗长”（其中“冗长”是一个占位符，暗示着多个内容，如轮询结果、用户操作、消息内容等——作者认为重要的任何事物）。
哦，而应用程序写入其日志文件的第一件事是提供其版本资源的标题，以便我们可以确定正在处理哪个构建——不要相信用户或现场工程师知道 :-)。
我们通常使用的级别是：关闭、仅错误、基本、详细、“冗长”（其中“冗长”是一个占位符，暗示着多个内容，如轮询结果、用户操作、消息内容等——作者认为重要的任何事物）。
哦，而应用程序写入其日志文件的第一件事是提供其版本资源的标题，以便我们可以确定正在处理哪个构建——不要相信用户或现场工程师知道 :-)。
- Bob Moore
0
AOP对于非侵入式日志记录非常有用。例如，您可以使用AOP记录每个方法调用的参数值和返回值，而无需实际将日志记录语句添加到每个方法中。
如何实现这一点的具体细节显然取决于您的目标语言和平台（您没有指定）。有关如何将此类记录器添加到基于Java Spring的应用程序的示例，请参见此处。
如何实现这一点的具体细节显然取决于您的目标语言和平台（您没有指定）。有关如何将此类记录器添加到基于Java Spring的应用程序的示例，请参见此处。
- Don
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接