One of the highlights of any Zabbix Summit is the diverse set of fascinating speakers who show up each year. With that in mind, we’re continuing our series of interviews with Summit 2023 speakers by sitting down with 7 to 7 CEO Sven Putteneers, who has been gracious enough to fill us in on his work, his Zabbix experience, and the details of integrating Zabbix with the popular messaging app Telegram.
Please tell us a bit about yourself and your work.
I’m a 43-year-old computer geek with a strong interest in Open Source software and programming. I work for a big telco, where I help to build and maintain a cloud telephony platform. Apart from that, I administer our Zabbix installation, which we have set up as a multi-tenant platform and which we use to provide a “monitoring as a service” offering to our customers. Aside from my day job, I founded a company (7 to 7), where Zabbix consultancy is part of the services I offer.
How long have you been using Zabbix? What kind of daily Zabbix tasks are you involved in at your company?
I have been using Zabbix daily for the last 7+ years. My daily tasks are configuring new customers and hosts, maintaining our Zabbix deployment, programming integrations with external systems, and thinking about how we can improve our Zabbix installation in any way.
For my side job, I give Zabbix-related advice, help customers solve tough Zabbix problems (e.g. “how to monitor this exotic device”) and roll out Zabbix installations from scratch to a fully functional monitoring platform. I also offer monitoring in an MSP-like fashion for customers who want their infrastructure monitored but don’t want to deploy their own Zabbix.
Can you give us a sneak peek at what we can expect to hear during your Zabbix Summit speech?
I’ll describe how a Telegram bot that is connected to your Zabbix deployment can turn your Telegram app into a small but powerful user interface for your Zabbix. This means not just using Telegram as a one-directional notification mechanism (like email), but allowing you to query your Zabbix, perform actions (like acknowledging alarms), fetch graphs, etc.
Why did you decide to write a bot for Telegram as opposed to other popular messaging systems? Was it simply a matter of preference or were technical considerations taken into account?
Preference was only a factor after we made a first selection based purely on technical criteria. Some of the criteria we had were that it had to be multi-platform (our Zabbix users are on Android as well as on iOS and use Mac, Windows, and Linux on their computers), it preferably had built-in platform support for bots, and the option of sending more than just plain text.
Telegram ticked all the boxes and has some nice extra features that were not hard requirements (like in-place updating of already sent messages instead of just being able to send new messages), so we decided to go with that.
Have you written any other custom integrations for Zabbix?
Yes, but most of these are for internal systems (like our in-house CRM) and are not really interesting outside the company.
I have written some integrations for monitoring (i.e. UserParameter scripts and external scripts -scripts + the accompanying templates) to monitor systems that have an API that is difficult to query with vanilla Zabbix. An example would be TLS certificate monitoring that is a bit more in-depth than what Agent2 currently offers.
I have also fixed some bugs in a script called mib2zabbix, which as the name suggests takes an MIB file as input and outputs a template file that can be imported in Zabbix.
There are a few features I still want to add to the script (like generating the new walk items for efficient SNMP value gathering), but the script as it is has saved us a tremendous amount of time already.
One fun (and useful!) thing I wrote is a script that uses zabbix_sender to feed data to a “fake host” representing all the things we monitor (think of it as an item per monitored host). Because our Zabbix is multi-tenant, we have some naming conventions and rules around mandatory hostgroup membership to control where alarms for a specific host (or trigger) get sent and when.
I did a talk about how we use hostgroups to control action logic at the Zabbix Benelux Conference 2020 (and the same talk again at the Online Meetup in September 2020. The “fake host” alerts us when a host doesn’t conform to our conventions or is misconfigured, so alarm notifications would be prevented from being sent, for example.
The cool thing is that since this is all based on discovery rules and a script that pulls everything from Zabbix through the API and then feeds data about potential problems back through zabbix_sender, new hosts are picked up automatically and are checked for compliance with our conventions within minutes after they’ve been added.