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

yao*_*bin 7 c++ linux logging

感谢您的宝贵时间,感谢抱歉!

我的工作环境

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

我的问题简单

在我正在处理的软件中,我们将大量日志消息写入本地文件,这使得文件大小快速增长并最终耗尽所有磁盘空间(哎哟!).我们希望这些日志消息用于故障排除,特别是在软件发布到客户站点之后.我认为占用客户计算机的所有磁盘空间当然是不可接受的,但我不知道如何处理这个问题.所以我想知道是否有人在这里有任何好主意.更多信息如下.

我不是在问什么

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

2).我不是在询问应该在日志消息中写入什么细节(例如时间戳,线程ID,函数名称等).一些建议可以在这里找到.

我在我的软件中做了什么

我将日志消息分为3类:

  • SYSTEM:仅记录我软件中的重要步骤.示例:外部调用我的软件的接口方法.背后的想法是从这些消息我们可以看到软件中通常发生的事情.有没有很多这样的消息.

  • 错误:仅记录错误情况,例如找不到ID.通常没有太多这样的消息.

  • 信息:记录我的软件中运行的详细步骤.例如,当调用接口方法时,如上所述编写SYSTEM日志消息,并且将使用INFO消息记录接口方法内的内部模块中整个调用例程.背后的想法是这些消息可以帮助我们识别详细的调用堆栈以进行故障排除或调试.这是耗尽磁盘空间问题根源:当软件正常运行时,总会有SO MANY INFO消息.

我的尝试和想法

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

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

3).也许我总是可以将INFO消息登录,但是会定期将日志文件打包到压缩包中? 嗯...

最后...

您在项目/工作中的经历是什么?欢迎任何想法/想法/意见!

编辑

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

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

2).定期处理最老的(删除它们或压缩并将它们放到更大的存储空间中).

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

blu*_*ift 5

您的(3)是UNIX系统日志记录的标准做法.

  1. 当日志文件达到特定年龄或最大大小时,请启动一个新文件
  2. 拉链或以其他方式压缩旧的
  3. 扔掉第n个最古老的压缩日志


Mat*_* M. 5

有两件事要注意:

  • 太大的文件很难处理。他们很难传播,很难调查,...
  • 日志文件主要是文本,并且文本是可压缩的

以我的经验,解决此问题的简单方法是:

  • 仅写文件:启动新文件进行新会话或当前文件超过预设的限制(我发现50 MB会非常有效)。为了帮助找到写入日志的文件,请将创建日期和时间作为文件名的一部分。
  • 离线(一旦文件完成)或在线(即时)压缩日志。
  • 实施常规的清理程序,删除所有X天之前的文件,或者每当您超过10、20或50个文件时,删除最旧的文件。

如果您希望将SystemError日志保留更长的时间,则可以将它们复制到仅跟踪它们的特定旋转文件中。

放在一起,将得到以下日志文​​件夹:

 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)
Run Code Online (Sandbox Code Playgroud)

根据是否可以计划(计划)清理任务,您可以简单地在应用程序中启动一个线程进行清理。无论您要使用清除日期还是要限制文件数,这都是有效的选择。

注意:根据经验,动态压缩时50MB的重量约为10MB,而离线压缩时的重量小于5MB(动态效率较低)。