Hi,
We would like to generate port link state alarms for wich the severity depends on an extra parameter that is updated on the fly by an automation script.
The parameter used in the condition has the following values: Mon-Wa, Mon-Mi, Mon-Ma, Mon-C.
In the example we describe here the parameter has the value Mon-C, which should create a critical alarm for a port that has a link status not equal to 'Up'.
Each condition maps on the corresponding severity.
This seems to work fine during several actions (update 'Port Monitored' param via automation/manual, restart element, ...).
Only if we update/apply the alarm template the severity of the alarm falls back to 'Warning' and is set to 'Critical' after a couple of seconds.
The question is how this conditional monitoring should work with multiple lines?
Hi Tom,
Looking at your screenshots, I could see that you are applying the same filter (in this case the wildcard '*') for the column parameter 'Port State' (I can see 4 extra rows created in your alarm template).
We normally created multiple rows in the alarm template to define different filters per instance. For Example, I would like that my Interface 'Gi0' has critical alarm on 'Operational State' if the value is equal to 'Critical', but for other interfaces I would like to set a different severity (e.g. Warning). For this case I would define my alarm template as follows:
Extra rows added in an alarm template are applied by DataMiner from top to bottom. The first filter that matches the index will be used to apply the severity. Since you are using the wildcard '*' for the first row, this means that all the rows on the table will use the first row to set the severity.
Keep in mind that the main purpose of the alarm conditional monitoring in alarm templates is to enable/disable the monitoring (not to update alarm severities). I believe for this case you could use correlation rules. For example, you can create a correlation rule that will update the severity of the alarm depending of the value of the extra parameter:
More information about how to use script conditions can be found in DataMiner Help.
In this example, I created a correlated alarm that will assign a different severity to the alarm that triggered initially the correlation rule (when the value of another column is equal to '60'):
Keep in mind that in this case the correlation rule will be triggered when there is an alarm on the monitored parameter (not when there is an update on the extra parameter). In case you would like to trigger the correlation rule based on the value of the extra parameter, then the alarm filter should be updated to take into account the value of the extra parameter.
Hope it helps.
Hi Tom,
In the condition column you need to specify for which state the line will be disabled.
So in case you select B, from options A, B, C and D that you can set on a row, your condition should be something like below:
row is equal to A
OR row is equal to C
OR row is equal to D
In general you'll have to add every option for which you don't want to have that specific alarm rule enabled.
I believe that we're looking at some unexpected behavior here, but someone can correct me if I'm wrong.
Some context:
Having looked at the setup with Tom, I can confirm that there are two different apparent behaviors for two distinct situations.
You could say that the behavior for the "disable" state of the condition differs between normal operations and after alarm template application.
For normal operation, the "disable" is treated as though the line would not be present in the alarm template in the first place. i.e. DataMiner will iterate from top to bottom, ignoring every line that matches the condition.
In short, a disable here, behaves rather as removal of the line from the alarm template. This is not as we expect, as Miguel's response indicated. We expect that with a single filter, only the top statement would be evaluated. If it's disabled, it's parsed as disabled within the alarm console.
However, after alarm template application, Tom gets a Warning alarm for about 12 seconds, before the alarm severity flips to Critical.
This is a distinctly different behavior. It seems to imply two things:
1. Conditional monitoring didn't trigger, because the top line would not allow a line with "warning" state column to be alarmed
2. The expected behavior does occur here, and the top line is evaluated.
The question here remains then, if the expected behavior is that conditional monitoring should fully eliminate a line from the alarm template (= what is disabled) and thus work with 4 identical indexes and thusly, if the warning state after an alarm template change is a bug?