In these first posts, we are going to analyze some of the interesting new features that the new version of Zabbix offers. We have chosen for this first post, one of the most outstanding, called "
Event tags", or "
event tags".
Zabbix's approach to incident management has so far been very much oriented to specific "hosts", to servers and to services within servers and not globally to "services". This perspective, coming from the original nature of Zabbix configuration (which is still in force) applies very well to the management of networks and servers in a single location, which corresponds to a very common use of the system.
But today, with the increasingly widespread use of containers and especially architectures oriented to
micro-services, another different approach is needed to make Zabbix a suitable tool for both the teams that manage the infrastructure for as those who manage the services (which, increasingly, are the same teams). To do this, Zabbix people have
redesigned the problem screen and added the possibility of, in each "trigger" a specific label is indicated.
These labels or tags are constructed by means of a label name, which can have a value associated with it, allowing us to give these labels an extra level of classification, for example: WebServices, WebServices:Muutech-Login, WebServices:Muutech-Web and others that we can think of once we start working with them as whose responsibility it is, if it affects clients, etc. (Team:Ops, Team:Dev, Customer:External).
Example of use and configuration of triggers
The example of use that we are going to put is in the most evident when we have a
single host whose services affect several of our applications or micro-services. We could, for example, monitor specific data from the databases of each micro-service, the disk consumption of its assigned folders, etc, but in this example, we are going to use that place where many times things from different micro-services or even other systems end up, in a way that is difficult to see:
the LOG. In the example, we are going to use the log of an Apache serving several web micro-services (two in particular that we will call Muutech-Login and Muutech-Web). Although it would be advisable to separate the log of each micro-service in different files, to show all the benefits of these Zabbix features, let's make them write on the general log.
For the example, we will want Zabbix to warn us every time there is a 404 error, for example:
192.168.56.1 - - [29/Jan/2017:20:46:57 +0100] "GET /muutech-login/no-existe HTTP/1.1" 404 221 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36"
We configure the item in a proper way to read from the log the GET requests, as well as the Zabbix agent to support the active mode and, important, to have read rights on the log.
When configuring the trigger, the key to indicate which label to put when this problem is solved is in the section "Tags". It is possible to use the following macros to fill in the tags: {ITEM.VALUE} and {ITEM.LASTVALUE}, as well as user macros. This can be tremendously useful to auto-generate the tags, combining it with the new functions for regsub and iregsub macros. In the Zabbix
manual you have examples of how to configure them. Try it: