我们采用Linux的syslog来记录产品的debug log。调用其中的一个可执行文件，执行完命令之后，查看debug log的信息，居然从某一条log之后的log都丢失了。多次尝试后，发现每次都在某条固定的log之后的log都丢失了。这篇博文就让我们一起来探个究竟。
在发现真正问题之前我做了以下尝试：
(1) 进程是否在固定log之后某种逻辑退出？或者在固定log打印之后的语句中会产生信号导致进程终止？ 在程序末尾打印一个消息到屏幕，可以看到程序正常运行，并退出。
(2) 是否debug log对象发生了改变，或者debug level在运行中发生了改变？ 同样在程序中打印这些信息，发现并无异常。
(3) gdb调试查看程序走的分支逻辑
如上方法均未发现问题，其实还有一种想法：syslog会不会丢弃一些log信息？但一开始是被我排除的，当时原因有二：第一在Redhat4/5上均不会出现这个问题；第二Redhat 6平台上的产品已经发布了至少一年了，要是debug log总是缺少应该不会等到我来发现吧。然而，正是由于一些惯有的思维，或者是一些看似有理却不严谨的推断，导致真相姗姗来迟。
接着，我优先查看了/var/log/messages文件, 看到了如下的错误信息，而6292正是我之前执行的进程ID。
imuxsock begins to drop messages from pid 6292 due to rate-limiting那么很显然，于是很快利用google神器，找到了原因，这个是和Redhat 6中的rsyslog的机制有关系，并且这些机制可配置。
所谓Rate limit就是指，在某个固定的时间段内，syslog最多允许打印的log信息数量（多出的log信息将被丢弃）。在Redhat 6中，由配置文件/etc/rsyslog.conf中以下两个配置项决定：
$SystemLogRateLimitInterval [Number1]: Number1 为设定的限制的时间间隔大小
$SystemLogRateLimitBurst [Number2]: Number2 为在设定的限制的时间间隔内,最多输出的log信息数量。
在设定完后，则表示在每一个Number1时间间隔内，如果超过Number2个数的log信息将会被去除。默认Number1为5秒钟，Number2为200.但如果我们不希望，在打印的log时有丢失，则可以在/etc/rsyslog.conf中添加或者设置：
$SystemLogRateLimitInterval 0当然设置完成后，一定要记得重新启动rsyslog服务(用命令:service rsyslog restart)哦~~~
参考：
1. https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=753363
2. http://lists.adiscon.net/pipermail/rsyslog/2011-April/028307.html
3. http://www.rsyslog.com/tag/rate-limiting/
Redhat 6中syslog信息丢失,布布扣,bubuko.com
原文：http://blog.csdn.net/cjf_iceking/article/details/37655659