Spectrum Southbound gateway Rsyslog use of SBGalertForwarding attribute

Products

• DX NetOps

Issue/Introduction

When setting up a Southbound integration in a distributed environment, to receive Rsyslog traps, alerts arrive hours late if the SBGalertForwarding attribute is enabled.

Environment

 Distributed fault tolerant SpecroServers with distributed Rsyslog server on each secondary SpectroServer sending syslog traps to respective primary.

 

Cause

This attribute SBGalertForwarding should only be used on EventAdmin / host models that live on the MLS, as the MLS needs to be contacted each time to locate the devices in the DSS. i.e. Rsyslog servers  should send all syslog traps to eventAdmin/ host models on the MLS to enable the attribute SBGalertForwarding to distribute to the other SpectroServers in the DSS.  Otherwise this attribute should be disabled or you may experience delays in receiving syslog traps.

 

Resolution

In a Distributed fault tolerant SpecroServer environment with distributed Rsyslog server on each secondary SpectroServer, the Rsyslog will send syslog traps to the respective SpectroServer i.e. the primary SS of the secondary it resides on (and not to the MLS), we should not enable this attribute.

 

Additional Information

Other recommendations to optimize distributed Rsyslogs.

1. Presently cache life is just 3 hours, hence we are not making full use of cache benefit. Increasing the timeout should improve the performance. 

2. this should be configured as a distributed solution with the SBGalertForwarding attribute disabled OR an MLS based syslog trap destination with the attribute enabled but NOT a mix of both as they had. Each time a sysog trap comes in, when the attribute is enabled, the SS has to contact the MLS to find the destination. So in order to enable the attribute, the best way is to create 4 Host_SystemEdge models on MLS and make all rsyslog servers to send the traps to MLS. This we will definitely improve the performance due to the following:

a. All the landscapes in DSS, will send request to MLS for finding out device landscape id, By creating Host_SystemEdge models on MLS itself we can avoid calls related to this. 

b. The cache created will be shared by all the SystemEdge models. Hence searching will be faster.

c. As the MLS doesn't have any devices, it need not spend time in polling and other things and hence it can dedicate it's time for trap/event processing.