感谢您的时间，并对此长信息表示歉意！在您的软件中写入日志以处理可能的大量日志消息的策略是什么？

我的工作环境

Linux下C/C++（但我是新来的Linux平台）

我简要

在我工作的软件问题，我们写很多的日志消息到本地文件这使得文件的大小增长很快，最后用尽所有磁盘空间（哎！！）。我们希望这些日志消息用于故障排除目的，特别是在软件发布到客户现场之后。我认为当然不能接受客户电脑的所有磁盘空间，，但我不知道如何处理这个。所以我想知道如果有人在这里有什么好主意。更多信息在下面。

我不是问的

1）。我是不是要求推荐的C++日志库。我们自己写了一个记录器。 2）。我是不是询问应该在日志消息中写入什么细节（如时间戳，线程ID，函数名等）。一些建议可以发现here。

我在我的软件

我单独的日志消息已经做分为3类：

SYSTEM：只有登录我的软件的重要步骤。示例：对我的软件的接口方法的外部调用。背后的想法是从这些消息中我们可以看到软件中通常发生的事情。有并不是很多这样的消息。
错误：只记录错误情况，例如找不到ID。通常有并不是很多这样的消息。
信息：记录我的软件内部运行的详细步骤。例如，当调用接口方法时，如上所述写入SYSTEM日志消息，并且在接口方法内的整个调用例程到内部模块中将被记录INFO消息。背后的想法是这些消息可以帮助我们确定详细的调用堆栈，以便进行故障排除或调试。这是使用磁盘空间问题的来源：当软件正常运行时，始终有INFO消息。

我的尝试和思考

1）。 我试图不记录任何INFO日志消息。这解决了磁盘空间问题，但我也失去了大量调试信息。想想这个：我的客户位于不同的城市，经常去那里很贵。此外，他们使用外部100％无法访问的内部网。因此：只要遇到问题，我们不能总是派工程师到现场;我们无法启动远程调试会话。因此，我认为日志文件是我们可以用来找出问题根源的唯一方法。 2）。 也许我可以做日志策略在运行时（目前它的软件运行之前）配置，即：在正常运行时，该软件只记录系统日志和错误日志;当出现问题时，有人可以更改日志记录配置，以便可以记录INFO消息。但仍然：谁可以在运行时更改配置？也许我们应该教育软件管理员？ 3）。 也许我总是可以打开INFO消息登录，但将日志文件定期打包到压缩包中？嗯......

最后...

什么是你在你的项目/工作经验？任何想法/想法/评论都欢迎！

编辑

感谢您的努力！这里的关键点从下面所有的答复摘要（我给他们一试）：

1）。不要使用大型日志文件。使用相对较小的。 2）。定期处理最旧的（可以删除它们或将其压缩到更大的存储空间）。 3）。实施运行时可配置的日志记录策略。

来源

2012-03-06 yaobin

用于对数轮转，请参阅http://linux.about.com/od/commands/l/blcmdl8_logrota.htm – stefaanv 2012-03-06 12:27:48

有采取注意到两个重要的事情：

非常大的文件是很不方便的。他们是很难传播，很难进行调查，...
日志文件主要是文本和文本是可压缩

根据我的经验，一个简单的方法来解决这个问题是：

只写小文件：为新会话或当前文件增长超过预设限制（我发现50 MB非常有效）时启动新文件。为帮助找到写入日志的文件，请将创建日期和时间作为文件名的一部分。
压缩日志，可以是脱机（一旦文件完成）或联机（即时）。
建立一个清理程序，删除所有超过X天的文件，或者每当超过10,20或50个文件时删除最老的文件。

如果您想保留System和Error记录更长的时间，你可能会在一个特定的旋转文件只跟踪它们复制它们。

干脆地说，这提供了以下日志文件夹：

Log/ 
    info.120229.081643.log.gz // <-- older file (to be purged soon) 
    info.120306.080423.log // <-- complete (50 MB) file started at log in 
           (to be compressed soon) 
    info.120306.131743.log // <-- current file 

    mon.120102.080417.log.gz // <-- older mon file 
    mon.120229.081643.log.gz // <-- older mon file 
    mon.120306.080423.log // <-- current mon file (System + Error only)

根据您是否可以安排（的cron）清理任务，你可能只是你的应用程序中旋转起来进行清理线程。无论你使用清除日期还是限制文件数量，你都必须作出选择，要么是有效的。

注意：从经验来看，50MB最终重量在10MB左右，而在离线压缩时低于5MB（动态效率较低）。

来源

2012-03-06 12:25:27

感谢您的详细回复。 – yaobin 2012-03-12 08:14:06

我会

a）在运行时使日志消息中的细节级别可配置。 b）为每一天创建一个新的日志文件。然后你可以让cron压缩它们和/或删除它们，或者转移到off-ling存储器。

来源

2012-03-06 11:45:47

你（3）在UNIX系统日志的世界标准的做法。

当日志文件达到一定年龄或最大尺寸，开始一个新的
Zip或以其他方式压缩旧
扔掉的第n个最古老的压缩日志

来源

2012-03-06 11:49:34 blueshift

的一种方式处理它就是旋转日志文件。

开始登录到一个新的文件，一旦你达到一定的规模，并保持过去的日志文件开始覆盖第一个前。

你不会有所有可能的信息，但你至少会有一些东西导致该问题。

的日志策略听起来不寻常的，但你有你的理由。

来源

2012-03-06 11:50:45 stefanB

我的答案是写长记录，然后调整你想要的信息。

压缩他们每天的基础上 - 而是让他们一个星期

来源

2012-03-07 06:32:22

我喜欢记录了很多。在某些程序中，我将最后的n行保存在内存中，并在发生错误或用户请求支持时写入磁盘。

在一个程序中，它会保留内存中的最后400行，并在发生错误时将其保存到日志记录数据库中。一个单独的服务监控这个数据库，并向我们的办公室发送一个包含摘要信息的HTTP请求，该服务将其添加到那里的数据库中。

我们在每台台式机上都有一个程序，显示一个问题列表（由F5更新），我们可以将这些问题分配给我们自己并标记为已处理。但现在我越来越被带走:)

这很好地帮助我们支持许多用户在几个客户。如果在运行我们的软件的PDA上发生错误，那么在一分钟左右的时间内，我们会在屏幕上显示一个新项目。我们经常在用户意识到他们遇到问题之前给他们打电话。

我们有一个过滤机制来自动处理或分配我们知道我们已经修复或不太在意的问题。

在其他程序中，我已经有每小时或每天的文件，这些文件在n天后被程序本身或专门的日志清理服务删除。

来源

2013-09-27 10:56:06 cja

在您的软件中写入日志以处理可能的大量日志消息的策略是什么？

我的工作环境

我简要

我不是问的

我在我的软件

我的尝试和思考

最后...

编辑

回答

相关问题