It’s been a while since the first public release of Zabbix – almost 10 years. That’s something worth celebrating, right? There also could be some event where Zabbix users could share their experiences, meet the developers and gain new knowledge about Zabbix. So what’s the plan?
Zabbix manual can be both source of joy and frustration. While some areas are easy enough to find and documented in detail, some are a bit lacking. Improvement has to start somewhere, so here’s an attempt at “rebooting” Zabbix manual.
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.
Zabbix has proven itself successful as an IT monitoring solution when there is a need to oversee the health of hundreds and thousands of servers. However, there is no reason to think that such a powerful system can only do just that – monitor computers. In the first such post today, we will try to uncover the potential of how Zabbix can be used in a multitude of different ways.
![](https://blog.zabbix.com/wp-content/uploads/2010/09/froscon-1.png)
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.
Tap, tap… anybody out there? Zabbix, while being a really great monitoring solution, did not have that many things…