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

Question

感谢您抽出宝贵时间，对这么长的消息深表歉意!

我的工作环境

Linux C/C++(但我是 Linux 平台的新手)

我的问题简述

在我正在开发的软件中，我们写了 很多 日志消息 到本地文件 这使得文件大小快速增长，最后 用完所有磁盘空间 (哎哟!)。我们想要这些日志消息 用于故障排除 ，尤其是在软件发布到客户站点之后。我相信占用客户电脑的所有磁盘空间当然是不能接受的，但我不知道如何处理这个 .所以我在想 如果有人在这里有什么好主意。更多信息如下。

我不是在问什么

1)。我是 不是 要求推荐的 C++ 日志库。我们自己写了一个记录器。

2)。我是 不是 询问应该在日志消息中写入哪些详细信息(例如时间戳、线程 ID、函数名称等)。可以找到一些建议here .

我在我的软件中做了什么

我将日志消息分为 3 类:

SYSTEM:只记录我软件中的重要步骤。示例:对我的软件的接口(interface)方法的外部调用。背后的想法是从这些消息中我们可以看到软件中通常发生的事情。那里不多这样的消息。

ERROR:仅记录错误情况，例如未找到 ID。通常有不多这样的消息。

信息:记录在我的软件中运行的详细步骤。比如调用一个接口(interface)方法的时候，写了一个SYSTEM日志信息，如上面所说，整个调用例程进入内部模块 在接口(interface)方法中将记录 INFO 消息。背后的想法是这些消息可以帮助我们识别用于故障排除或调试的详细调用堆栈。这是磁盘空间用尽问题的根源 : 总有这么多 软件正常运行时的 INFO 消息。

我的尝试和想法

1)。 我试图不记录任何 INFO 日志消息。 这解决了磁盘空间问题，但我也丢失了很多调试信息。 想想这个 : 我的客户在不同的城市，经常去那里很贵。此外，他们使用从外部 100% 无法访问的内部网。因此:我们不能总是一遇到问题就派工程师到现场；我们无法启动远程调试 session 。因此，我认为日志文件是我们可以用来找出问题根源的唯一方法。

2)。 也许我可以在运行时配置日志记录策略 (目前是在软件运行前)，即:在正常运行时，软件只记录SYSTEM和ERROR日志；当出现问题时，有人可以更改日志记录配置，以便可以记录 INFO 消息。但仍然:谁能在运行时更改配置？也许我们应该教育软件管理员？

3)。 也许我总是可以打开 INFO 消息登录但定期将日志文件打包成压缩包？ 唔...

最后...

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

编辑

感谢您的所有努力!!! 以下是所有回复的要点摘要(我会尝试一下):

1)。不要使用大型日志文件。使用相对较小的。

2)。定期处理最旧的(删除它们或压缩并将它们放入更大的存储空间)。

3)。实现运行时可配置的日志记录策略。

Answer 1

有两个重要的事情需要注意:

非常大的文件是笨拙的。他们很难传播，很难调查，...

日志文件多为文本，文本可压缩

根据我的经验，处理这个问题的简单方法是:

只写小文件:为新 session 启动一个新文件，或者当当前文件增长超过预设限制时(我发现 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(即时效率较低)。