Applies To
- All Versions
Summary
Administrators must choose an approach for organizing their devices in Zenoss and remain consistent in implementing that approach as devices are added. Zenoss offers the following device organizers:
- Device classes -
Provided out-of-the-box with Zenoss . Enables administrators to organize devices by device type. Additional classes can be created at any time. For example, Zenoss includes a device class called /Devices/Server/Linux with the intention that administrators will place Linux servers in this class. Administrators may choose to add sub-classes to the /Devices/Server/Linux class. However, placing devices in particular device class has greater implications for Zenoss monitoring than merely grouping them logically. This KB examines these implications in greater detail and makes recommendations about when new classes should and should not be created. - Groups -
Device organizers can be created by administrators as needed. - Systems -
Device organizers can be created by administrators as needed. - Locations -
Device organizers can be created by administrators as needed.
Organizing Devices: A Short Case Study
To fully examine the different approaches administrators can take when organizing devices, consider a fictitious example: Hypothetical Insurance Company. Hypothetical has offices in several cities and began monitoring their devices using Zenoss in Annapolis, Maryland and Washington, DC. The company also has several internal departments, and wants to administer the IT resources of these departments as distinct collections. Their most important departments include Underwriting, Business Development, and Accounting.
Hypothetical Insurance could choose from two broad approaches for organizing these devices:
Method #1 (Recommended):
Organize Devices by Creating Groups, Systems and Locations Organizers
Hypothetical should make use of the “Groups” “Systems” and “Locations” organizers provided specifically for the purpose of logically grouping devices. Hypothetical can create their own organizers as required and specify which devices are associated with each. For example, they can create:
- Washington and Annapolis “Locations” organizers
and
- Underwriting, Business Development, and Accounting “Groups” organizers
They can then “move” systems into these organizers as appropriate. Although it appears that devices have physically moved when they are dragged-and-dropped to these organizers within the user interface, the devices aren't actually moved within the Zenoss database. Rather, the Zenoss software sets "Groups" "Systems" and "Locations" organizers as attributes of devices. As described below, this distinction has important implications for Zenoss' operation "under the hood".
Method #2 (Not Recommended):
Create Device Classes to Organize Devices
Alternatively, Hypothetical could add child classes to each device class to organize their devices. For example, they could create the following child classes of /Devices/Server/Linux/ to organize their Linux servers:
/Devices/Server/Linux/Annapolis /Devices/Server/Linux/Washington
These child organizers could be further expanded to separate systems in different departments:
/Devices/Server/Linux/Annapolis/Underwriting /Devices/Server/Linux/Washington/Business_Development
These steps could be repeated for each device class Hypothetical uses.
Creating device classes to organize devices is not recommended for two primary reasons:
1) Creating devices classes to organize devices can make it very difficult for administrators to find the devices they are looking for. For example, if someone needed to find all of the servers (of any type) in the Underwriting department, he or she would need to hunt through all of the child classes under /Server, identifying and writing down the names of the devices they are looking for. The broader the administrator's query, the more severe this problem becomes.
2) Creating classes to logically group devices unnecessarily increases the complexity of the Zenoss back end database. This increased complexity can contribute to performance degradation. Unlike adding "Groups" or "Systems" organizers - that are attributes defined for devices - a new device class constitutes a new location within the database with its own set of attributes and relationships with other database objects. When practical, it is preferable to avoid the introduction of the increased database complexity associated with the creation of new classes unless it is necessary for custom monitoring of a subset of devices. Because Hypothetical is creating organizers only for the purpose of logically organizing their devices, with no changes in the monitoring or modeling specifics for subsets of devices, they should choose Method #1 above and make use of "Groups," "Systems" and "Locations" organizers.
When Hypothetical Should Create New Device Classes
New device classes should be created when one or more of the following need to be unique for a subset of devices:
- monitoring template bindings
- modeler plugin associations
- configuration properties
Consider a concrete example at Hypothetical Insurance. For a subset of Windows servers, system administrators at Hypothetical have decided to fetch server logs related to print spooler failures so they appear in the Zenoss event console. Their method for doing this is to add an additional data source to the Windows server template, but in order to prevent their event console from being clogged up with entries from servers they are unconcerned with, they only want to apply the modified template to a subset of their Windows servers. This scenario would be a perfect use case for the creation of a new sub class of the /Server/Microsoft/Windows device class. Here are the steps Hypothetical administrators would take to create the new class:
- Create the new Windows sub-class. For example:
/Server/Microsoft/Windows/Print_Logging/ - Create a copy of the standard Windows monitoring template for the new class ("copy/override" the template)
- Add the additional data point to the new template
- Move the target servers into the new class
Note that no changes will be made to the target servers' "Groups," "Systems" or"Locations" organizer settings by moving the target servers to the new sub class. When and if the need to fetch the print spooler events from one or more of the servers ends, they can be moved back to their original device class.
There is a logical fallacy in this document. You state that creating device classes is not recommended, due to complexity. You then say you should only do this store bindings or configurations. However, each company should have their own set of attributes important to them, so would need a new device class (or more) to store these attributes and configurations. Any changes to the top level device classes are subject to overwriting when upgrading the application, so new device classes are a must.