Docs/specs/ZBXNEXT-973

Contents 1 Recreate and maintain a new set of templates 1.1 Description 1.1.1 Summary 1.1.2 Specification 1.1.2.1 Naming 1.2 Details 1.2.1 API changes 1.2.2 Database changes

Recreate and maintain a new set of templates

ZBXNEXT-973

Status: Draft

Description

Current templates are buggy, outdated and don't represent Zabbix capabilities well. They should be recreated from the scratch.

Summary

Existing templates have many problems:

• They monitor redundant items (CPU load for 1, 5 and 15 minutes)
• They monitor incorrect items (vmlinuz on BSD, AIX etc)
• They have items monitored at way too small intervals
• They do not use new Zabbix 2.0 functionality (namely, low level discovery)

Specification

• Templates should be modular. Things which are possible to be separated in monitored environments should have separate templates. For example, ICMP ping always belongs in its own template. SSH, Apache and any other service monitoring also happens in separate templates.
• Templates should be as universal as reasonably possible. For example, Apache template should check all popular possible daemon names in items, and verify all of them in the trigger.
• Item polling intervals should be large.
• Low level discovery should be used for all supported objects (network interfaces, mounted filesystems, SNMP trees...).
• As many items as possible should have triggers attached to them.
• Where it might be useful, triggers should have some description as well, explaining some more complicated expression, reason for choosing some threshold, informing the user of possible causes or suggesting possible remedies.
• Trigger expressions should be reasonably flap-resistant - that is, not relying on the last value only but checking last 5 or 10 minutes instead.
• Trigger thresholds should be aimed at a mid-sized environment monitoring.
• Trigger severities should be set to reasonable values.
• Custom graphs should be added as much as reasonable.
• Host screens should be added as much as reasonable.

should item keys be as short as possible or always specify all parameters ? as in net.if.in[eth0] or net.if.in[eth0,bytes] ? the latter would get quite ugly for something like icmppingsec[127.0.0.1,3,100,56,1000,avg] ... --Richlv 14:43, 5 January 2012 (SAST)

I vote for short keys. KISS principle. --Dimir 12:04, 11 January 2012 (SAST)

agreed --Richlv 12:07, 11 January 2012 (SAST)

Naming

• Template names start with "Template_", then comes the template name itself - for example, "Template_Linux" or "Template_AIX".

Shouldn't the naming scheme better be like Template_[Category]_[Object], like "Template_App_SqlServer2003" or "Template_OS_Linux"? Otherwise the list will become rather confusing with many Templates. --Maxhq 01:43, 16 March 2012 (SAST)

could be, but it also makes template names longer. alternatively, we could just make additional host groups like "Application templates" or "Templates: applications" --Richlv 12:46, 16 March 2012 (SAST)

What about TPL_ or Tpl_ instead of Template_ (it's shorter) --Maxhq 01:43, 16 March 2012 (SAST)

it is, but it's mighty cryptic as well :) --Richlv 12:46, 16 March 2012 (SAST)

• All names (group, template, item, trigger, graph, application, screen, discovery) use normal case - for example, "Template_Zabbix_server".

use underscores or spaces ?

• All templates are added in a group called "Templates"

do we need additional groups ? --Richlv 14:49, 5 January 2012 (SAST)

• Where possible, "$1" references must be used in item and trigger names.

Details

The section contains minimum set of templates for inclusion into 2.0:

Platforms:

• AIX
• FreeBSD
• HP-UX
• Linux
• OpenBSD
• OS/X
• Solaris
• Windows

Devices:

• HP LJ Printer series
• HP CLJ Printer series

Network:

• Generic SNMP template

Applications and services:

• DNS
• MySQL (also zabbix_agentd_mysql.conf)
• Tomcat (as JMX example)
• Apache

Agentless:

• FTP
• Ping and pingsec
• SSH
• All other services supported by Zabbix

Zabbix:

• Zabbix self-monitoring

API changes

None

Database changes

None