减少 SNMPd 日志记录的详细程度

Question

我的 CentOS 系统上的 SNMPd 每次收到来自我的监控工具的查询时都会向 syslog 发送日志消息。有没有办法降低 SNMPd 的冗长程度？它给日志增加了很多混乱。

Sep 12 13:05:40 myhost snmpd[7073]: Received SNMP packet(s) from UDP: [ipaddr]:42874
Sep 12 13:05:40 myhost snmpd[7073]: Connection from UDP: [ipaddr]:49272

谢谢！

Answer 1

检查启动的命令snmpd（可能在某处/etc/rc.d/- 在 Ubuntu 中/etc/defaults/snmpd）以获取日志记录选项：

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -g root 0.0.0.0'

或者在ps aux | grep snmpd输出中找到它。

该手册页给出了记录选项：

-Ls 设施

通过系统日志记录消息，使用指定的工具（'d' 代表 LOG_DAEMON，'u' 代表 LOG_USER，'0'-'7' 代表 LOG_LOCAL0 到 LOG_LOCAL7）。这些选项中的每一个也有“大写”版本，允许将相应的日志记录机制限制为消息的某些优先级。

对于 -LF 和 -LS，优先级规范出现在文件或设施标记之前。公认的优先事项是：

0 or ! for LOG_EMERG,
1 or a for LOG_ALERT,
2 or c for LOG_CRIT,
3 or e for LOG_ERR,
4 or w for LOG_WARNING,
5 or n for LOG_NOTICE,
6 or i for LOG_INFO, and
7 or d for LOG_DEBUG. 

默认值相当冗长（仅比调试低 2 个级别）：

正常输出（或将要！）以 LOG_NOTICE 的优先级记录

如果您通过 LOG_DAEMON (-Lsd) 登录到 syslog，您可以将其减少为例如 LOG_WARNING with -LSwd/-LS4d或 LOG_ERR with -LSed/ -LS3d。

（编辑以按正确的顺序排列选项。）

Answer 2

为了将最小优先级设置为 LOG_WARNING，（这是我通常使用的），只需更改 argopt：

-LSD

到

-LSwd

代表：

• S : 系统日志，优先级次之
• w：（或4）只记录警告和更多相关消息
• d : 使用 LOG_DAEMON 工具

正如man中所述（但实际上缺少一个明显的例子）：

对于 -LF 和 -LS 优先级规范出现在文件或设施标记之前

Answer 3

dontLogTCPWrappersConnects

如果 snmpd 是用 TCP Wrapper 支持编译的，它会记录与代理的每个连接。此设置禁用已接受连接的日志消息。拒绝的连接仍将被记录。

即添加dontLogTCPWrappersConnects true到snmpd.conf。

对于监控服务（以及支持 UDP 的服务），为什么在 LOG_DEBUG 之上考虑此日志消息：-(。 journalctl -o verbose显示消息具有 PRIORITY=6 (INFO)，这与 snmpd 的正常启动消息相同.

Answer 4

我从/etc/sysconfig/snmpd.optionsCentOS/Redhat 安装的文件中完全删除了“-Lsd”指令，留下一个文件，内容如下：

# snmpd command line options
OPTIONS="-Lf /dev/null -p /var/run/snmpd.pid -a"

Answer 5

包含标准（包含在/etc/snmp/snmp.confCentOS 6.5的默认文件中）行对我有用，以减少与 TCP/UDP SNMP 连接日志相关的详细程度：

dontLogTCPWrappersConnects yes

这是默认snmp.conf文件中更“详细”的摘录：

# We do not want annoying "Connection from UDP: " messages in syslog.
# If the following option is commented out, snmpd will print each incoming
# connection, which can be useful for debugging.

dontLogTCPWrappersConnects yes