Some questions about this option .
Is this a recommended setting on large settings with large quantity of new alarms ? would that increase Cube performance on such setups?
Is the filtering then done by the DMA and would that reduce the data traffic between DMAs when a DMA is requesting data to other DMAs ?
Can you provide more details about the warning ? "this can lead to incomplete and inconsistent data"
How would that lead to wrong data ?
thanks
Hi abel,
I'll try to give a solid answer on each of your questions:
- The filtering is done on the server instead of in the client.
This should mean that there is more code execution in DMA (SLNet), which could be seen as a performance decrease.
- The filtering is done on the DMA, but that only reflects for external connections (I assume only Cube connections) and not for internal connections (between DMA's).
- “this can lead to incomplete and inconsistent data” means that there is a potential that the data in the alarm console and the data in the surveyor are not aligned. Because of the server filtering of alarms, the consistency in Cube is disrupted.
Example of such use case: an element can have a monitored parameter which was first in state Minor and the then after some time in state Critical. If you configured a filter so that you won't want to see critical alarms, then you will see an alarm console stating that the parameter is in Minor, while you will see Critical on the element on when navigating to that parameter in Data display of that element.
Screenshot of what I'm trying to say:
- The following info is copied from our documentation (Alarm Console settings):
- Filter the alarms before they enter Cube: Select this setting and then select one of the existing alarm filters in the drop-down list in order to apply it as a server-side alarm filter. When you do so, the Active alarms tab of the Alarm Console will only list alarms that match this filter.
NOTE
- When you have modified this setting, you will need to reconnect your DataMiner Cube session in order to apply the change.
- Applying this setting can lead to inconsistencies between the Alarm Console and element alarm states. In other words, alarms could be present in the DMS that cannot be seen in the Alarm Console, because the server side filter overrides any other filter you set in the Alarm Console.
- If this setting is applied, the message Limited Alarm Access is shown at the top of the screen. If you hover the mouse pointer over this text, a list of possible inconsistencies will be shown.
- For more information on alarm filters, see Alarm filters.
Hope this helps you further
Thanks for the detailed answer.
What are the potential benefits of this option in cube then ? when should it be used ?
1 use case I can think of is when you have alarms from specific devices/connectors or from specific Views that are not relevant for a specific user, yet that user does need access to them.
please read ” on large systems”