[ZBX-19101] Trigger remains in 'PROBLEM' while trigger/item is disabled Created: 2021 Mar 08 Updated: 2025 Apr 10 |
|
| Status: | Reopened |
| Project: | ZABBIX BUGS AND ISSUES |
| Component/s: | Server (S) |
| Affects Version/s: | 5.0.9 |
| Fix Version/s: | None |
| Type: | Incident report | Priority: | Trivial |
| Reporter: | Brian van Baekel | Assignee: | Zabbix Support Team |
| Resolution: | Unresolved | Votes: | 7 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Zabbix 5, every version |
||
| Attachments: |
Screenshot 2021-03-08 at 12.18.07.png
problem_disabled.png
problem_enabled.png
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
Create new item, and a trigger on that item. Make sure trigger goes into problem state and navigate to Monitoring -> Problems to confirm. Once confirmed, disable this trigger, navigate back to Monitoring -> Problems and confirm the trigger is not in the problem state(==hidden) anymore on this view
Now, if you navigate to configuration -> hosts -> {host} -> triggers, you will see the trigger is still in the problem state. It is still in the problem state in the DB and api call problem.get will still pick it up.
According to the docs: A trigger may have the following status:
If trigger is disabled (or corresponding item for that matters) we can never determine something happened and the PROBLEM state is misleading.
I think this behaviour should be changed. If host, item or trigger is disabled the state should be reset to normal (or unknown?). |
| Comments |
| Comment by Oleksii Zagorskyi [ 2021 Mar 08 ] |
|
It's kind of arguable what would be more correct. Technically API is not the same as frontend, so it must not imitate some user-friendly logic as frontend does. |
| Comment by Brian van Baekel [ 2021 Mar 08 ] |
|
Hi Oleksii,
Let's expand the scenario a bit here to make sure we both get the behaviour that happens, since it is not only the API that is wrong.
1) Create host, item and trigger 2) make sure trigger goes into problem state as expected:
3) Disable trigger, config cache reload all over the place, and send in a value that should resolve the issue:
Ok, trigger remains in the problem state, which was not expected (yet it is not expected to receive an update either). Now if we don't only look at the frontend, but also execute the problem.get api calls, we simply can confirm in step 2 a new event will be generated, and in step 3 that event is not updated.
In my opinion, that actually is just plain misleading and is a bug on the server side. Zabbix is basically build on the concept "trigger is in ok state and will be evaluated on new metrics/values coming in, so if there is no data, it is ok". Now if we disable the trigger, it is not 'reset' into it's default state (and i can understand that, default state is 'ok' which might be wrong) nor it is set to 'unknown' state, which it should be.
Take in account the ZBX host availability icon. Some versions ago that behaviour was changed as well(is it zabbix 3.0?) so that the icon becomes grey again if the host is disabled, moved from server to proxy, proxy appears offline, before a config cache is reloaded etc etc. I think triggers should follow the same behaviour. |
| Comment by Shane Arnold [ 2021 Mar 26 ] |
|
Agree with the above. Problem state should be unknown (not just last state) when trigger is disabled. Because incoming items won't be evaluated against a disabled trigger, it's impossible to say what the state truly is. |
| Comment by Arne Strauß [ 2024 Jul 17 ] |
|
This Issue remains still in Zabbix 7.0 I would love to have this fixed |
| Comment by Stefan Prokop [ 2025 Apr 09 ] |
|
Same applies to services if an underlying trigger is disabled in problem state. Only workaround is to enable the trigger again, close the problem manualy and disable it again. We are on version 7.0 LTS. |
