Some more information now that I have spent many hours trying to figure out why the script causes problems. There were WAY too many events in the database. It just takes too much time a CPU and maybe disk I/O for the script to delete so many events.

So, far today, with the workaround below in place, I am not getting any heartbeat failures, I am doing pretty aggressive pinging (30 seconds cycle) and aggressive SNMP collection (60 seconds). I can also do a /24 discovery without causing heartbeat failures.

My workaround is as follows:

A. Severely reduce the number of Windows events being picked up. I set //Devices/Server/Windows/zProperties/zWinEventlogMinSeverity = 2, so Zenoss only picks up Warning and Error Windows events. This cuts the number of events per hour from many thousands (almost all Security events) to maybe 10-100.

B. Get rid of all events in history by deleting and re-creating MySQL Events database. This was the only way I could think of to reduce the size of the database to something that is manageable. It had about 10 million total rows and any serious deletion of records seemed to bring the system to a crawl for hours.

1. Drop the events database (logged in as zenoss):

mysqladmin -prootpassword drop events

2. Create a new events database (logged in as user zenoss)

zeneventbuild localhost zenoss zenossuserpassword events

3. Create additional permissions as needed to run remote SQL Administrator

Doesn’t seem to be necessary

C. Configure the collector to delete events in history older than 60 days (/ZenEventManager/Delete Historical Events Older Than (days)=60). This is a guess based on my wanting to limit the database to something like 1-2 million rows max. I am currently collecting about 15,000 events per day most of which will go into the history table which figures to be 1-2 million rows in 60 days.