5.7 alert problem

Hi David,

I have no experience with alerts for error count changes, so can’t help you there.

But my first reaction is to try to ‘touch’ your alert file (normally ‘default.alrt’). This way the monitor daemon will see that a ‘new’ alert file and will start a new cycle of monitoring. (Not very well explained, but I hope you get my drift.)

I’d like to suggest that the alert fired at 1 and stayed true.

The alert condition needs to be cleared before firing again.

You probably have to zero out the statistics to get the error count back to zero.

Also, you have it set to fire once?

You may want to set repeat in 5.7 and a maximum.  I will check my setting tomorrow since I use this alert as well.  I know it is working in 5.7.

Once an alert fires, you must touch the file to enable Cloverleaf to reset the alert, so it will recognize that alert condition when it occurrs again. Clearing statistics doesn’t have anything to do with this.

We use a cron job to touch the file hourly, so any alert conditions not cleared by then will re-fire.

Not to hijack the discussion but if you don’t clear the statistics and the thread has an error count, and your alerts run say from 8am to 11pm, then every morning when the alert wakes back up at 8am, the engine will fire the alert again.

We had the same issue when we converted our 5.5 Alerts to 5.7

We changed our alert time windows from “by event time” to “by range”

So if you vi the default.alrt file you will see the paramenter change from { WINDOW * * * * } to { WINDOW */*/*/* }. Hope this works for you.

I seem to have the same issue as you at two of my clients.  I haven’t yet figured out the cause.  The monitorD correctly parses the alerts file, but doesn’t crash until the alerts fires.  And whats frustrating, is if I move this alert file to their test box and try to reproduce, it works fine.

Both servers are:

CL 5.7 (ones Rev1 the other Rev2)

Redhat 5.3

The crashes might be the monitord log files getting to large.  We had this same problem when we moved to 5.7.

I had to add

for each of our sites when we cycle our log and smat files to ensure the monitord logs are cycled also.  Under 5.2 at least only the actual command received was written to the log but now the data that is returned is also written to the log so with alerts firing it can get large very quickly.

We recently moved from version 5.3 to 5.7 sp2 and we had to do a lot of work on our alerts to get them to work. The biggest problem was getting an alert to run once a day at a specified time. We have the same alert programmed on 7 different sites, and on some of them it would run and reset, and on some it wouldn’t. Reloading the alerts with the Site Daemons gui would sometimes result in them running that night, but sometimes it wouldn’t, only actually stopping and starting the monitor daemon was sure to make them run at least once, but even then, some would reset and some would not.

One thing that has seemed to be successful is to use the repeating field. If you tell it to repeat every 1440 minutes it runs once a day at the same time and it doesn’t require that it gets reset.

One and All,

We have discovered in moving from 5.6R2 to 5.7R2 that any “ampersand” (&) that is exec type alerts that you have directed to run in the background need to be removed – they error and you will see “failed” to trigger in the hcimonitord logs.   These will not execute.

Following the discussion about the repeat option closely.

Thanks to all who post on alert issues for 5.7R2.

Happy Holidays!