NOM higher capacity trap receiver

Idea ID 1795401

NOM higher capacity trap receiver

For larger deployments, a higher capacity trap receiver de-coupled from the main JVM instance would be a welcome improvement. Currently when an NNMi server experiences a rate above 40/second  with the default trapFilter.conf file, the JVM garbage collection begins to stutter  (S0, S1 nolonger queue and E hits 100) and finally dies.   I'm guessing that its single threaded.

I'd like a robust trap receiver that doesn't kill the main application when it experiences difficulty.

 

Tags (1)
7 Comments
Commodore Commodore
Commodore

Steal the kafka stack from ArcSight 🙂

Micro Focus Expert
Micro Focus Expert

Dear Submitter,

What is the trap rate you expecting?

Trap receiver is a separate process, and hence load should not kill the main application. If that is happening, we suggest you to get in touch with MF support for the issue.

Fleet Admiral Fleet Admiral
Fleet Admiral

Anything above ~40 traps per second causes issues with JVM Eden space as it tries to ingest them into the application. Only having 100K total traps supported for storage is pretty low unless your target market is for a mom and pop shop. If that's going to be the case, let me know and I'll steer T-Mobile to another vendor.

Commodore Commodore
Commodore

Fully agree with what @AndyKemp  wrote.

Just try to compare ArcSight ESM events per second handling capabilities and correlation engine with NNMi's and you will understand what we are talking about. Also, when under stress, NNMi simply stops trap reception and this is the moment when we need ALL the traps available.

As for the numbers - with 25k nodes on a single server it is pretty easy to reach 40 traps/sec with stable network. Single glitch in the network and NNMi's trapreceiver is off.

Captain
Captain

100k traps in a large environment isn't much headroom.  Agree with the comment above, NNM stops receiving when we need it most. 

Micro Focus Expert
Micro Focus Expert
Status changed to: Waiting for Votes

Dear Submitter,

You indicated that current supported trap rate is less, we would like to understand as what is the trap rate support you are looking for?

-------------

The idea has received an initial review to ensure adherence to our idea submission and community guidelines. More information may be needed at this stage, and we expect the community to help prioritize the idea with comments and community support (votes/kudos).

 

Fleet Admiral Fleet Admiral
Fleet Admiral

I hate to be imprecise, but a scaleable solution is what's needed. I have some devices which can send literally a thousand traps in under an hour and they all represent status changes to the services that they offer.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.