See www.zabbix.com for the official Zabbix site.
One way to meet the challenge of a naming convention for groups
Zabbix does not (yet) support hierarchic groups. Without having a proper naming convention for host and user groups in place things may become complicated at a certain count of groups. Another issue might come up when multiple user groups need different permission on the same host(s). The following naming convention is one example how one could name groups to achieve a better overview and usability.
So, since there is currently no possibility to organize groups in a hierarchy, the idea is about introducing prefixes for easier interpretation and to keep similar combo-box/list entries grouped together. Additionally a separator '::' is used to imitate sub-groups.
Zabbix user groups
|Misc.||->||Miscellaneous||(anything not fitting into one of the other user groups)|
|Org.||->||Organizational purposes||(e.g. Action operation recipients)|
|Role||->||Role||(e.g. Zabbix administators)|
|Svc||->||Service||(e.g. Web Mail)|
|ZBX||->||Zabbix||(group level settings like managing authentication method or frontend access)|
The general pattern for names is: <PREFIX> :: FOO :: BAR :: BAZ
Beside of natural persons there could be generic users as well. For instance to deposit an individual email address per service, application or department. To better differentiate these users for selection from natural ones, they could be written in capital letters. Despite of that these users could get the corresponding prefix and the uncut name as name respectively surname.
|E.g.:||AIXADMIN (Dept.: AIX Administration)|
|MPAY (Svc: Mobile Payment)|
To allow people to choose such an ‘Action operation recipient’ user in an action operation message as receiver, the user and the natural user(s) have to share membership of at least one user group. This could be for instance the respective 'Dept.' user group of a natural user:
|Groups:||Dept. :: OS Platforms :: AIX|
|Org. :: Action operation recipient|
|ZBX :: FRONTEND DISABLED|
The host group prefix follows the same intention of the user group prefix. To save space in combo-boxes a single letter is used to describe the category.
|Prefixes:||D||->||Department||(e.g. if a host does not belong to any service)|
|I||->||Infrastructure||(e.g. Domain name service)|
|S||->||Service||(e.g. Online banking)|
|T||->||Template||(e.g. if templates should be separated from hosts)|
By the way, using the 'T ::' prefix in the visible name of templates can also help a lot to differentiate hosts from templates in combo- or tween-boxes where both may appear.
In addition there may be a suffix too. This can be useful to allow segregation of duty. A service for instance may consist of load balancers, web proxies, application servers and databases. Now when having all the corresponding hosts in one service related host group only, then this would not allow to have different permission per area of responsibility.
- A database administrator wants read-write permission to database hosts and read permission to SAN hosts but is generally not interested in the upper layers.
- An application administrator wants to have read permission to every host related to his or her service and of course read-write permission to hosts of the service itself.
- An administrator of web proxies wants to have read-write permission to web proxy hosts and read permission to load balancer hosts as well as external service checks from the Internet.
|(HSM)||->||Hardware security module|
|(WWW)||->||External checks via Internet|
The '(RO)' resp. '(RW)' suffix can be beneficial in situations where for instance an application administrator wants to have respective permission to the respective OpenVZ Hardware Node of his or her OpenVZ container. Instead of granting him or her access to the host group ‘P :: OpenVZ Hardware Node’, which would permit access to every Hardware Node, one could create a dedicated group like 'D :: Application operators (RO)'. To this group one could then add then the respective Hardware Node hosts and grant read permission to the respective user group – in this case 'Dept. :: Application operators'
The general pattern for names here is: <PREFIX> :: FOO :: BAR :: BAZ (<SUFFIX>)
If a segregation is not necessary (yet), then the suffix may be omitted.
To me the need of such kind of naming convention indicates clearly that there is something to fix. It is unlikely that the permission model changes in mid-term. But I hope we may see hierarchical host groups and maybe also user groups too soon.