ProTop provides default thresholds adjusted for common uses of various OpenEdge components. But what if they are too low for my configuration?
ProTop does a good job of providing an alert threshold based on OpenEdge's common uses. But as is often the case, one size does not fit all.
On the one hand, when default alert thresholds are lower than normal usage, ProTop will send alerts when your usage exceeds the default threshold, even though that activity level may be normal and, therefore, not interesting. This is called alert noise, which can be corrected by Reducing Alert Noise.
On the other hand, if your usage is lower than the default, no alerts will be sent. To correct this situation, review the default alert thresholds, compare them to your configuration and actual usage, and adjust them accordingly.
For example, the default threshold for sending an alert for the number of busy AppServer or WebSpeed agents is 100:
asBusy num > 100 "" "hourly" "&1 &2 &3" alert
If the ProTop Portal Trend charts report that you use at most 3 agents on average:
You will not get an alert even when twice the normal number of agents is started because the threshold is much too high at 100.
In this case, we need to change the alert definition for asBusy (busy app servers) to send an alert when say more than 5 app servers are running. That is about twice the average number of busy agents, and we should be alerted to this situation. We might also send an alarm when we see more than eight busy servers (80% of max) and another to send a page when the maximum number of agents (maxSrvrInstance for this app server is set to 10 in $DLC/properties/ubroker.properties) is reached at more than 9. Like this:
asBusy num > 5 "" "hourly" "&1 &2 &3" alert
asBusy num > 8 "" "hourly" "&1 &2 &3" alarm
asBusy num > 9 "" "hourly" "&1 &2 &3" page
Do you have some very busy and some not-so-busy app servers?
If you have app servers that vary significantly in the number of expected busy servers, consider setting up a second (or third, etc.) app server monitor and giving each an alert configuration file with thresholds that better reflect the expected number of busy app servers:
appsrv.asLoVol.cfg - this app server monitor would use this alert config file:
alert.asLoVol.cfg
asBusy num > 6 "" "hourly" "&1 &2 &3" alert
asBusy num > 8 "" "hourly" "&1 &2 &3" alarm
asBusy num > 9 "" "hourly" "&1 &2 &3" page (maxSrvrInstance=10)
appsrv.asHiVol.cfg - and this app server monitor would use this alert config file:
alert.asHiVol.cfg
asBusy num > 80 "" "hourly" "&1 &2 &3" alert
asBusy num > 90 "" "hourly" "&1 &2 &3" alarm
asBusy num > 99 "" "hourly" "&1 &2 &3" page (maxSrvrInstance=100