One common question we often hear on IRC is: how to make hosts depend on their proxy. The problem being that when a proxy is unable to send data to the server for a long enough time, the nodata() triggers on hosts monitored by the proxy start to fire.
A possible end result is illustrated perfectly by quoting one of the users in #zabbix @ irc.freenode.net
<someuser> lets say one of my large proxies falls behind. I can receive like 2k mails.
Obviously, receiving such a quantity of notifications doesn’t help you correct the issue.
Zabbix supports Linux agent auto-registration and it’s a well documented process in the Zabbix manual. However, it’s not really straightforward to mass provision Zabbix agents on hundreds of servers if you want to have Zabbix agent <-> Zabbix server communication encrypted. At least not without some form of additional scripted step in your installation process. For large deployments I usually use Ansible, although this article just briefly covers that part and I’ll mostly focus on how to make sure your agents get registered for encrypted communication.
We talked about the second most-voted feature request for Zabbix, an ability to create a graph containing an item for all LLD-created entities like network interfaces or filesystems. There was a teaser on using the Zabbix API to implement something like that. Now is the time to check out a simple example that shows such a functionality using a Perl module for the Zabbix API, Zabbix::Tiny.
Don’t despair if you have never used Zabbix::Tiny or even Perl before – everybody starts that way, and questions are always welcome. You might also want to review the posts that introduced Zabbix::Tiny:
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.
In this example, the item will be a net.tcp.service[]item to check a web server for an http response. The goal is to have this service checked every 5 minutes (300 seconds) under normal conditions, but if the response indicates that the service is down, change the interval to 60 seconds, which will allow the trigger to get cleared faster. Additionally, once the service is back up, the interval should return to 5 minutes. Continue reading Using the Zabbix::Tiny to change an item interval based on a trigger.→
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.
Zabbix 3.0 introduced a major new feature – encryption between Zabbix components. If you’d like to add a new host with encryption enabled, you would go to the documentation of the host.create method… and be surprised. It says nothing about the encryption at all. You might continue to the host object page, but that wouldn’t have anything on encryption either.
