I have several new NetApp's that are being setup and configured. I'd like to add them to Operations Manager (DFM) right away however these NetApp's will be tested thoroughly which includes reboots, cf takeovers/givebacks, LUN's going off line and other operations I would typically like to be alerted for with the exception of filers that are being setup and configured.
Is there any way to add a filer to operations manager but flag the filer as being in "maintenance mode" within Operations Manager? The goal is to have operations manager track this filer and gather data but also to tell operations manager not to alert us on significant events.
Wish i had seen the dfm host delete section, it appears that moving into new group and setting critical alarm for that group to ignore does not work since there is a top-level global 'All -Critical or Worse alarm that catches it from Global. Would have had to create new Critical_per_Subgroup_Alarm (i.e. CRITICAL_SUB1, CRITICAL_SUB2, etc) and move hosts into sub group, and enable Critical alarm for each SUB group and then be able to disable the top-level All-Critical, as those would be caught by the sub group critical alarms set. More work that way. Or in addition could add Maintenance_SUB and move filer into there, but would still need to create other SUB groups for other criticals so they are caught, and disable top. Unless theres another way. But the dfm host delete may be the better solution, given the hierarchy for the alarms .
I'd suggest creating 2 top-level groups - Production and Maintenance. Then you can assign alerts to the Production group only and move systems over to the Maintenance group to avoid alerts while still capturing data. Using alerts from the root is a bad idea in general.
If you base your alerts on the Global "root" level, you can't stop alerts like you were asking about. Also, as you grow you can use nested groups to control who gets what level of alerts based on site, application or other groups - while maintaining higher-level alerts and allowing for maintenance/lab groups for no alerting. Remember that you can create groups of Volumes, LUNs, Resource Pools, Aggregates, Qtrees, etc. to help narrow the focus (i.e. send alerts on Exchange resources to your Exchange admins). DFM is VERY noisey so the more yoiu can intelligently group your resources the better you can isolate alerts to what is needed so they are actionable and not just another email that gets filed (or deleted) and overlooked.
Unfortunately OnCommand Unified Manager for Clustered Data ONTAP (DFM 6) doesn;t work the same way, the alert settings have resources individually rather than using groups so they cannot be easily moved into maintenance like this. You're forced to setup your alerting very granular so you can disable an individual alert that contains the resources going under maintenance.
We're looking to move alerrting to SolarWinds SRM now to have better control of this and of the content of the alert messages. It will still use OC Core/OCUM for the data source, but we can "unmanage" a system during maintenance (and even schedule it in advance!) Plus the added advantage of using the AppStack to see upstream systems (VMware, UCS, Switches, Routers, Applications, etc.) could give us a true single pane of glass for the environment in general.