CSPM - Event Batching Timeout

[giovanni]

Hi guys,

can someone explain the usage of the field in subject? It can be found in the Edit -> Preferences dialog of the Event Viewer.

Ciao,

Giovanni

[danrodri]

My understanding of this feature is the timeout value assigned to control CSPM's event viewer (EV) receiving new alarms from the database. For instance, the default value is zero, which means the EV will display alarms as soon as they are "received" by the CSPM database. Changing the value will cause the alarms not to appear in "real-time" in the EV.

Hope that helps.

[giovanni]

Dan,

the Code Red worm has given us a chance to test this feature. Apparently it doesn't work like you describe, or it doesn't work properly.

It would be VERY useful now that CR events are coming up at a very high rate, but my event viewer interface is almost locked up by the continuous updating, although I've set a 60 seconds Event Batching Timeout.

Any ideas?

Giovanni

[marcabal]

I talked with the Event Viewer developer and here are his replies:

This is a bit embarrassing, but... the field the person

is asking about has no effect in CSPM. The Event Batching

Timeout was used in the standalone product when events

were read directly from the communications infrastructure.

The value specified how long to read events off the postoffice

before repainting the screen. In CSPM, however, we get

events from the CSPM database; the CSPM database has batching

functionality built into it already (the database sends events

to the event viewer in batches), so the event viewer simply

repaints the screen after it finishes processing a new batch

from the database, and doesn't have to keep track of any

timoute...

The bottom line is that the user can ignore this field. It's

probably just best to keep it at zero, which is the default.

In truth, we should have removed this field from the Preferences

Panel, but it slipped through the cracks.

He can keep the event viewer from flooding by setting the

"max events per grid" value in the preferences panel. If

the user is having troubles, he can set this value to a

fairly low number (like, say, 25,000), and this will ensure

that he'll never look at more than 25,000 events at a time.

He can look at "batches" of 25,000 events at a time, delete

them from the database when he is done, and then close and

reopen the event viewer to get the next "batch" of events.

If the user is using the event viewer and all of the sudden

he gets a flood of events that makes it difficult for him

to see what is going on because of all the screen repainting,

the user should press the Pause button, then manipulate the

events as he sees fit, and then press the Resume button to

see all the events that were inserted into the database since

the Pause button was pressed.

There is no way, however, to prevent the *event database*

from flooding. The "max events per grid" and the pause

button do not affect how many events go into the database

- they only affect the event viewer.

There are only two things that the user can do to ensure

that the database doesn't crash:

1) upgrade to CSPM 2.3.1i - the database has bug fixes

that reduce the likelihood of crashes

2) tune the sensors to diminish the number of events

sent to the database