日志很重要，然则别为其付出太多。
日志多用于审计和排错，在核心网络或者大负载服务器上，它很重要，然而却不是核心业务。
如果确认了自己的网络是安全的，请关掉日志。
内核有时候会因为日志不堪重负的。
在iptables防火墙上，使用ULOG而不是LOG纪录iptables日志，因为LOG使用耗时的printk，而ULOG则使用netlink直接将日志广播给用户态，真不行就overrun，而不是无条件写，这是对的，因为真的没有必要将每一个数据包都记录下来，iptables日志更多的在统计意义上有效，它们更多的要通过psad/gnuplot等程序绘制出图表以供分析。
编译内核的时候，减少printk缓冲区的大小：
Symbol: LOG_BUF_SHIFT [=17] #改成一个较小的数
x Prompt: Kernel log buffer size (16 => 64KB, 17 => 128KB)
x Defined at init/Kconfig:409
x Location:
x -> General setup
此时，我们应该信任syslog吗？是的，应该！
如果可能就在内核注册一个新的chain而不是在用户态使用iptable命令。
日志多用于审计和排错，在核心网络或者大负载服务器上，它很重要，然而却不是核心业务。
如果确认了自己的网络是安全的，请关掉日志。
内核有时候会因为日志不堪重负的。
在iptables防火墙上，使用ULOG而不是LOG纪录iptables日志，因为LOG使用耗时的printk，而ULOG则使用netlink直接将日志广播给用户态，真不行就overrun，而不是无条件写，这是对的，因为真的没有必要将每一个数据包都记录下来，iptables日志更多的在统计意义上有效，它们更多的要通过psad/gnuplot等程序绘制出图表以供分析。
编译内核的时候，减少printk缓冲区的大小：
Symbol: LOG_BUF_SHIFT [=17] #改成一个较小的数
x Prompt: Kernel log buffer size (16 => 64KB, 17 => 128KB)
x Defined at init/Kconfig:409
x Location:
x -> General setup
此时，我们应该信任syslog吗？是的，应该！
如果可能就在内核注册一个新的chain而不是在用户态使用iptable命令。
TP-LINK和D-Link的做法值得借鉴啊！
本文转自 dog250 51CTO博客，原文链接:http://blog.51cto.com/dog250/1270961
