Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1516643 - [RFE]status and utilization not repeating snmp traps
Summary: [RFE]status and utilization not repeating snmp traps
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: web-admin-tendrl-notifier
Version: rhgs-3.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Nishanth Thomas
QA Contact: sds-qe-bugs
URL:
Whiteboard:
Depends On: 1515276
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-23 07:55 UTC by Lubos Trilety
Modified: 2018-12-07 11:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-07 11:22:29 UTC


Attachments (Terms of Use)

Description Lubos Trilety 2017-11-23 07:55:32 UTC
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.

Comment 1 Nishanth Thomas 2017-11-23 10:29:15 UTC
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.

Comment 2 Lubos Trilety 2017-11-23 11:26:40 UTC
(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.

Comment 4 Nishanth Thomas 2018-12-07 11:22:29 UTC
This is minor RFE which we are not planing to implement in any of the upcoming releases. Closing the Bz


Note You need to log in before you can comment on or make changes to this bug.