Presentation: Managing Zabbix Hosts with Puppet’s Config Management

At the previous Puppet User Group in Belgium I gave a talk about how to manage Zabbix Hosts with Puppet’s Exported Resources. After some tweaking of the presentation to get it OK-ish to be published online, I present you: the slides!

The rational behind the talk

This not about how to set up the Zabbix servers that actually do the monitoring. It’s about how to add data into your Zabbix configuration, adding hosts with their correct IPs and applying the correct monitoring templates to them.

Since Puppet is used as our config management of choice, it would be a perfect fit to have our monitoring be kept up-to-date automatically as soon as changes are made in our Puppet codebase.

The presentation, when given with verbal comments (aka: a talk), runs for about 40-45 minutes.

Managing Zabbix with Puppet

There is no native Puppet type for managing a Zabbix host in Puppet. That means the code to talk to the Zabbix API introduce custom Puppet types and providers to make this work. My version of the zabbixapi Puppet type is available online, but if you’re going to look into this, I would recommend checking out express42/zabbixapi. That codebase was the original basis for my work, but seems to have evolved much further in the meantime and probably contains more features / bugfixes.

Disclaimer: I’ve not yet tried the express42 version.

Lessons learned

While the Puppet type in itself is no magic, and neither is the use of Puppet’s Exported Resources, I did learn a few things while implementing this.

1. PuppetDB, in the early days, was flaky: I had several times where I had to wipe all my data from PuppetDB. This has since greatly improved.
2. Naming the items zabbix_* was a bad idea: Puppet is used to abstract away the configs, naming the types zabbix_* implies I’ll always use Zabbix. It would have been better to name it monitor_* as a type, with Zabbix as one of the possible providers.
3. The code needs optimising: adding ~400 hosts into Zabbix made a little over 60.000 Zabbix API calls. There’s probably a more efficient way for that.
4. This scares the crap out of me: I love automation, but having had a few PuppetDB failures I’m hesitant to base all my monitoring configuration on it (after all: no monitoring = no service guarantees). Perhaps my fear will go away in 2015.

If anyone has any remarks or comments, spots any obvious rookie mistakes or has any other feedback of any kind, please let me know!