Normally, Alexei is the one that directs Zabbix development: which bugs are meant to be fixed and which features are meant to be implemented. However, sometimes Alexei is too busy to pay enough attention to what developers are doing, and that is a chance to do some hacking. Here is one of them.
Zabbix is used to monitor many of the world’s biggest environments. But it also monitors its own (albeit small) environment. And this environment recently saw a shark attack.
Zabbix daemons use various approaches to improve performance. One such measure, introduced in Zabbix 1.8, is configuration cache. It resulted in massive performance improvements (up to 10 times), mostly because of a significantly reduced database access (that we looked at in previous blog posts). This cache slightly changes how Zabbix operates, though, and can introduce some delays in configuration information processing. Zabbix 1.8.6 provides a new feature to help with configuration cache management.
…in the configuration files, that is. For a long time, if you made a mistake in a configuration parameter’s name, Zabbix processes would not really tell you about that. This is finally changing with Zabbix 1.8.6.
One of the promises of Zabbix is an ability to monitor pretty much anything. That is possible using various extending capabilities on the Zabbix server, binary agent and elsewhere. Maybe we can monitor some aspects of Zabbix community using Zabbix itself?
The opensource conference T-DOSE in Eindhoven, Netherlands took place a bit more than a week ago. It provided good coverage of different subjects, including KVM, Devops, Open GIS, puppet and lots more. And, of course, Zabbix.
For a long time Zabbix has gone largely unnoticed in the world of monitoring systems. Despite being around for almost 10 years and having several unique features for the time (and still today) like Zabbix proxy, it was not something one would expect to see in user surveys. Times, they seem to be a-changin’.