Tags in Zabbix 6.0 LTS – Usage, subfilters and guidelines

Post Syndicated from Andrey Biba original https://blog.zabbix.com/tags-in-zabbix-6-0-lts-usage-subfilters-and-guidelines/19565/

Starting from Zabbix 5.4, item tags have completely replaced applications. This design decision has allowed us to implement many new usability improvements – from providing additional information and classification to the tagged entities, to defining action conditions and security permissions by referencing specific tags and their values. Let’s take a look at how tags are defined in the official Zabbix templates and some of the potential tag use cases when configuring actions and access permissions.

Tag usage in Zabbix 6.0

The outdated “applications” have been replaced by tags, which I wanted to talk about in more detail today.

The main difference between tags and applications is that tags are defined using a name and a value, which greatly expands their scope of usage. Now tags are used in items, triggers, hosts, services, user groups for permission configuration, actions, and more. I am sure that their scope will expand with each new release. 

Trending
Stable kernel updates

Due to the structural difference between “applications” and tags, filtering tools had to be adapted. For example, in the “Latest data” section in Zabbix 6.0, sub-filters have been redesigned to support tags and provide granular filtering options. Grouping tags by name allowed to save space and made using sub-filters more intuitive.

To optimize the work with tags, we have developed several standards for different template elements. 

Template

Now each template contains the mandatory class and target tags. Using these tags will allow distribution templates by class, such as application, database, network, etc., and by the target.

Items

Mandatory component tag that describes whether the data element belongs to a particular system or type. If a metric belongs to several types at once, it is necessary to use several component tags to describe the relevant component assignment as best as possible. 

Custom tags are also allowed for low-level discovery data elements using LLD macros. 

Triggers

The scope tag is assigned to the trigger based on the issue type. The general idea is to organize triggers into 5 groups: availability, performance, notification, security and capacity. 

Hosts

For a host, the service tag is used, which defines a single service or multiple services running on this host. 

Example of tagging on a ClickHouse by HTTP template 

Let’s start with the tags of the template itself. It has class: database and target: clickhouse tags assigned to it. You shouldn’t assign too many tags on the template level, because each of these tags will be inherited by template elements, which can create unnecessary redundancy, and as a result, a “mess” of tags. 

Let’s take a look at a few metrics and triggers from this template.

The “ClickHouse: Check port availability” metric is assigned the component: health and component: network tags, as it contains information about the health of the service and the checks are performed over the network. Problems on this metric can be displayed to the group responsible for the network 

The “ClickHouse: Get information about dictionaries” metric has a tag component: dictionaries because it explicitly refers to dictionaries, and a tag component: raw, because it is a master metric, and dependent metrics get data from it.

The metrics from the low-level discovery “Replicas” rule contain the component: replication, database: {#DB}, and table: {#TABLE} tags. LLD metrics allow custom tags as they allow the use of low-level discovery macros for grouping flexibility. 

 

Trigger “ClickHouse: Version has changed (new version: {ITEM.VALUE}” with scope: notice tag implies a simple notification that does not contain critical information related to system unavailability and performance. At the same time, trigger “ClickHouse: Port {$CLICKHOUSE. PORT} is unavailable” means the system is unavailable and has the tag scope: availability. 

 

How to use tags?

As I wrote earlier, right now we are using tags for the majority of Zabbix components, so they become a functional and flexible tool for managing monitoring. One of the latest such implementations is Services – now they can also have tags assigned to them. 

Of course, one of the most obvious use cases is the logical grouping of some elements. This allows filtering triggers and metrics by given parameters.

The next use case is also of significant importance – it’s the extension of the rights management functionality. With the help of tags, it is possible to add a layer of granularity so a Zabbix user can view problems for a particular service. For example, we need to provide access to Nginx servers that are in the Webservers group. To do this, just add the read permissions for the Webservers group in the Permissions section of a User group and select the Webservers group in the Tag Filter section and add the service: nginx tag. You can find more information about user groups on our official Zabbix documentation page.

Using tags in permissions

Let’s look at the use of rights with a practical example. Suppose there are 3 user groups: 

  • Hardware team – a team of administrators that is responsible for hardware 
  • Network team – a team of administrators that is responsible for the network and network hardware
  • Software team – a team of administrators that is responsible for software 

For each group assign the following permissions: 

  • for the Hardware team, set the read permissions for the Hardware group
    • In the tag filters, set the tag and tag value to scope: availability in the tag filter because we want the team to see only availability problems.
  • for the Network team, set the read permissions for the Database, Hardware, Linux servers, Network groups
    • In the tag filters for the Database, Hardware and Linux servers set the tag and tag value to component: network in the tag filter, because for these groups it is necessary to see only problems related to the network.
    • in the tag filters for the Network host group, we have to set “All tags” since we’re interested in seeing all of the problems related to hosts in this host group.
  • for the Software team, set the read permissions for the Databases and Linux servers groups
    • In the tag filters set, the tag and tag value to class: software for each group to see events exclusively related to software. 

With this configuration, each user group will see only those problems that fall under the respective permissions and tag filters. 

Remember, that  a Super admin user will see all of the problems created in Zabbix

While users belonging to User roles of type Administrator or User will see a restricted set of problems based on their permissions:

  • Users from the Hardware team group will only see problems for hosts from the Hardware group and triggers with the tag scope: availability.

  • A user who is in the Network team will see all problems with the component: network tag and all triggers for the Network host group.

  • And users of the Software team only have access to problems with the class: software tag.

Using tags in actions

And of course the use of tags in actions. Pretty often required to set up quite complex conditions which may become confusing and hard to maintain. Tags, as a universal tool, add another entity that you can use when creating actions.

For example, if we want to send notifications about network availability problems with a severity greater than Warning to network administrators, we can specify the following conditions for our action:

  • value of tag class equals network
  • value of tag scope equals availability
  • Trigger severity is greater than or equal to Warning

Questions

Q: Are tags a full-featured replacement for “applications” or are there any downsides? 

A: Of course, they not only replace the functional “applications” but also extend the functionality of using tags in various aspects of Zabbix. 

 

Q: Is the current implementation of tags finalized or is there more to come?

A: No, we are working every day to improve the experience gained from using Zabbix, and tags in particular, so we are listening to the opinion of the community and adapting the functionality for the best result. If you have any ideas or comments, please use the official Zabbix forum and the Zabbix support portal to share them with us!

 

Q: Is there a document describing the best practice approach of using tags?

A: Yes, there is a guideline section on the documentation site that contains recommendations for best tags usage in Zabbix.

The post Tags in Zabbix 6.0 LTS – Usage, subfilters and guidelines appeared first on Zabbix Blog.