Documentation
Table of Contents
Template styling
1 General
1.1 Avoid extensive template tuning
Try to keep everything default and simple in the template as long as possible. For example, item attributes as update interval, history, trends. Change them only if there is a good reason for this. Don’t waste time deciding whether you should make an update interval 1 minute or 2 minutes, or maybe 2.5 minutes? Use the Pareto principle to get 80% template efficiency with 20% of your time effort. Don’t over-engineer it, unless there is a reason for it.
1.2 Template language
All template descriptions, names, and so on, must be created in the English language first. If you need a template in another language – consider maintaining two copies – English and localized version.
1.3 Everything enabled
All items, triggers, LLD rules, and other configuration entities should be enabled by default to make the template useful out of the box.
1.4 Avoid global macros
If user macros are used, define them in the template itself instead of using global macros - that way users get either the default values or an example of what the macro names are. If global macros are used, they are not exported along with the template.
1.5 Avoid global regexes
Avoid using global regexes in templates if possible, as they are not exported with the template. If global regex is used, document in the README what global regex with what values must be used with the template. (Note that since 4.0 you can use NOT to filter out negative results in LLD filters, see ZBXNEXT-2788)
1.6 Avoid trigger dependencies for triggers from different templates
Avoid trigger dependencies for triggers from different templates. Use global correlation and event tags instead.
1.7 Keep templates modular. Profile templates
Generally, to keep the template reusable and modular, the single template should be capable to monitor a single resource or inseparable set of resources only.
If you need to monitor multiple resources on the host (and you probably do) – consider creating a so-called ‘Profile’ or ‘Meta’ empty template and then link multiple resource templates to it.
| Good | Bad |
|---|---|
| “Apache”, “MySQL”, “PHP”, “Linux” all linked to profile template named “LAMP”. Then, “LAMP” is linked to hosts “lamp1” and “lamp2”. |
“Apache”, “MySQL”, “PHP”, “Linux” all linked directly to hosts “lamp1” and “lamp2” |
It is also a good place to redefine user macros on the profile template level if needed.
2 Files
Share your work as an XML file. The filename should start with the word "template" followed by the category short name and then the exact template name. Use lowercase with spaces replaced by _
| Good | Bad |
|---|---|
| template_app_nginx.xml template_db_mysql_by_odbc.xml |
Template App Nginx.xml Template_DB_MySQL.xml mysql_by_odbc.xml |
Store each template file in its own, separate directory. Create a README.md file or similar in this directory to describe what this template does and how to install it. Place user parameter files or any other files required to run this template into this directory as well.
2.1 Pick a template category
You can create your own template categories. But first, consider using one of the recommended categories:
| Category full name | Category short name | Description | Template name → File name |
|---|---|---|---|
| Modules | Module | For all templates not intended for direct host linkage but often used as a dependency for other templates | Generic SNMPv2 → template_module_generic_snmpv2.xml HOST-RESOURCES-MIB SNMPv2 → template_module_host-resources-mib-snmpv2.xml Interfaces SNMPv2 → template_module_interfaces_snmpv2.xml Interfaces simple SNMPv2 → template_module_interfaces_simple_snmpv2.xml ICMP ping → template_module_icmp_ping.xml |
| Network devices | Net | For all network devices(or software) which main role is networking including switches, routers, wireless, firewalls, etc | Generic device SNMPv2 → template_net_generic_device_snmpv2.xml Juniper SNMPv2 → template_net_juniper_snmpv2.xml Mikrotik SNMPv2 → template_net_mikrotik_snmpv2.xml Dell Force S-Series SNMPv1 → template_net_dell_force_s-series_snmpv1.xml Brocade FC SNMPv1 → template_net_brocade_fc_snmpv1.xml |
| Storage devices | Storage | For FC and other storage devices | IBM Storwize by SNMPv1 → template_storage_ibm_storwize_by _snmpv1.xml EMC VNX → template_storage_emc_vnx.xml |
| Server hardware | Server | For server hardware (iLO, IMM, blades and so on) | IBM IMM2 by SNMPv2 → template_server_ibm_imm2_by_snmpv2.xml IBM IMM2 by IPMI → template_server_ibm_imm2_by_ipmi.xml HP iLO by SNMPv2 → template_server_hp_ilo_by_snmpv2.xml |
| Operating systems | OS | For server operating systems (Windows, Linux, OSX, ESXi by SNMP, Solaris and so on) | Linux → template_os_linux.xml Linux by Zabbix agent active → template_os_linux_by_zabbix_agent_active.xml Linux by SNMPv2 → template_os_linux_by_snmpv2.xml Linux VMware → template_os_linux_vmware.xml ESXi SNMPv2 → template_os_esxi_snmpv2.xml Solaris → template_os_solaris.xml Windows → template_os_windows.xml Windows XP by SNMPv2 → template_os_windows_xp_by_snmpv2.xml |
| Databases | DB | For all SQL, NoSQL and key-value storages | MySQL → template_db_mysql/xml Redis → template_db_redis.xml Oracle by ODBC → template_db_oracle_by_odbc.xml |
| Power | Power | For UPSes and other power category devices | Generic UPS by SNMPv2 → template_power_generic_ups_by_snmpv2.xml APC by SNMPv2 → template_power_apc_by_snmpv2.xml Eaton SNMPv2 → template_power_eaton_snmpv2.xml |
| Telephony | Tel | For hardware and software telephony systems (Asterisk, Panasonic, Avaya, etc) including IP phones | Asterisk by SNMPv3 → template_tel_asterisk_by_snmpv3.xml Avaya → template_tel_avaya.xml |
| Virtualization | VM | For VMs, Hyper-V, VMware, Xen, KVM... | VMWare → template_vm_vmware.xml Hyper-V → template_vm_hyper-v.xml Xen → template_vm_xen.xml |
| Printers | Printer | For printers and MFPs | Printer generic by SNMPv2 → template_printer_generic_by_snmpv2.xml HP LaserJet → template_printer_hp_laserjet.xml |
| Applications | App | For software that doesn't fit in any category above | Generic Java JMX → template_app_generic_java_jmx.xml RabbitMQ → template_app_rabbitmq.xml Apache Tomcat JMX → template_app_apache_tomcat_jmx.xml Apache ActiveMQ → template_app_apache_activemq.xml Docker → template_app_docker Apache2 → template_app_apache2.xml Nginx by HTTP → template_app_nginx_by_http.xml |
| Hardware | HW | For other hardware that doesn't fit in any category above | Netbotz by SNMPv2 → template_hw_netbotz_by_snmpv2.xml Siemens PLC by Modbus → template_hw_siemens_plc_by_modbus Skycontrol by SNMPv2 → template_hw_skycontrol_by_snmpv2.xml Skycontrol SNMPv1 → template_hw_skycontrol_snmpv1.xml Netping → template_hw_netping.xml |
2.2 Readme file structure
It is very important to provide a clear explanation of what your template does, how it can be installed, configured, and tuned. Consider providing such documentation in the README file. Readme file should contain the following sections:
Overview
Describe what this template is about, what versions of a monitored object it was tested on.
Setup
Provide clear step-by-step instructions on how to install the template.
Zabbix configuration
Provide info here on how the template can be tuned using macros and so on.
Template links
List all template links if any.
Discovery rules
List discovery rules with filters applied.
Items collected
List all items being collected.
Triggers
List all triggers.
Feedback
Describe how to provide feedback.
Demo
Optional. Provide some screenshots from the template in action.
Known issues
Describe all known limitations here.
References
Optional. Provide any links to any templates that inspired you to create this one, or reference to the official documentation about the monitored object.