Isn't that intentional, same as with host group and host level maintenance? Events/problems are generated, but actions can obey the maintenance status.

Could you please be so kind and provide steps to reproduce and expected behavior?

From what I see is that problems are created because they don’t match maintenance criteria tag value 1 because 0 is received.

Expected behavior: all problem in groups host with tag Maintanance=1 will be supressed, all other (without tag and with value=0) not be in maintanance.

Tag in maintanace period = filter of trigers by tag?

Steps to reproduce:

1. Create maintanance period and add to it tag. For example: tag_mute=1
2. Add all hosts in maintanance period
3. Dont add tag_mute for trigers. This tag only in maintanance period
4. In time of maintanance all problems wil be supressed. But they don't have tag_mute

Maybe I don't understand the documentation clearly?

As I see it -

If tags are specified, maintenance for the selected hosts will be limited to the problems with the corresponding tags.

So, if I have specified a tag, no other problems should go into maintenance. So if tag value differs, or, does not exist, the problem should not be in maintenance, correct?

Seems it works as expected.

Documentation:

If tags are specified, maintenance for the selected hosts will be limited to the problems with the corresponding tags.

Problems with other tags will not be suppressed, but hosts in any case will be marked with a special sign .

Suppressed problems are marked by sign.

>but hosts in any case will be marked with a special sign

What for?

in order to show that these hosts are under maintenance.

Maybe the documentation could be adjusted to something like this:

If tags are specified, maintenance for the selected hosts will be enabled, but problem suppression will be limited to the problems with the corresponding tags.

sasha Thanks for your suggestion. The documentation will be updated.

>in order to show that these hosts are under maintenance.

If problem not will be supressed, for what maintenance?

May be it should not enter in maintenance?

 
zux I think this gives more flexibility, you can add a host to maintenance, but only suppress some triggers (if you know what will be done on the host). Others notifications would still be sent, but the maintenance options is visible in the problems, so user can understand faster, that something is done on the host.

Yes, seems to work as expected, now that I know what to expect
After adding the correct tag to the trigger, now the problem is also suppressed:

Thanks for the discussion and suggestions. The documentation has been updated for 4.0, 4.2.

I would like to create a maintenance rule for a group of windows and linux hosts, which I have defined as hostgroup, but by using tags I would like to filter out only hotsts with a specific tag. A tag that is created from a template as a tag of type - host tag.

Hostgroup (required): "Critical_systems"

tags:

• target=windows
• target=linux

Hostgroup:"Critical_systems" + tag:"target=windows"

Zabbix 6.0 LTS

The documentation does not specify what kind of tags (trigger tag or host tag) can be used.
Support for host tag but not implemented. I find it useful.

Zabbix version - 6.0
A maintenance period with a trigger tag is configured. During the maintenance, no action is performed, and no notification is sent to e-mail (as it should be). But after the period expires, provided that the problem persists, the notification is still not sent. Although the documentation says that the escalation pause should go away and the action should be performed.