Hi Scott,
- If you don't batch alerts (the default), entry alerts are triggered
when a changelog records is processed about the entry. So this depends
on the filesystem activity/access patterns.
In the particular case of dircount alerts, this means the directory
count is checked when there is a changelog record about the directory
itself (but not for events on sub-entries). As creating a sub-directory
entry doesn't necessarily trigger a record about the parent directory
this may explain you have such an erratic frequency, depending if users
perform directory operations like chmod, etc...
- If you batch alerts, alerts are trigered when the configured batch
size is reached (Log::batch_alert_max parameter).
Of course, triggering the alert or not also depends on your alert
definition (eg. if you have specified criteria on last modification,
last access...).
Alert behavior is expected to change in RBHv3: the plan is to turn alert
matching into policies like others, so they will be checked afterwards,
not immediately when the changelog record is processed. This will make
alert frequency more controllable and predictable :)
Regards,
Thomas
On 09/09/14 19:39, Scott Nolin wrote:
Hello,
I'm trying to understand how often alerts run and why.
We are using tmpfs on lustre with changelogs (so no scans except
initial).
I have three filesystems that have some alerts to report. One seems to
send the alert every 90 seconds, another every 40 minutes, and finally
one seems to go on it's own yet-to-be-determined schedule. Like every
few days.
The systems are generally set to do purges (if they purge) every 12
hours. They never do scans since they initial.
From the manual it seemed that it would happen on each scan, but we
don't scan. Otherwise, makes sense it would be at each purge period,
but I don't see tha really.
The type of alert I'm looking at now is a pretty simple one - too many
files in directory.
Thanks for any insight.
Scott
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
robinhood-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/robinhood-support
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
robinhood-support mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/robinhood-support
