I would like to monitor an analog parameter which is expected to increase in the specific rate in normal situation.
The delta is +480 in normal case, the analog parameter value will keep increasing at the same pace, +480 per poll.
e.g.
Say for example, the first poll is 480, the second measured value is 960, the third measured value is 1440.
I would like to configure the alarm template if,
- the delta is greater than +600, e.g. the first poll = 480, second poll = 1080, the third poll = 1680, etc.
In this case, the delta is greater than the normal case( delta=+480), then Major Hi alarm will go off.
or
- the delta is smaller than +400, e.g. the first poll = 480, second poll = 880, the third poll = 1280, etc.
In this case, the delta is smaller than the normal case(delta= +480), then Major Low alarm will go off.
I tried configuring alarm template with "Rate" type, but it doesn't work in a way I expect.
You could configure "Rate" type alarms like below, as an option, but not perfect, ...
- Critical Hi = (delta) +600
- Major Hi = (delta) +480
- Warning HI = (delta) +400
It doesn't represent the severity correctly, because delta +480 should be treated as a normal state,
rather than Major alarms.
On the other hand, the Warning low/Major low/Critical low alarm thresholds only works for decreasing analog parameter value,
e.g.
from 50 to 40,
from 40 to 30, etc.
The low alarm thresholds only works when the delta is negative value.
How can I solve this requirement ?
Addition to above, the parameter value will reset to zero at some point when the value reaches to the maximum number of the counter.
In that moment, it resets only because the counter reached to the max value, however, it doesn't necessarily mean that you are in any problematic situation, and operational wise, the parameter status should be treated as in normal.
How can you address those situation with alarm handling ?
Hi,
I believe that in these cases, with wrap-around counters (that reset at some point when they reach their maximum - e.g. nbr of bytes transmitted), the common practice is to convert this in the driver to a metric that indicates the rate of change. And then standard monitoring is applied to the rate metric. Most bitrates are done like that in DataMiner (i.e. the underlying products provide metrics such as 'bytes transmitted' and the driver converts that into a 'TX speed' metric). So in your case the driver would have to be expanded with a new metric called PTP Follow Up Message Rate.