About a year ago, I was inspired by Raymond Kuiper’s Zen and the Art of Zabbix Template Design, and decided to start applying its practices to my own environment. If you’re not familiar with it, I would strongly recommend looking at the linked page, as well his video presentation on the subject. The idea is to create small “Task” templates for very specialized purposes, and then group those into more generalized “Duty” templates, which are grouped into even more generalized “Role” templates that provide a scope for the function of the generalized server, and that finally nests inside of a “Profile” template which gets applied to the monitored server. The process creates an extremely modular system that is very easy to manage. One of the key concepts is to rely on discovery as much as possible to maintain this modularity.
Among the first places I put this into practice was to monitor Windows services. I had envisioned several task templates for monitoring Windows services – one for DFS (distributed file services), one for SQL services, one for Skype For Business services, etc. The only functional differences between them would be that the filters used in each rule would pick just the services for that particular task.
In practice, just doing this created a problem, because while Zabbix does have a very nice Windows service.discovery item, it can only exist once per server. It was easy to create the Tplt::Task::Win::Services::DFS and Tplt::Task::Win::Services::SQL “Task” templates, however trying to link these into the same parent “Duty” template Tplt::Duty::MSSQLServer gave an error like this:
- Discovery rule "service.discovery" already exists on ...
A relatively common Zabbix feature request is to change the interval of a Zabbix item (how often the item is updated) based on the value of the item. This post will illustrate how to use a trigger to execute a Perl script to meet this goal.
Zabbix::Tiny is a Perl module that I wrote to automate much of the boilerplate that I found myself writing when I wanted to script against the Zabbix API. This article will take a brief look at exactly what advantages are provided by using Zabbix::Tiny. Finally a simple example script is provided, along with a step-by-step explanation of what it does.
Zabbix’s API has the advantage of being both extremely flexible and extremely powerful. Scripts that leverage the API can address many of the perceived ‘short-comings’, or commonly requested features of Zabbix. I wrote the Zabbix::Tiny module as a small interface to the API to abstract some of the boiler plate that I was repeating in each script I was writing without it. Rather than delve directly into the module and it’s uses, I wanted to first cover a few of the dependencies I rely on for (nearly) every script that I write using the Zabbix API. Any articles that I write in the future will consider these points as implied.