持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第15天
一、问题描述
某天测试同学说客户端连接服务器错误，查看服务器连接数、连接状态、负载、tcp等相关信息，均无所获后，在 /var/log/messages 系统日志中发现了另一个问题：
Aug 8 03:41:48 localhost kernel: audit: backlog limit exceeded
Aug 8 03:41:48 localhost kernel: audit: audit_backlog=8198 > audit_backlog_limit=8192
Aug 8 03:41:48 localhost kernel: audit: audit_lost=10367555 audit_rate_limit=0 audit_backlog_limit=8192
Aug 8 03:41:48 localhost kernel: audit: backlog limit exceeded
Aug 8 03:41:48 localhost kernel: audit: audit_backlog=8198 > audit_backlog_limit=8192
Aug 8 03:41:48 localhost kernel: audit: audit_lost=10367556 audit_rate_limit=0 audit_backlog_limit=8192
一番搜索后，发现问题很严重啊 (ㄒoㄒ)，这里贴两个典型事例的连接：
www.cnblogs.com/qfdxxdr/p/8…
cikeblog.com/auditbacklo…
blog.csdn.net/sunny05296/…
其他的搜索结果大致也是如此，什么系统假死、需要重启等等...
解决的方法几乎都是修改 审计缓冲区 的上限值；
auditctl -b 8192
二、审计缓冲区的相关调查
因为是生产环境，不能随便修改参数；至少也得调查审计缓冲区的相关问题；
1、auditd 安全审计服务
在messages日志中，可以看到 kernel 后面的字段是 audit，这个audit是一个审计服务，它可以记录系统被入侵、攻击、不正当操作的详细的内容，当然，需要用户提前配置规则才行；
示例：
auditctl -w /etc/passwd -p rwxa
-w path : 指定要监控的路径文件
-p : 指定触发审计的文件/目录的访问权限
rwxa ： 指定的触发条件，r 读取权限，w 写入权限，x 执行权限，a 属性（attr）*/
如果 /etc/passwd 文件被读取、写入、执行或者属性被修改，都会触发审计日志（也可以是告警）；
这里也提供了一篇不错的文章：
CentOS7下安全审计工具Auditd的简单使用
审计规则集简介
2、什么是审计缓冲区？
简短描述：Linux 系统中的审计积压缓冲区是操作系统用来维护或记录审计事件的内核级套接字缓冲区队列。当新的审计事件触发时，系统会记录该事件并将其添加到审计积压缓冲区队列中。
以下是审计积压所需内存的计算公式。使用此计算公式来确定在不对实例造成内存压力的情况下可以设置多大的积压队列：
一个审计缓冲区 = 8970 字节
审计缓冲区的默认数量（backlog_limit 参数）= 8192
8192 * 8970 = 73482240字节 ≈ 70MiB
3、系统未配置审计规则，为什么会出现messages中的日志？
先用命令查看一下审计缓冲区的数值：
[root@hadoop3 docker_test]# auditctl -s
enabled 1
failure 1
pid 558
rate_limit 0
backlog_limit 8192 （Audit缓冲区缓冲上限个数）
lost 0 （丢失的Audit消息数）
backlog 0 （未输出的Audit缓冲区大小）
loginuid_immutable 0 unlocked
参数解释
enabled：是否启用审计，1为开启，0为关闭；
failure：0是不输出信息，静默状态；1是输出信息，输出到了/var/log/messages中；2是混杂模式，官方文档说安全环境中建议调整为2；
pid：auditd服务的进程号，为0则代表没开启此服务；
backlog_limit：审计积压缓冲区的上限；
lost：有多少事件记录由于内核审计队列溢出而被丢弃；
backlog：当前有多少事件记录排队等待审计来读取它们；
当 backlog > backlog_limit 时，/var/log/messages日志中就会出现上面的日志。
题外话：
1、至于是什么原因造成的积压不得而知，有文章说可能是系统网络流量大，或者读取了大文件，导致的缓冲区不够用。但排查过系统，都是正常的；
2、backlog 是只增不减的！（如果你的 backlog 不为0的话）；如果 backlog = 0 ，说明没有积压；但是如果不为0，你可以观察下，它会一直增长，直到超过你的backlog_limit值（上限）。
三、操作过程以及产生的问题
出现这种日志本身是没什么问题的，但是搜到的一些信息让人着实有点害怕，本着解决系统遗留问题的想法，还是要处理掉这个问题的；
1、修改backlog_limit值
系统原本默认的backlog_limit为8192，也就是8192个缓冲区（折合70M内存）；
为了稳定，增大这个数值时幅度不要太大，backlog_limit改为10240刚好，≈ 87M；
auditctl -b 10240
通过 auditctl -s 查看，backlog_limit的值已经改为了10240。此时 /var/log/messages 中也不在有审计的告警日志出现；现场等待了十几分钟，均正常。下班、回家 ヽ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾉ
2、问题复现
第二天，发现这该死的日志又出现了：
Aug 9 21:14:57 localhost kernel: audit: backlog limit exceeded
Aug 9 21:14:57 localhost kernel: audit: audit_backlog=10243 > audit_backlog_limit=10240
Aug 9 21:14:57 localhost kernel: audit: audit_lost=10430577 audit_rate_limit=0 audit_backlog_limit=10240
Aug 9 21:14:57 localhost kernel: audit: backlog limit exceeded
Aug 9 21:15:01 localhost kernel: audit: audit_backlog=10243 > audit_backlog_limit=10240
Aug 9 21:15:01 localhost kernel: audit: audit_backlog=10243 > audit_backlog_limit=10240
Aug 9 21:15:01 localhost kernel: audit: audit_lost=10430578 audit_rate_limit=0 audit_backlog_limit=10240
日志中说的很明显 10243 > 10240 ，我......
难道这个审计缓冲区不清理的？如果这么下去，backlog_limit 调整再大也没用，迟早还是要报错；
3、调整其他参数造成的机器重启
走投无路，开始查阅auditd的其他参数、服务说明、手册；
其中，对于auditctl命令，有这么几个参数：
Aug 9 21:14:57 localhost kernel: audit: backlog limit exceeded
Aug 9 21:14:57 localhost kernel: audit: audit_backlog=10243 > audit_backlog_limit=10240
Aug 9 21:14:57 localhost kernel: audit: audit_lost=10430577 audit_rate_limit=0 audit_backlog_limit=10240
Aug 9 21:14:57 localhost kernel: audit: backlog limit exceeded
Aug 9 21:15:01 localhost kernel: audit: audit_backlog=10243 > audit_backlog_limit=10240
Aug 9 21:15:01 localhost kernel: audit: audit_backlog=10243 > audit_backlog_limit=10240
Aug 9 21:15:01 localhost kernel: audit: audit_lost=10430578 audit_rate_limit=0 audit_backlog_limit=10240
稍等，我给大家翻译成中文：
-s #此处不翻译，-s参数就是查看的意思
-e [0..2] #是否开启审计日志
设置启用标志。
当传递0时，这可以用来临时禁用审计。
当1作为参数传递时，它将启用审计。
要锁定审计配置，使其不能被更改，请传递一个2作为参数。
锁定配置是审计的最后一个命令。
任何希望激活此功能的人的规则。
任何试图在此模式下更改配置的尝试都将被审计并拒绝。
只有重新启动计算机才能更改配置。
-f [0..2] #触发时的动作
设置故障模式0=silent 1=printk 2=panic。
该选项允许您确定希望内核如何处理关键错误。
该模式可能产生效果的示例条件包括:
向用户空间审计守护进程传输错误、积压限制超过、内核内存不足和速率限制超过。
默认值为1。
安全环境可能希望将此值设置为2。
-b backlog #修改审计缓冲区的上限
auditctl -e 就是可以动态的决定auditd审计日志的开启和关闭；
auditctl -f 可以决定出发审计规则之后的动作，0是没动作，1是输出（会输出到messages中），2是混杂模式；
通过man手册可以看到，在安全环境中，还是建议 auditctl -f 2 的；
同时也查阅了网上关于 -f 参数的文章，也是如此；本着稳定的运维精神，还是在测试环境测试了一把，auditctl -f 2 修改为 2 之后，修改成功，并且系统无异常- . -
于是，开始配置修改生产环境参数；
修改的同时，tail -f /var/log/messages 也在监控着日志的输出；
命令执行完毕，messages 也停止了之前的错误信息输出；
不！NO！它不是停止了输出，是卡住了！~ 赶紧到其他终端查看系统状态...
不！NO！它不是卡住了！是重启了，也可能是关机了！...卒...
各种告警开始频飞（系统配置了微信告警），不过还好，系统重启成功了；
服务相继启动后，业务恢复正常。
“auditctl -s” 再查看审计缓冲积压，也恢复了正常，且不再增长了。
就好像一场狂风暴雨，过后又阳光明媚...
四、总结
1、重启的原因
auditctl -f 2 之后机器重启的原因还在调查中,初步判断可能是清理临时目录、文件导致的，后面有结果再补充；
/var/log/messages 中重启前的日志只有这两条：
Aug 10 14:50:35 localhost systemd: Starting Cleanup of Temporary Directories...
Aug 10 14:50:35 localhost systemd: Started Cleanup of Temporary Directories.
2、重启能解决80%的问题
尽管生产环境的机器经历了1分多的重启（还好不是关机），但最终重启后问题解决了，
3、其他机器参数的对比
在排查问题过程中，查看了多台机器的审计积压情况，其他机器均没有审计缓冲积压状况，说明这种情况并不常见，且网上相关资料甚少，几乎都是 auditctl -b 调整上限值；
生产环境的机器出现审计积压日志，说明系统本身就已经存在一些问题了；
4、不同场景的错误日志
如果 “audit: backlog limit exceeded” 只是在你的messages日志中出现，并且系统可ssh，可ping通，那么大概率系统都还是正常的，并不像网上那样，出现假死、宕机。这样可以选择忽视（后期寻机重启解决），也可以 “auditctl -f 0” 不输出，或者 “auditctl -e 0” 禁用安全审计，再或者停止 auditd 服务；
5、处理方法
1、禁用审计日志
/etc/init.d/auditd stop
2、增加缓冲区大小
auditctl -b 10240
3、调试
aureport --start today --event --summary -i
aureport --start today
