标准错误日志文件的良好布局是啥?

Posted

技术标签:

【中文标题】标准错误日志文件的良好布局是啥?【英文标题】:What Is a Good Layout for a Standard Error Log File?标准错误日志文件的良好布局是什么? 【发布时间】:2011-01-08 02:14:21 【问题描述】:

我正在尝试为我的桌面程序设计错误和警告日志文件。

当我的程序读取用户的输入文件时,它可能会发现语法错误或某种无效数据。一旦读取所有内容并且程序正在处理数据,可能会发现更多问题。

我想将有关这些的消息写入一个简单的文本文件。我可能还想包含信息文本以指示进度、时间、内存使用等。我想包含行号,甚至可能包含导致错误的实际输入行。

这将是用户想要浏览的文件,因此显然它必须布局合理且易于使用。

您是否知道这方面的任何样式指南,或者您是否看过一个错误日志文件,让您自己思考:“现在这是一个精心设计的日志文件!”


跟进:

前三个答案实际上更适用于服务器或事件日志。

我真的在为我的桌面程序寻找一种日志文件格式,以详细说明它在输入文件中发现的任何问题及其处理的成功(或失败)。

我确信您使用过的某些桌面应用程序会生成此类日志文件。你见过什么好的吗?

【问题讨论】:

每个操作系统会有所不同——Windows 应用程序会记录到事件日志中,Mac OS 和其他 Unix 可能会使用 syslog。我想不出我使用任何其他方法使用该日志的任何主流桌面程序。 @Nathan:我对 Windows 最感兴趣,但了解其他操作系统上的良好日志格式会很有用。 对于 Windows,它几乎总是应用程序事件日志,我不太喜欢文本文件,但它是正确的方式。我见过一些在他们的程序目录或其他东西中写入文本文件的应用程序,但它总是临时的,从来没有标准。例如,McAfee VirusScan 将文件记录在 C:\Documents and Settings\All Users\Application Data\McAfee\DesktopProtection 中。我的机器在C:\Documents and Settings\username\Local Settings\temp\*.logC:\WINDOWS\temp\*.log 中有很多安装日志。但同样,它们都是不同的、临时的,设计得并不明显。 内森:这是一个很好的答案。如果您不介意,我会将其添加到您现有的答案中。 【参考方案1】:

sysloglog4j 是系统管理员可能熟悉的广泛使用的格式,并且有一些工具可以使用它们。在进行自己的格式之前,您至少应该查看它们。

对于 Windows,它几乎总是应用程序事件日志,我不太喜欢文本文件,但它是正确的方式。我见过一些在他们的程序目录或其他东西中写入文本文件的应用程序,但它总是临时的,从来没有标准。例如,McAfee VirusScan 将文件记录在 C:\Documents and Settings\All Users\Application Data\McAfee\DesktopProtection 中。我的机器在 C:\Documents and Settings\username\Local Settings\temp*.log 和 C:\WINDOWS\temp*.log 中有很多安装日志。但同样,它们都是不同的和临时的,设计得并不明显

【讨论】:

您对所有 temp*.log 文件的评论对我很有帮助。对 *.log 的简单搜索可以在我的机器上从大约 100 个不同的程序中找到大约 400 个。它们都如此不同,为我自己的日志提供了很好的选择。【参考方案2】:

我真正印象深刻的日志文件很少——实际上,我很难想到任何日志文件(而且我找不到任何日志文件)。根据我的经验,出现问题的部分原因是日志的格式是为了让内部人员(程序员)理解,而不是让其他程序或局外人(非程序员)理解。

关键信息经常被忽略;有时甚至是日期和时间信息。我建议使那些易于解析;我会使用 ISO 8601 表示法,例如 '2010-01-22T10:23:21-08:00' (包括时区,请注意)。我会包括进程(和线程)ID;我会考虑包括程序名称、参数(例如文件名);我也会以某种形式包含用户 ID。其中一些可能每次运行只需要一次,但每条消息可能需要其他位。这部分取决于日志文件是每次运行唯一还是跨运行共享,以及单个文件是否可以被多个用户/进程使用。

然后,您需要决定如何识别消息内容 - 以及消息内容的结尾。特别是对于机器解析(但也适用于人工解析),如果内容的格式明确并且可以检测到结尾,这将很有帮助。您可能需要转义内容(这是最常撤消的步骤,因此如果错误消息是关于格式错误的错误消息,那么很难分辨文件中的数据是什么以及有关数据的新错误消息是什么在文件中)。在多线程程序中 - 或者日志文件可能在进程之间共享 - 您还必须考虑如何缓冲写入,尤其是在您必须处理长行时。您希望每条消息在日志文件中单独分开。这不一定是微不足道的——您甚至可能需要处理锁定协议以确保受控访问。

考虑是否需要为日志提供漂亮的打印机。

考虑基于 XML 的格式(带有开始和结束标记)是否会有所帮助。我不是 XML 的忠实粉丝,但它在机器处理方面确实有一些优势。

【讨论】:

【参考方案3】:

我将日志写入 csv 文件并发现它非常方便(您可以将它们用作数据库或使用电子表格软件打开它们以进行复杂的分析)。示例日志文件是:

Date;Time;Severity;TID;Module;This;Source;Message
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@36;DLL_PROCESS_ATTACH
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@40;DLL_PROCESS_DETACH

我不确定它是否适合您的需求,但我认为您已经掌握了主要想法。祝你好运!

【讨论】:

以上是关于标准错误日志文件的良好布局是啥?的主要内容,如果未能解决你的问题,请参考以下文章

SQL Server事务日志被填满的原因是啥

nohup命令输出日志的方式

如何使用 Popen 同时写入标准输出和日志文件?

curl 日志分析

curl 日志分析

错误代码:400指的是啥错误?