In recent memory, Cloverleaf has been able to automatically generate alerts under a variety of scenarios. Unfortunately, the built-in alert actions that displayed a message on the console or placed a message in the log/error files were not terribly useful. Sending automatic emails on Windows was challenging. The latest Cloverleaf makes the emailing much easier and adds some useful functionality.
Here is a list of my favorite alerts:
Alert Type
|
Send an
alert when:
|
Thread status
|
A thread is up or down (or
opening) for specified period of time
|
Error count
|
A thread has more than X
errors
|
Outbound queue depth
|
More than X messages are
queued up waiting to be sent
|
Last send
|
The last message we sent
was more than X seconds ago
|
Disk % full
|
Just like it sounds
|
Last receive
|
The last message we
received was more than X seconds ago
|
System CPU %
|
Just like it sounds
|
File change
|
A file is updated
|
Transactions/sec
|
A thread is processing >
or < X transactions/second
|
Idle CPU %
|
CPU has less than X % idle
for Y minutes
|
Fittingly enough, the default file for the alert configuration is called “default.alrt”. You can change this under the “Site Daemons” by using the “Alert Cfg” button but I’ve never bothered with that. I have a feeling that if you did change it, you’d have to restart the Monitor Daemon for it to take effect. Unlike other configuration settings in Cloverleaf, the alerts take effect as soon as you save the alert file. Not like the NetConfig, where you have to bounce a thread or process for it to become active.
There is a file called “alerts.log” that is useful for troubleshooting. Cloverleaf adds an entry to this file each time an alert fires. This file is in your site directory under exec\hcimonitord.
Here is an example of an outbound queue depth alert that will notify us when two or more messages have been queued up for at least a minute:
Here are guidelines for setting up some of the common alerts:
Alert Type
|
Source
|
Source Count
|
Comparing
|
Comparing
Blank
|
Duration
|
Thread status
|
any
|
!=
|
up
|
N min (usually use 1 for 1
minute)
|
|
Protocol status
|
any
|
!=
|
up
|
N min (usually use 1 for 1
minute)
|
|
Error count
|
|||||
Outbound queue depth
|
any
|
>=
|
# of messages
|
N min (usually use 1 for 1
minute)
|
|
Last send
|
Any
|
>=
|
# of seconds
|
N min (usually use 1 for 1
minute)
|
|
Disk % full
|
Drive to monitor
|
all
|
>=
|
% e.g. 80
|
Once
|
Last receive
|
Any
|
>=
|
# of seconds
|
N min (usually use 1 for 1
minute)
|
|
System CPU %
|
|||||
File change
|
|||||
Transactions/sec
|
|||||
Idle CPU %
|
All
|
<=
|
% (e.g. 5)
|
N min (e.g. 5)
|
Automatically Bouncing a Thread
The screen shot above shows an example of stopping and restarting a thread automatically. Thread_Restart.bat is a generic .bat file I created that allows us to pass the site, process and thread names so it can be reused. Contact me if you’d like a copy of the file by calling:Jeff Robbins
Dynamic Health IT, Inc.
504-309-9103
or visit our Contact Us page.
Dynamic Health IT offers Cloverleaf Interface Development and Consulting.
Wow! this is a good read, thanks for sharing
ReplyDelete