- Zenoss 4.x
- Zenoss 3.1.x
- Zenoss 3.0.x
- Zenoss 2.5.x
- Zenoss 2.4.x
Zenoss applies templates (Device and Component) in a few different ways and the following is an explanation of the binding rules. It is important to remember that the name of each template must match exactly, and that the matching is case-sensitive.
- applied to devices
- only once per device
- bound according to what the zDeviceTemplates property contains
For most device classes within the system this is set to "Device". For a hypothetical /Server/Linux/MySQL device class the zDeviceTemplates property would likely contain Device and MySQL so that normal CPU and Memory information would be collected using the Device template and MySQL specific metrics using the MySQL template.
A device template is bound manually - see the administration guide for your version of Zenoss for how to bind device templates.
Example device templates
- MySQL, Apache
- Active Directory, MSExchangeIS, MSSQLServer, IIS
A Device (ie a server) has many components, such as network cards, slots, disk drives and non-physical items like processes. Think of these as sub-components of the main device. Component templates, therefore, can be thought of as templates for these special sub-components.
Component templates are a bit more mysterious than device templates. The biggest difference in how they're applied is that a component template can be applied many times per device depending on how many components the device contains that match the template.
Another big difference is that there are no zProperties or other settings that control which component template is applied. Component templates follow more rigid rules than Device templates and they are applied without user interaction, usually after modelling has found the devices components.
Example component templates
- FileSystem, HardDisk, IpService, OSProcess, WinService
- Fan, PowerSupply, TemperatureSensor
- LTMVirtualServer, VPNTunnel
These component templates are named EXACTLY according to the name of the underlying class that represents the component. This is the case for all component templates except for the IpInterface component. As you might have already noticed, there is no template called IpInterface (see the next section).
Templates get applied to network interfaces using a special kind of binding. Instead of using the name of the underlying class, Zenoss will look for a template that has the same name as the "type" of the interface. You can find this type by clicking into the details for any network interface from the OS tab of its containing device. This information was populated from the device via snmp or ssh during the modeling of the device. Therefore, we set Interface templates directly according to what the device gives us as its 'Type'.
If a template matching the name of the interface's type can't be found, the "ethernetCsmacd" template will be used as the fallback. Most interfaces you'll find are this type.