Zabbix Code Guidelines


Zabbix naming guidelines

These are Zabbix rules regarding element naming, grammar usage, etc. Primarily for frontend, also documentation.


  • Both software and company are consistently referred to with only the first letter capitalized like this: Zabbix.
  • Random words should never be capitalized in the middle of a sentence or label. "Incorrect characters used for host", "Create host" etc should be used.
    • "Zabbix agent", "Zabbix server", "Zabbix proxy", "Zabbix Java gateway" - note the capitalisation. Also "Zabbix active agent"
    • Exception: Failure Audit, Success Audit - Windows Eventlog levels which are capitalized like that in original
  • Names like "host name", "host group", "proxy name", "node name", "template name", "media type", "super admin" should always be written separately
  • For referencing bytes with a multiplier prefix, KB, MB, etc syntax should be used.
  • For title capitalisation (uppercase/lowercase choices), first and last word should always be capitalised. Other words should be capitalised, except "a", "an", "and", "at", "but", "by", "for", "in", "nor", "of", "on", "or", "out", "so", "the", "to", "up", and "yet" (This rule from Grammar Girl). Such capitalisation should also be followed for value map entries if they are capitalised.
Date and time syntax

This describes date and time syntax, used for the default English locale. Other locales may have their own formats.

  • The time and date order always goes from the least precise to more precise units, for example, 2013-12-13 or 04:43:59
  • Single digit time and date values are always prefixed with a zero, for example, 01:02:03
  • Open questions : use of text representation for months (Jan instead of 01), omitting units ("2014", "2014/May", 15:04)...


  • Entities (hosts, items, item keys...) should be referenced by enclosing them in double quotes, without additional characters - "like this". (Square brackets are already used for item parameters, asterisks are not commonly used and look confusing)
  • Main status messages like "Host added" (displayed on green/red background at the top of the page) should never end with a dot. Detail (expandable) messages should always end with a dot.
  • Detail messages follow the syntax of :<source lang=bash>Action: Object "Object name" on "Host name".</source>
    • Host part is only printed if relevant for the object (for example, it won't be printed for actions and network discovery rules).
    • Example: "Created: Item "Free memory" on "Database server".
  • ISO 8601 should be used for all date and time displaying, except graphs (for now). This was unified in 5430 for Zabbix 2.4. In March 2014, there was a discussion about how the duration is displayed in various locations in the frontend. Current formatting is, for example, 3h 6m. A suggestion was to potentially change it to 03:06:00. This change might have affected duration in trigger/event pages, duration in time period scrollbar, and in graph title (formatting must be the same everywhere). It was decided not to change, as it might be confusing as for what this depicts (duration vs absolute time). An idea that was considered - "(Period length: nnnnn)", but that would increase the length of various titles/labels. Start-end dates and times also would not be that great as it would be harder to figure out what the period is (think 15:00-23:00).


  • All entities (items, triggers, custom graphs, applications etc) are always referenced by host and entity name.
  • In user-visible messages, comments, documentation, etc trigger functions should have an empty set of parentheses added after the function name, for example, last.

Grammar & style

  • "Can't" vs "Cannot" - only the expanded lay") - Action escalations (currently "period", should be "step interval") - Web monitoring (currently "Update interval")
    • Delay should be used for:
      • Slideshows
  • Entity name is always called "Name" (not "Description") - items had "description" up to 2.0
  • external scripts (config file) or external checks (frontend) ?
  • "Network discovery" is always referred to as that (not auto-discovery etc)
  • "Active agent auto-registration" or "Auto-registration"
  • "Low level discovery"
  • remote actions → remote commands
  • system maps → network maps (just maps somehow ? how about consistency ?)
  • frontend scripts ? scripts ? global scripts ?
  • user alias → user name
  • "Metric" should not be used. Either "item" or "value", depending on what it describes
  • "Inventory", not "profile" (as in "Host inventory") 863
  • nodes - master/slave, parent/child ? zabbix uses all versions randomly - nodes have been removed for 2.4, not relevant anymore
  • messages being sent out database has "alerts", frontend mostly uses "actions" (Administration → General → Housekeeper has Do not keep actions older than (in days), Administration → Audit has Actions in the dropdown and page header - and there's also Administration → Notifications... and these also do include remote commands
  • It should always be clarified what type of an entity something is
    • Not just "group", but "user group", "host group" etc, except when the group may be both host and template group
    • "Required field "expression" is missing in icon mapping.", not "Required field "expression" is missing in mapping."
    • Type may be skipped if the message already implies it, for example, "Icon map "%s" cannot have mapping with empty expression."
  • Both item keys and trigger functions have "parameters" (not "arguments")
  • rights or permissions ? permissions seems to be a bit more specific & better
  • Trigger severity (not priority)
  • Maps - "icons" instead of "images" for element icons.
  • users can be 'user', 'admin' and 'superadmin' - currently frontend uses "types" (at least in user properties). possibly "roles", "[access] levels", "classes". in the future might be renamed to "access levels"
  • screen items/elements/widgets ? same for dashboard
  • it is suggested to reference specific entities when possible - currently, copying items and triggers calls them "elements"
External names
  • Instead of just "DB2" use "IBM DB2" because there is also Berkeley DB2 database
  • Objects and returned results have "properties", not "attributes" For example, the "lifetime" property.
  • When referring to properties of an object, passed as an argument to the API, "parameter" should be used instead of "property" or "option". For example, the "selectTriggers" parameter.
Formatting - Parameters

Often the messages use a reference to the parameters. Currently the following standards can be found:

  • Without a standard for highlight a parameter:
VMware cache statistics. Valid modes are: total, free, pfree, used and pused.
  • Using TAG standard to highlight a parameter: "VMware virtual machine processor usage in Hz, <url> - VMware service URL, <uuid> - VMware virtual machine host name"
  • Using TAG standard to highlight a parameter and possible values:

1. Standard one:

VMware cache statistics. <mode> - total, free, pfree, used and pused.

2. Standard two:

Data cache statistics. Cache - one of values (modes: all, float, uint, str, log, text), history (modes: pfree, total, used, free), trend (modes: pfree, total, used, free), text (modes: pfree, total, used, free).

3. Standard three (with more explanation about parameter but without explanation about possible values):

CPU(s) load. Processor load. The cpu and mode are optional. If cpu is missing all is used. If mode is missing avg1 is used. Note that this is not percentage.

I like to start the discussion about what is the best standard.

I think is required maintain 2 standards:

  • Standard to highlight a parameter (without a possible values for params):
<Description Message>, <param 1> - <description of param 1>[, <param N> - <description of param 1>].
  • Standard to highlight a parameter (with a possible values for one or more parameters):
<Description Message>, <param 1> - <description of param 1> (<value1>, <value2>[, <value3>])[, <param N> - <description of param 1>].

The second one can cover all situations - for example

<Description Message>, <param 1> - <description of param 1> [(<value1>, <value2>[, <value3>])][, <param N> - <description of param 1>].