Just a couple of pictures of what’s happening at the home of Zabbix. Short version – winter is here.
The development of a monitoring solution, now called Zabbix, started way back in 1999. From the functional perspective, Zabbix is much more capable now than it was 11 years ago. However, is it possible that some of this functionality is still backed by code from those ancient times? How did the source code change over the years? In this article, we will take a look at how the software developed over time source code-wise.
Zabbix has built-in web monitoring, which provides scenario support – user workflow emulation on the webpage. There are also some neat predefined graphs on the scenario level. Dedicated Zabbix translator zalex_ua has shared some of these predefined graphs… from scenario with 20 steps.
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?
More than a month ago probably the furthest ever training of Zabbix happened. It was also a very exciting environment where Zabbix was being introduced. Meet Montevideo, Uruguay and Plan Ceibal.
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.
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…
Zabbix 6.4 introduced major improvements to SNMP monitoring, especially when it comes to collecting large numbers of metrics from a single device. This is done by utilizing master-dependent item logic and combining it with low-level discovery and newly introduced preprocessing rules. This blog post will cover the drawbacks of the legacy SNMP monitoring approach, the benefits of the new approach, and the steps required to deploy bulk SNMP metric collection.