NOM higher capacity trap receiver

[AndyKemp]

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.

[Vesselin Kotaro]

Steal the kafka stack from ArcSight 🙂

[AkashDeep]

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.

[AndyKemp]

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.

[Vesselin Kotaro]

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.

[Joe]

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

[AkashDeep]

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).

[AndyKemp]

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.