This article provides best practice recommendations from Zenoss Professional Services on how Zenoss customers should manage their zenoss
monitoring template configuration.
If you're reading this article, it's likely you want to change some of the out of the box monitoring templates. If so, before reading further, please make sure you have read all of the following articles:
How To Organize Devices In Zenoss
How Zenoss Chooses Template Bindings
How To Create a Custom Template In Resource Manager
As discussed in these articles, you many have many reasons for wanting to modify or override a Zenoss provided monitoring template, for example to add a graph, change a threshold or to add a new datapoint alias to provide ETL of the datapoint to Zenoss Analytics.
Indeed as the above articles explain, it is is quite easy and practical to do that on a single device by overriding the device level template for that device and making the desired modifications on the overriden template.
However, for modifications to templates at the device class level (ie to affect all devices of that class) or to component level templates (to affect all components of that type on all devices in that device class), the situation is more complicated:
1. Device and component level templates can be reverted or enhanced by a Zenoss software upgrade relevant for that device class, including device classes provided by a Zenpack. This can lead to inadvertent or undesirable changes in your monitoring as a result of such upgrades. Unless you have manualy recorded modifications to baseline templates, and the reason for such change outside of Zenoss, and further, are prepared to manually recheck the integrity of such changes and potentially reapply each one manually again after each software upgrade, there is no guarantee that post upgrade you will not have made undesirable changes to your monitoring settings. Such a "manual check" method is viable for minor, isolated and well
understood and documented changes, but quickly becomes impractial and unmanageable for signficant changes.
2. Component level templates cannot be overridden on a per device basis - they are bound at modeling time based on the component matching the name of a component template existing at (or above) the device class.
As such, regardless of the impetus to make such monitoring templates changes, it is highly recommend that you make device class level changes in a manner that is "upgrade safe", and therefore our recommendation is that you should consider all the base product and Zenpack provided monitoring templates as "read only". In other words, never make any modifications to them directly in the UI.
Rather, to make device or component template changes on a per device class basis, you should:
1. create a sub-device class, named consistently and conventionally for your organization, directly under each device class on which you want to make such changes
2. override the device and/or component level templates you want to modify on that sub-device class
3. make desired modifications to these overrides.
To illustrate this, let's consider the example of making changes to the FileSystem component template for Linux Servers, and the Device level template for Windows servers. Prior to making any template changes, the relevant part of the device hierarchy would look like this:
/Server
/SSH
/Linux
/Windows
/WMI
After creating relevant sub-device classes, the device class hierarchy would look like:
/Server
/SSH
/Linux
/<Customer>
/Windows
/WMI
/<Customer>
where <Customer> is an appropriate term for your organization, e.g. "Acme"
The implications of making your class level template modifications in this manner are:
1. This method is upgrade safe. Monitoring templates copied to the <Customer> device class are guarantee to persist and not to have been modified in any way by any upgrade process.
2. Since you are not using the default templates, even if the default monitoring templates change in an upgrade, your monitoring will not (but see 4 below).
3. It gives you time to review any changes/enhancements to baseline monitoring templates and consider when/if to make those changes to your customized templates post upgrade. Certainly it would be necessary to pull these enhancements/additions into your copies to benefit from all enhanced features provided by the upgrade in the baseline templates.
4. There is a small chance that due to model changes caused by the upgrade, your customized templates may have issues post-upgrade. If so, you will need to prioritizing step 3 above.
Note that it is further recommend that you do NOT create your own top level device classes and recreate/copy baseline class monitoring templates below that. Many zenpacks rely on specifically named device class prefixes for successful operation. In other words, don't create your own hierarchy that looks something like this:
/<Customer>
/Server
/SSH
/Linux
/Windows
/WMI
/vSphere
etc
Happy template customizing!
Comments