See for the official Zabbix site.

Template gallery

Jump to: navigation, search

Feature list

It's gonna be a collection of all kind of stuff which makes it easier to extend the basic setup of zabbix If someone did it once why to redo it? This is a main concern. So first we have to categorize the extras. The need is old, there are similar systems and it should be straight-forward to implement one for zabbix as well.

Data collection

Everything what helps collecting for a monitored host; it could be done by extending the agent's knowledge with a module, adding custom userparameter or by setting up a program which collect and submits with zabbix_sender.

User parameters

  • a standardized distribution format
  • mechanisms to ease packaging to operating system distribution formats (RPM, DEB, ...)
  • dependencies (which software/packages is/are needed on the system)
  • independent parameters, independent config files, but related ones should be grouped (/etc/zabbix/zabbix_agentd.d/userparameter_something.conf)
  • mark the necessary changes in permissions (need a custom sudo entry etc.)


  • a standardized distribution format
  • mechanisms to ease packaging to operating system distribution formats (RPM, DEB, ...)
  • dependencies (which software/packages are needed on the system)
  • build-dependencies (which software/packages is/are needed on the system)


  • a standardized distribution format
  • strong connection with the documentation
  • no upload without doc
what kind of scripts is meant here ? --"" (talk) 10:01, 27 November 2013 (UTC)
this is the "external" scripts which needed for few of the userparameter, for example (apache or postgresql )

Evaluation of Data

Zabbix server core patches

Due to the fact this kind of patches is require recompiling the package and it's need a big and confident knowledge, this is kind of not too likelihood, but if so, then we have to store very detail-full docs for this section, or also on some os we could script it ( in deb there is all the parameter which was used for compile the original package so "easy to recompile after the patch"

i'd say patches should not be mixed in here. user written modules, possible since 2.2, should, though. --"" (talk) 10:00, 27 November 2013 (UTC)
agree, it was just an option, but because it's to complex due to the patches can overlap or conflict, this could be skiped ( but leave it here for future reference )

Data presenting

If we already made the information available, we have to collect it and show it up nicely on the web interface. This is mainly just templates with items, graph and etc, but it could be also different view of an existing data.


  • a description which provides a overview
  • a preview of the template functionality - example generated with a xslt transformation
  • compatibility information

Frontend patches

  • have to have a special attention of the the compatibility
  • standard format, even could be one script for patch5dummys
  • role back option also with script


  • a standardized template for documentations
  • Ranking ( the user could recommend to others to use this one )
  • Easy search ( smart tagging )
  • Standard way to install something downloaded from here
  • Collaboration, bugfixes improvements should be able to added to the existing one, and not new one.

Technical needs

  • This wiki ? ( just to make the decisions )
  • Github as project workflow system
    • version controlling system
    • issue tracking system
    • allows easy collaboration
    • file distribution
  • websearch with database
  • hosting of the files ( just the adopted ones )

Human power needed

  • Maintainer ?? ( big and hard question )
  • In case of custom code, PHP coder?


  • svn vs git:
    • github, because of collaboration and issue tracking :-)
  • self hosted vs 3rd party
    • host repositories at github
    • use platform as an database, do not mirror the items
  • grouping
  • supported languages for scripts ( python, perl, bash, ruby, php ? all?)
  • custom code vs platform
  • backend database
Version control system
SVN ( Git (
halt , Scoopex
Page core
Custom build (PHP) Framwork/Ready App (can't name any, anyone ?)

Database structure

We have to store quite detail full information about the uploaded stuff, so need smart indexing, and a good database design. All short of tags should be added to every uploaded script/template/etc also we should disallow any upload without the minimal tags.

any DBA around ?

Property's of solutions (with options)

  • Monitored Application (any)
  • Collection type (push [active item,zabbix_sender] , pull [userparameter] )
  • Scripting language in use (bash, pyton, perl, etc)
  • Discovery (yes,no)
  • Technology ( module, user parameter, etc)
  • Other aspects what I did not think of yet, but relevant

I think this also should be parallel with the db.


Once we now what we will do than it's gonna be here.