感谢您的时间，并为这个长长的信息感到抱歉！
我的工作环境
Linux的C / C + +（但我是新的Linux平台）
我简要的问题
在我正在处理的软件中，我们写了大量的日志消息给本地文件 ，这使得文件的大小增长很快，最后耗尽了所有的磁盘空间 （哎！）。 我们希望将这些日志消息用于故障排除目的 ，尤其是在软件发布到客户现场之后。 我认为，占用客户计算机的所有磁盘空间当然是不可接受的， 但我不知道如何处理这个问题 。 所以我想知道这里有没有什么好主意。 更多信息在下面。
我不是在问什么
1）。 我不是要求推荐的C ++日志库。 我们自己写了一个logging器。
如何使用控制台/ Windows应用程序而不关注它？
VLC将stream保存到文件
你如何pipe理日志logging性能？
2）。 我不会问什么细节（如时间戳，线程ID，函数名等）应该写在日志消息中。 一些build议可以在这里find。
我在我的软件中做了什么
我将日志消息分成三类：
系统：只logging我的软件中的重要步骤。 例如：一个外部调用到我的软件的接口方法。 背后的想法是从这些消息中我们可以看到软件中正在发生的事情。 这种消息并不多 。
错误：只logging错误情况，例如找不到ID。 通常这样的消息不多 。
信息：logging我的软件内部运行的详细步骤。 例如，当调用一个接口方法时，如上所述写入一个SYstem日志消息，并将整个调用例程写入接口方法中的内部模块中，并loggingINFO消息。 背后的想法是这些消息可以帮助我们确定详细的调用堆栈进行故障排除或debugging。 这是使用磁盘空间问题的根源 ：当软件正常运行时总是有很多信息。
我的尝试和想法
1）。 我试图不logging任何INFO日志消息。 这解决了磁盘空间问题，但是我也失去了很多debugging信息。 考虑一下 ：我的客户是在一个不同的城市，经常去那里是昂贵的。 此外，他们使用一个外部100％无法访问的内联网。 因此：一遇到问题，我们就不能总是派工程师到现场。 我们无法启动远程debugging会话。 因此，我认为日志文件是我们能够用来找出问题根源的唯一方法。
2）。 也许我可以在运行时 （在软件运行之前） 对日志策略进行configuration ，即：在正常运行时，软件只loggingSYstem和ERROR日志; 出现问题时，有人可以更改日志loggingconfiguration，以便可以loggingINFO消息。 但仍然：谁可以在运行时更改configuration？ 也许我们应该教育软件pipe理员？
3）。 也许我总是可以打开INFO消息login，但是将日志文件定期打包到压缩包中？ 嗯…
最后…
你的项目/工作经验是什么？ 任何想法/想法/意见，欢迎！
编辑
感谢您的所有努力！ 下面是所有答案的关键点摘要（我会给他们一个尝试）：
1）。 不要使用大型日志文件。 使用相对较小的。
2）。 定期处理最古老的（可以删除它们或将其放入较大的存储空间）。
3）。 实施运行时可configuration的日志logging策略。
如何捕获Linux framebuffer上的屏幕电影logging
在Linux系统上logging速度错误
debugginginstall4j在Linux上工作，但不是在Windows上？
强大的事件logging
有两件重要的事情需要注意：
极大的文件很笨重。 他们很难传播，很难调查，…
日志文件大部分是文本，文本是可压缩的
根据我的经验，处理这个问题的简单方法是：
只写小文件：为新会话启动一个新文件，或当前文件增长超过预设限制（我发现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（运行效率较低）。
您的（3）是UNIX系统日志记录的标准实践。
邮编或以其他方式压缩旧的
扔掉第一个最老的压缩日志
一旦达到一定的大小，开始登录到一个新的文件，并保持最后几个日志文件，然后再开始覆盖第一个。
你不会有所有可能的信息，但你至少会有一些东西导致这个问题。
记录策略听起来不寻常，但你有你的理由。
我会
a）在运行时对日志消息中的详细程度进行配置。 b）为每一天创建一个新的日志文件。 然后，您可以让cron压缩它们和/或删除它们，或者转移到off-ling存储器。
我的答案是写长记录，然后调整你想要的信息。
压缩他们每天 – 但保持他们一个星期
我喜欢记录很多。 在某些程序中，我将最后的n行保存在内存中，并在发生错误或用户请求支持的情况下写入磁盘。
在一个程序中，它会保留内存中的最后400行，并在出现错误时将其保存到日志记录数据库中。 一个单独的服务监视这个数据库，并发送一个包含摘要信息的HTTP请求到我们的办公室里的一个服务，这个服务把它添加到那里的数据库中。
我们在每台台式机上都有一个程序，显示一个问题列表（由F5更新），我们可以将这些问题分配给自己并标记为已处理。 但是现在我越来越多了:)
这很好地帮助我们支持几个客户的许多用户。 如果在运行我们的软件的PDA上发生错误，那么在一分钟内，我们会在屏幕上看到一个新的项目。 我们经常打电话给用户，然后才意识到有问题。
我们有一个过滤机制来自动处理或分配我们知道我们已经修复或不太在意的问题。
在其他程序中，我已经有小时或每天的文件，这些文件在n天后被程序本身或专门的日志清理服务删除。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
