-
Type:
Problem report
-
Resolution: Fixed
-
Priority:
Trivial
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
Hello Zabbix Support Team,
We are facing an issue on one of our Zabbix proxies related to uncontrolled disk usage growth caused by SNMP trap logging.
Issue summary
On this proxy, the directory:
/var/log/snmptrap
is currently consuming approximately 36 GB of disk space.
This usage is entirely due to a single file:
/var/log/snmptrap/snmptrap.log
(~38 GB, no rotation in place)
For comparison, we have another Zabbix proxy with equivalent SNMP trap functionality where the same directory only uses a few kilobytes, which strongly suggests abnormal behavior on this specific proxy.
Evidence and findings
- The /var/log/snmptrap directory contains only one file (snmptrap.log) with ~38 GB:
rw-rw-rw 1 root root 37930080417 snmptrap.log
- No log rotation is occurring for this file.
- Live monitoring (tail -f snmptrap.log) shows a continuous and high volume of incoming SNMP traps from multiple source IPs.
- A significant portion of the traps are logged as:
unmatched trap received from "<source IP>"
- These "unmatched" traps are:
-
- received by the proxy
-
- processed
-
- discarded functionally (no matching SNMP trap item)
-
- but still fully written to disk
- The same "unmatched trap received" messages are also visible in zabbix_proxy.log, confirming that the Zabbix Proxy is actively handling and rejecting these traps.
- MariaDB service is healthy and stable, with:
-
- no abnormal growth
-
- no backlog
-
- no errors related to trap processing
Current understanding
- Zabbix does not automatically manage or rotate files under /var/log/snmptrap
- The excessive disk usage is caused by:
-
- continuous SNMP trap flooding
-
- a high number of traps not matching any configured SNMP trap items
-
- lack of log rotation for snmptrap.log
- This behavior differs from another proxy with similar configuration, where SNMP trap logging remains minimal.
Questions
- Are there known Zabbix Proxy or SNMP trap processing scenarios where unmatched traps can lead to excessive filesystem log growth?
- Are there Zabbix-side best practices or recommended configurations to:
-
- reduce logging of unmatched traps, or
-
- limit their impact on disk usage?
- Are there specific proxy or SNMP trapper settings that should be validated to explain the behavioral difference between these two proxies?
If required, we can provide:
- Zabbix Proxy version
- Operating system details
- SNMP trap configuration
- Extracts or samples from snmptrap.log and zabbix_proxy.log
Thank you in advance for your support.
Best regards,