ESA Performance

[RenatoGoncalves]

I recently found a thread: with this written:https://community.rsa.com/docs/DOC-83654 

This topic explains how to configure the ESA database to maintain a healthy level of alerts

This procedure is optional. Administrators can specify a retention period for alerts. Deleting old alerts is a best practice to maintain the alerts database. Otherwise, the database could continue to grow and eventually have a negative impact on performance.

Which impacts can it have? Service down? Sessions Behind?

[EricaChalfin]

Renato Goncalves‌,

I've moved your question to the RSA NetWitness Platform" data-type="space space where it will be seen by the product's support engineers, other customers and partners.  Please bookmark this page and use it when you have product-specific questions.

Alternatively, from the RSA Customer Support" data-type="space‌ page, click on Ask A Question on the blue navigation bar and choose Ask A Product Related Question.  From there, scroll to RSA NetWitness Platform" data-type="space  and click Ask A Question.  That way your question will appear in the correct space.

Regards,

Erica

[someone]

In 10.6.x, if the alerts DB size is around 10GB or more (sometimes even less), ESA will not be able to open the database. So for example, when you go to Summary page, the alerts won't load. 

The ESA storage page you posted is not accurate. I spent 11 months with RSA engineering so they confirm that the "Alert age" retention does not work and was never designed to work. Then Support closed the case and offered me to raise an RFE so they make the product according to the documentation you posted. Hopefully the documentation team will correct the documentation sometime in the future so that is inline with the product capabilities.

With that said, your options for storage maintenance is "By database size", not sure about "both database size and alert age" since the "alert age" does not work. 

I would definitely recommend some kind of storage maintenance on ESA to avoid making the database inaccessible and having to delete alerts as emergency (using things like ESAtool, manually, or to completely having to purge the contents depending on severity).

I hope this helps.

[JohnKisner]

Renato,

Yes if the alerts database grows too large it can cause performance issues. The Summary page, as mentioned by Marinos, will stop responding as well as alerting can be affected. The ESA server can appear to hang if the database is too large.

In 11.x there is no longer a ESA database for alerts. Instead all alerts are sent to the Respond alert database and the Respond service is responsible for maintaining the database. So please note that if you are on 11.x the post you reference will not be appropriate as the explore nodes will not be visible.

https://community.rsa.com/docs/DOC-80098 

[RenatoGoncalves]

Hello John,

Yes im using 11.2...i was aware of that change, i probably i made a mistake in exposing the question but for us ESA is "everything", and we usually join ESA and Respond Server when we speak.

The issue is taht we are constantly with sessions behind on ESA and we have a support case with engineering, but is taking too long and we still have sessions behind that are resolved with rebooting ESA and disabling the rules ( whos only use is 1% ) for a couple of minutes. After that the alerts are fired correctly and with no delays.  At the time of the contact with support one of the things that were mencioned was the retention that probably could be one of the point in the problem.

[JohnKisner]

Renato,

Based on what I am seeing in your case and the JIRA that is opened for it the alert database isn't the issue. The Support Engineer sees that it is about 1.2GB in size which isn't a problem but did want to make sure that maintenance was turned on so you didn't run into issues later. The Engineering case says that there may be some network latency that may be aggravating the situation when the underlying concentrators get spikes of traffic through out the day. There are also a few suggestions for turning on more debug logging of services to see what may be going on. They also mention a particular ESA rule that is supplied by us that they are going to check internally on.

As this is an open forum I'm not going to provide any further details about the exact debug logging or the rule in question. However I suggest you talk with your Support Engineer about these items to get more details. 

[RenatoGoncalves]

Hello John,

Im talking with the support engineer and he is studying the case, well see

Now im just trying to gather information on how the retention could affect ESA to make a report for my boss, for him to see if we change or not the retention time. We are using a outside ticketing plataform who receives the alerts and with that im in favour of changing the retention period but....its my boss who's in charge

[JohnKisner]

I'm glad to hear you are working with a Support Engineer. They should be able to help you get this straightened out.

Good luck with your boss