The very first alpha versions of long-awaited Zabbix 3.0 were available for testers already some time ago. Now we are getting much closer to the final release of Zabbix 3.0 with the new 3.0 beta available for everyone. Many people would like to give it a try, but sometimes a nice tutorial helps to understand all concepts involved in this process.
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.
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?
“Why on earth was I not notified?!” — ever heard that question from a fellow worker? Setting up notifications can be a challenge — and not only for beginners. Normally, debugging such cases is cumbersome, complex and requires a good understanding of how Zabbix works. Were you ever asked for a list of people who would be notified on some event? It’s hard to tell, until the event actually happens. Or at least it used to:
The Action Simulator tries to relieve you from these problems and make you and your co-workers happy again.
Update: Presenting the Action simulator at the Zabbix Conference 2013
EPEL finally offers Zabbix 2.0 packages. These packages are for you, if you are running RHEL, CentOS, Scientific Linux or any other Red Hat derivative. EPEL aims to provide best quality packages, that follow the same rules and conventions as Red Hat packages and therefore integrate smoothly.
JMX monitoring with Zabbix is easy using Zabbix Java gateway. Let’s say you have a JMX-enabled Java application running on some host. You start the Java gateway, configure Zabbix server to use that, add that host in Zabbix frontend, set up a JMX interface and create a JMX agent item (described here). A JMX item key name is (surprise-surprise!) jmx and it needs 2 parameters that describe a monitored entity:
For quite some time now Zabbix has been offering a virtual appliance for those who would like to try it out or have a simple deployment for a small environment. Among other virtualisation solutions, users also run it on VirtualBox. But, when using NAT in VirtualBox, the host of the virtual machine cannot connect to the appliance directly. Let’s explore how this can be solved.
Often host level maintenance is too much. Picture a machine running multiple services: While one service has a scheduled downtime, others continue their work and you want to be alarmed about them. Zabbix has no maintenance on trigger level at present, but you can work around it quite easily.
Zabbix API starts to play significant role especially when it comes to integration of Zabbix with third-party software like configuration and incident management systems as well as for automation of routine tasks. It is incredibly difficult to manage monitoring of thousands of hosts without some automation in place!
Here at the University of Hawaii at Manoa ITS department, we recently began using Zabbix. Before adopting Zabbix, we monitored our resources with a loosely integrated mix of several software components, including Cacti, MRTG, and uPortal. Having used this old system for quite a while, we have a considerable amount of data which is valuable for trending. So how do we switch to this great Zabbix system but retain all of our trending statistics? The instructions here describe how to convert data from either Cacti or MRTG and import it directly into Zabbix.
