[ZBX-4011] IT Services when not linked to trigger sametime hold problem status without any REASON (Child changed to OK) Created: 2011 Aug 03  Updated: 2017 Oct 24  Resolved: 2017 Oct 24

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Frontend (F)
Affects Version/s: 1.8.5
Fix Version/s: None

Type: Incident report Priority: Critical
Reporter: Marzena Piko Assignee: Unassigned
Resolution: Unsupported version Votes: 1
Labels: itservices
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL 5, Zabbix 1.8.5
IBM eServer x3500

Attachments: PNG File bug1-noreason-support.png     PNG File bug2-noreason-support.png     PNG File bug3-noreason-support.png    

 Description   

Ones for a time (not every time)
After problem occurs, IT Services view does not reset alert in elements, that not linked to the Trigger. (I mean not always reset alarm, usually it works fine, but for some reason not always).
In that case, there is alarm but there is no Reason explained, and when you check -all monitored parameters are OK. (check screens)
We already delete all IT services and create all of them again, it didn't work, we check logs in debug mode -> no errors
We use 1.8.5 performance items so we know, that we don;t have any problem with performance of any processes.

At this point we are going to create a trigger like ping 127.0.0.1, that will be always true to link with groups that does just grouping other groups or triggers, hope that will help, but if there is possibility to create empty IT services that only groups other "leafs", it should always work. And it isn't.
IT will be hard to recreate, sometime, problem with no reason clear itself, but usualy we need to change something to force Zabbix to generate true alarm (like change IP to not existing), Zabbix will discover problem, generate alarm, then we restore IPO to real one, Zabbix clear itself from down to up -this is manual force Zabbix to check again, often without manual "push" it clear itself alter few hours, but we use SLA, and we have people that really use IT Services view, and the few time that this problem kick in, is really troubling.

 Comments   
Comment by Marzena Piko [ 2011 Aug 03 ]

OK, there is no way to link to a trigger a Service that is gruop (parent).
If I try link to trigger an item (service), that have several "Depends on" and clik save: It looks OK, but no trigger is added.
I will try use soft links (another bug I think: You can't use soft link on existing items in "depends on"; you may use check box only when creating new service.
Even if this will work, it is only workaround, problem still exists. If someone really want use IT Services and SLA, there is problem..

Comment by Marzena Piko [ 2011 Oct 25 ]

Quicker way to force zabbix to check itself when problem occurs:
Edit services that shows problem without reason, change "Status calculation algorithm" to "Do not calculate." -> Save
Edit Service again and restrore previous "Status calculation algorithm".
still you have to set one-time-downtime to elimate false problem in SLA calculation.. ;/ but at least its quicker way then triggering a real problem.

Comment by Alexei Vladishev [ 2012 Jul 28 ]

I believe it was resolved in one of the latest 1.8.x.

Comment by Rein Remmel [ 2013 Feb 27 ]

It looks like we are experiencing the same problem. We have a IT service that depends on JMX trigger "{HOST.NAME} is not reachable". Although the trigger status is OK, IT service keeps adding downtime. At the same time IT Service status column is OK.
We have upgraded our installation from 1.8 to 2.0.4 and then 2.0.5. We are using MySQL as and Centos 6.
Since we just started using SLA monitoring I can't tell whether the problem was present in 1.8.x or appeared in 2.0.4.
What I can confirm is that flushing service_alarms table will stop downtime counting.

Comment by Aleksandrs Saveljevs [ 2016 Jan 28 ]

Is the problem still relevant with the latest versions of Zabbix?

Comment by Rostislav Palivoda [ 2017 Oct 24 ]

Please reopen if required.

Generated at Sun Apr 06 05:11:51 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.