Zabbix virtual appliance has been available for quite a long time now. It includes Zabbix server, agent and frontend, and everything is working out of the box. So far it has always been available in 32bit mode, to make it run on as wide range of platforms as possible.
With the new Zabbix 2.0.8 release, we are moving to 64bit platform. We hope that this won’t make it not working for anybody.
Additionally, this release of the appliance includes an example web monitoring scenario, along with some other minor changes to the default Zabbix configuration. That should make it a bit easier to explore those features – why not take a look at a working example and learn from it?
The appliance is available in 9 different formats, which should be enough for everybody. Head on to the download section and try it out.
Posted in Technical
Creating complex maps is a time-consuming job. Actually, even designing a rather small map of 25 elements can take you an hour. That’s time you rather want to spend on something useful or fun, unless you’ve got a fetish for repetitive work. All we need to automate this task, is a network/graph library like Networkx and the Zabbix API.
Until Zabbix 2.0.7 proxies used a simple algorithm for their configuration synchronization – overwriting the old configuration with a new one. Even unchanged records were updated. It produced a lot of SQL updates even when there were no changes in configuration.
It worked good enough until one user wanted to synchronize a heavy loaded proxy (800 hosts, 120 000 items, 2000 NVPS) configuration every 7 minutes (see the graph).
The synchronization was taking about 2-3 minutes, produced more than 5000 updates per second and caused a heavy impact on performance of other Zabbix processes by blocking the hosts table. During this time poller processes could not update host status data.
In Zabbix 2.0.7 the synchronization aims to generate a minimum number of SQL queries by doing more work in the Zabbix proxy itself. The old configuration is read into memory and compared with the new configuration, record by record. If corresponding records exist in both old and new configurations every field is compared to find out differences. If all fields match, no update is necessary. If a few fields differ an SQL update statement is composed only for those fields.
Tests show that a configuration with 500 hosts and 600 000 items can be synchronized in ~11 seconds if there are few or no changes (not counting ~14 sec for getting 63 MBytes of configuration data from master server). That is 5 times faster than before (depends on the number of items).
After upgrading to Zabbix 2.0.7 the synchronization produces no updates if configuration is not changed as shown in the graph. The main improvement is less blocking of tables and shorter waiting times for other processes.
The Zabbix 2.0 translation team has done a great job, but there’s something else coming closer… no promises, but Zabbix 2.2 will come out one day
With lots of new features and improvements, translatable strings have changed significantly, too. Even for languages that are in great shape in 2.0, things don’t look that great in 2.2 – yet.
Also in Russian: эта статья доступна и на русском языке.
One of the questions for those of us that use Zabbix on a large scale is “Just how much data can Zabbix ingest before it blows up spectacularly?” Some of the work I’ve been doing lately revolves around that question. I have an extremely large environment (around 32000+ devices) that could potentially be monitored entirely by Zabbix in the future. There is a thread in the Zabbix forums where some people have discussed ideas for large environments, but unfortunately, I have not been able to find a thorough list of ways to run large environments. I intend to show how I set up my environment to handle a large influx of data. To give an idea of what I’m talking about, here are some of my current environment stats:
Statistics for a large Zabbix environment
Posted in Technical
Zabbix offers a lot of methods for data gathering, including SNMP. SNMP has been a popular protocol for many years and probably will stay that way – it’s used on routers, switches, UPS devices, storage arrays and lots of other devices. Zabbix 2.2 will improve the existing SNMP support in several ways.
Posted in Technical
Tagged 2.2, snmp
Zabbix trigger expressions provide an incredibly flexible way of defining problem conditions. If you can express your problem using plain English or any other human language, there is a great chance it could be represented using triggers.
I’ve noticed that even experienced Zabbix users are not always aware of the true power of triggers. The article is about defining problems in a smart way so that all alerts generated by Zabbix will be about real issues. No flapping, no false alarms any more. Interested?
Zabbix comes with an impressive list of supported metrics for virtually all platforms. It covers the monitoring of performance and availability of OS including CPU, memory, network, processes, files, kernel parameters and more. Zabbix also performs agent-less checks for well-known services such as FTP, SSH, IMAP, POP3, HTTP, TCP, etc.
Extending Zabbix functionality is a trivial task thanks to user parameters (agent metrics) and external checks (agent-less monitoring). It is just a matter of adding a new line into the configuration file of the agent and you have a dozen of new metrics supported. Depending on security settings you may also use system.run, which does not require any changes on the agent side.
It works very well, but it has one major drawback, namely fork(). Zabbix has to fork a new process every time it handles a user metric, which is obviously not good for performance. It is not a big deal normally, however it could be a serious issue in case of monitoring of embedded systems, a large number of monitored parameters or heavy scripts with complex logic or long startup time.
Zabbix 2.2 comes with support of loadable modules for extending Zabbix agent and server without sacrificing performance.
The Monitoring -> Latest data page in the Zabbix frontend allows to see values for items. Items are grouped by application (if assigned), and they can be expanded and collapsed. Previously, any such operation would result in a full page reload. 2.2 will make this operation happen without a page reload.
Posted in Technical