Anonymous_User Absent Member.
Absent Member.

Monitoring EPS of an event source?

We have a requirement to generate proper alerts whenever the EPS value
of an event source is over a predefined threshold fro a given period.

After some search on API documents I saw there is no-data alert
mechanism and also configuration for limiting dta rate from the event
source, but I could not find any mechanism for generating alert when the
event source's data rate is over some threshold value.

Is there a way to monitor eps values of event sources and generate
alerts properly?

Alternatively, limiting data-rates for database and file connectors may
be acceptable, but what about syslog event sources?

How can we catch event-drop situations so that some admin may be
informed via e-mail/sms.


hkalyoncu's Profile:
View this thread:

4 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Monitoring EPS of an event source?

Hash: SHA1

I cannot think of great ways to do this; Sentinel is made to audit
security events, and a decrease in security events isn't really a
security event in and of itself; usually if that happens to a point that
is a problem it is indicative of a system failure which is the realm of
tools like Nagios or NetIQ AppManager which are system/application/etc.
monitoring tools.

You could probably run a summary report from time to time for an event
source just to get an idea of counts coming in and have that
automatically e-mailed out. The mail could also include the list of
events as an attachment to be sent to a service account, even if it's on
the same machine as Sentinel itself, for some nice processing. I have
seen some people use things like postfix (mail server in SLES by
default)) to configure service accounts and actions for when e-mails
come to them automatically. Combining that with Sentinel's ability to
e-mail results and you could probably work up something to analyze data

Anyway, if your end goal is to know if an event source is down or not,
enable the alerts but keep in mind that it only alerts you if security
events are not coming in, which doesn't mean the system id down, or tell
you if the network is having problems delivering data, etc.

Good luck.
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined -

Anonymous_User Absent Member.
Absent Member.

Re: Monitoring EPS of an event source?

Well, you could easily set up a correlation rule to detect this
condition. Something as simple as:
trigger(60000, 60, discriminator(e.rv24)
would generate an alert if the number of events from a single source was
over 1000 for 60s.

This is likely to be an expensive rule, however, and may not be
necessary - you should investigate whether ESM already will complain if
the rate is exceeded.

But really I think your use case is whether events are dropped, and
that's kind of a different use case. How this works depends on the type
of source:

- For the Syslog Connector, the Syslog Event Source Server will simply
cache events that can't be processed fast enough until the system
recovers. It can cache a largish number of events, so although things
may be processed a bit late, it's unlikely to drop event data. Plus, it
will generate a nasty alert message if the entire cache overflow.
- For File/Database/WMI/etc, these are offset based so if they get
behind they will just keep working until they catch up. There's really
not much risk of losing events entirely unless the source "ages out" old
events aggressively.

In general, if a given source just keeps generating events faster than
Sentinel can process them for a really long period of time, eventually
the Collector will get so far behind that the caching or aging
mechanisms will overflow. This would be a pretty bad condition,
actually, but should also be pretty obvious - this would be something
like a single source sending > 1000 EPS for many minutes. In this case
what will really tell you if the processing is getting behind is if new
events coming into the system look "old", meaning that you start seeing
events that are from 2 minutes ago arriving at Sentinel now, and this
gets worse and worse.

Overall I guess what I'd tell your customer is something like "Look,
Sentinel makes aggressive use of caching and offset mechanisms to
prevent loss of event data under any conditions. In the very bad case
where some out-of-control source generates huge volumes of data for a
long time, you'll get some high-priority alerts from components like the
Syslog Connector. Otherwise what you'll see is that the processing just
gets a little bit behind, and then eventually catches up."

DCorlette's Profile:
View this thread:

Anonymous_User Absent Member.
Absent Member.

Re: Monitoring EPS of an event source?

Thanks David, this is what I was looking for 🙂

hkalyoncu's Profile:
View this thread:

Anonymous_User Absent Member.
Absent Member.

Re: Monitoring EPS of an event source?

what about SLM?
is there a place (e.g. postgresql table) where total events processed by
collector is stored?

hkalyoncu's Profile:
View this thread:

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.