Items of types "Zabbix trapper" and "SNMP trap" in some situations (improperly configured SNMP protocol on a network device (too many traps enabled by default for example), typo in Cron job definition, or in case of SNMP even an Ethernet storm because of let's say switching loop) may receive 'storm' of values and at this moment it's impossible to avoid it.

Theoretically it can lead to database performance degradation, disk space utilization, history syncers having to evaluate enormous amount of triggers for each received value, etc., storm of notifications and so on.

It'd be nice to either:

1. Have a special rate-limit parameter for these two types of items (e. g., no more than I values per J time period) similarly as we have a specific ACL parameter for Trapper.
2. Or introduce new 'Discard any value (with or w/o heartbeat)" preprocessing step which would extend this 'rate-limiting' functionality to all types of items (for example log monitoring with Zabbix Agent active where this also could be helpful). ZBXNEXT-5264 already exists with a similar request but perhaps for different purpose.
3. A global (not per-item) rate-limit parameter for whole trapper/SNMP trapper components would also be nice to have, probably defined as a configuration parameter

I'm not 100% sure which solution would be better architecturally/performance-wise in case of fore-mentioned scenarios. Maybe if we discard value before it's even communicated to preprocessing manager it would be faster (option 1 outlined above).