感谢您抽出宝贵时间，感谢抱歉！
Linux C / C ++（但我是Linux平台的新手）
在我正在处理的软件中，我们将大量日志消息写入本地文件，这使文件大小快速增长，最后全部用完磁盘空间（哎哟！）。我们希望这些日志消息用于解决问题，尤其是在将软件发布到客户站点之后。我认为占用客户计算机的所有磁盘空间当然是不可接受的，但我不知道如何处理这个。所以我想知道如果有人在这里有任何好主意。更多信息如下。
1）。我不要求推荐的C ++日志库。我们自己写了一个记录器。
2）。我不询问应该在日志消息中写入哪些详细信息（例如时间戳，线程ID，函数名称等）。可以找到一些建议here。
我将日志消息分为3类：
SYSTEM：仅记录我软件中的重要步骤。示例：外部调用我的软件的接口方法。背后的想法是从这些消息我们可以看到软件中通常发生的事情。 没有多少这样的消息。
错误：仅记录错误情况，例如找不到ID。通常不是很多这样的消息。
信息：记录我软件中运行的详细步骤。例如，当调用接口方法时，如上所述编写SYSTEM日志消息，并且接口方法中的整个调用例程进入内部模块将与INFO消息一起记录。背后的想法是这些消息可以帮助我们识别详细的调用堆栈以进行故障排除或调试。这是用尽磁盘空间问题的来源：当软件正常运行时，总会有 SO MANY INFO消息。
1）。 我试图不记录任何INFO日志消息。这解决了磁盘空间问题，但我也丢失了很多调试信息。 想一想：我的客户位于不同的城市，经常去那里很贵。此外，他们使用的是一个100％无法从外部访问的内部网。因此：我们不能总是在遇到问题时立即派遣工程师到现场;我们无法启动远程调试会话。因此，我认为日志文件是我们用来找出问题根源的唯一方法。
2）。 也许我可以在运行时配置日志记录策略（目前它在软件运行之前），即：在正常运行时，软件只记录SYSTEM和ERROR日志;当出现问题时，有人可以更改日志记录配置，以便记录INFO消息。但仍然是：谁可以在运行时更改配置？也许我们应该教育软件管理员？
3）。 也许我总是可以将INFO消息登录，但是会定期将日志文件打包到压缩包中吗？嗯......
您对项目/工作的体验是什么？欢迎任何想法/想法/意见！
感谢您的所有努力!!! 以下是所有回复中关键点的摘要（我会试一试）：
1）。不要使用大型日志文件。使用相对较小的。
2）。定期处理最旧的（删除它们或压缩并将它们放到更大的存储空间中）。
3）。实现运行时可配置的日志记录策略。
答案 0 :(得分：5)
您的（3）是UNIX系统日志记录的标准做法。
答案 1 :(得分：4)
处理它的一种方法是轮换日志文件。
一旦达到一定的大小，就开始登录到新文件，并在开始覆盖第一个日志文件之前保留最后几个日志文件。
您将无法掌握所有可能的信息，但至少会有一些问题可以解决问题。
记录策略听起来很不寻常，但你有理由。
答案 2 :(得分：4)
有两件重要的事情需要注意：
根据我的经验，处理这个问题的一个简单方法是：
如果您希望将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 :(得分：3)
我会
a）使日志消息中的详细级别在运行时可配置。 b）为每天创建一个新的日志文件。然后，您可以让cron压缩它们和/或删除它们，或者转移到异常存储。
答案 4 :(得分：0)
我的回答是编写长日志，然后推出你想要的信息。
每天压缩它们 - 但保留一周
答案 5 :(得分：0)
我喜欢记录很多。在某些程序中，我将最后n行保留在内存中并在出现错误或用户请求支持时写入磁盘。
在一个程序中，它会将最后400行保留在内存中，并在出错时将其保存到日志数据库中。一个单独的服务监视此数据库，并将包含摘要信息的HTTP请求发送到我们办公室的服务，该服务将其添加到那里的数据库。
我们在每台桌面计算机上都有一个程序，显示了一个列表（由F5更新）的问题，我们可以将这些问题分配给自己并标记为已处理。但是现在我被带走了。）
这非常有效地帮助我们为多个客户的许多用户提供支持。如果在某个运行我们软件的PDA上发生错误，那么在一分钟左右的时间内我们就会在屏幕上显示一个新项目。我们经常在用户意识到他们遇到问题之前给用户打电话。
我们有一个过滤机制来自动处理或分配我们知道我们已修复或不关心的问题。
在其他程序中，我有每小时或每天的文件，这些文件在n天之后被程序本身或专用的日志清理服务删除。