Build a scalable and highly available Zabbix monitoring system by scaling it on database level with MySQL InnoDB cluster. It guarantees data consistency and automated conflict resolution, automated failover, and self-healing.
Sometimes it is required to monitor not only a performance of database, but also the data inside it. Zabbix has native functionality to query the database, visualize and process the data.
Watch the video now.
Every monitoring system has to deal with three kinds of performance-related challenges.
Firstly, a good monitoring system must receive, process and record incoming data very quickly. Every microsecond counts here. This may not seem obvious from the start but when your system becomes large enough all the tiny fractions of seconds add up to become seconds if not minutes.
The performance of Zabbix is being constantly improved, and there were significant performance improvements back in 1.8. Then pretty much every Zabbix 1.8 series release added some more benefits, reduced database access and so on. With the 2.0 release there are more performance benefits expected, but there’s so little time to gather some information… luckily, some users do provide us with empirical evidence 🙂
So in part 1 we found out that Zabbix 1.8.1 provided significant performance improvements over 1.6, mostly because of reduced database access. But those who have been following “What’s new” section in Zabbix manual might be aware that both 1.8.2 and 1.8.3 promised even better performance. After 1.8, that sounds quite optimistic, doesn’t it? Let’s try to get some data on that then. To have comparable data we hunted down Zabbix user verwilst again and coerced him to provide some fresh graphs – thanks again.
Zabbix is being constantly improved – functionality, usability and also performance wise. Let’s look at some practical effects on what all these performance improvements have provided in 1.8 series.
As some might recall, Zabbix 1.8 alone was promising a huge performance improvement. Back in February we actually got a confirmation on that, thanks to Zabbix user verwilst. In the first part, let’s rehash what we found out that time regarding upgrade from 1.6 to 1.8.1.
I spent a couple of wonderful days at FrOScon 2010 conference recently. I was mostly interested in NoSQL track due to possible implementation of a high performance storage for Zabbix historical data. However after a few presentations I realized that the topic requires more in-depth research, there are so many NoSQL engines around each with its own functionality and feature set.