Description of problem: All status and utilization alerts which have some clearing alerts should generate snmp traps regularly. There should not be sent just one trap when the "bad" state is found, but sent another one every time when check is done and the "bad" state remains. That's a common thing how snmp traps work. The reason behind this is all snmp traps are sent via UDP without any acknowledgment that the traps were received on client. So these critical alerts (critical for proper functionality) are sent repeatedly till the issue remains. As of now that's not how RHGSWA works. Only one trap is sent for any event. Even those which are checked regularly. Version-Release number of selected component (if applicable): tendrl-ansible-1.5.4-1.el7rhgs.noarch tendrl-ui-1.5.4-4.el7rhgs.noarch tendrl-grafana-plugins-1.5.4-5.el7rhgs.noarch tendrl-selinux-1.5.3-2.el7rhgs.noarch tendrl-commons-1.5.4-4.el7rhgs.noarch tendrl-api-1.5.4-2.el7rhgs.noarch tendrl-api-httpd-1.5.4-2.el7rhgs.noarch tendrl-monitoring-integration-1.5.4-5.el7rhgs.noarch tendrl-grafana-selinux-1.5.3-2.el7rhgs.noarch tendrl-node-agent-1.5.4-5.el7rhgs.noarch tendrl-notifier-1.5.4-3.el7rhgs.noarch How reproducible: 100% Steps to Reproduce: 1. Set up RHGSWA SNMP server 2. Generate some status alert for which a clearing alert exists (e.g. stop glusterd on some gluster node) 3. Wait a while Actual results: Only one trap is generated for the status, no other is sent Expected results: The same trap is generated repeatedly e.g. every time the status is checked Additional info: Of course the same is not applied for mails. For mails it's OK and required that only one mail is sent for any event.
We cannot send traps continuously(every sync) which floods into receiving application. If required we can configure retries; if there is failure in sending traps it will retry the configured no of times. Sending traps during every sync is not something we would like to implement.
(In reply to Nishanth Thomas from comment #1) > We cannot send traps continuously(every sync) which floods into receiving > application. If required we can configure retries; if there is failure in > sending traps it will retry the configured no of times. Sending traps during > every sync is not something we would like to implement. In most snmp clients which are used nowadays it's counted with repeating traps and only the first one is displayed. I don't know how often the sync is but you don't have to worry much about flooding a receiving application. Still I agree with using your suggested solution (just be sure repeated traps are sent only when clear alert didn't arrive) or we can send the trap, lets say, every tenth sync.
This is minor RFE which we are not planing to implement in any of the upcoming releases. Closing the Bz