[ZBXNEXT-104] switch trigger to OK based on acknowledgement by user Created: 2009 Oct 23 Updated: 2020 Dec 23 Resolved: 2017 Feb 17 |
|
Status: | Closed |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Frontend (F), Server (S) |
Affects Version/s: | None |
Fix Version/s: | 3.2.0alpha2 |
Type: | New Feature Request | Priority: | Minor |
Reporter: | David M. Zendzian | Assignee: | Unassigned |
Resolution: | Fixed | Votes: | 139 |
Labels: | acknowledges, logmonitoring | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified | ||
Environment: |
No specific environments |
Issue Links: |
|
||||||||||||||||||||||||
Team: | Team C | ||||||||||||||||||||||||
Sprint: | Sprint 1 |
Description |
If there was an item or trigger tied to the ACKs on a trigger, then the trigger expression could be written so that when it becomes active it can stay that way until there is an ACK and someone has at least looked at it. Maybe have the ability to use values in the ack msg to determine if it is just examined, OK cleared, etc |
Comments |
Comment by Raymond Kuiper [ 2011 Mar 16 ] | ||||||||||||
This would be very handy for triggers that are triggered by logfiles etc. I would like the option that a certain trigger (configurable per trigger) can only be cleared from the webgui, preferably via a tick box in the acknowledge screen. | ||||||||||||
Comment by Paul Seymour [ 2011 Apr 26 ] | ||||||||||||
Ability to clear via API would be good as well. | ||||||||||||
Comment by Raymond Kuiper [ 2011 May 04 ] | ||||||||||||
A {TRIGGER.ACK} macro (a bit like the {TRIGGER.VALUE} macro) that could be used in the trigger expression could solve this for us. It would need the trigger to be ACK before it can go to the OK state. <normal trigger expression> | ({TRIGGER.VALUE}=1 & {TRIGGER.ACK}#1 ) Also see https://support.zabbix.com/browse/ZBXNEXT-645 and http://www.zabbix.com/forum/showthread.php?t=13088 | ||||||||||||
Comment by Niumar Andre Klein [ 2011 May 04 ] | ||||||||||||
Very usefull for me too. | ||||||||||||
Comment by Nico Zanferrari [ 2011 Sep 26 ] | ||||||||||||
I think this is a must-have missing feature, expecially for newcomers like me. Now, the simpler GUI way I've found to reset a log trigger is to disable and re-enable it.... I think it should not be too difficult to implement an optional tick box or a radio button in the acknowledge screen in order to reset a log (or eventlog) trigger. | ||||||||||||
Comment by travis mathis [ 2011 Dec 19 ] | ||||||||||||
2011 and still waiting | ||||||||||||
Comment by Eric Rosevear [ 2012 Mar 19 ] | ||||||||||||
I agree with the must have comment above. BTW if you google the text in this request it has been floating around for the last 3+ years | ||||||||||||
Comment by Raymond Kuiper [ 2012 Aug 30 ] | ||||||||||||
Open since October 2009...Can we get a status update on this one? | ||||||||||||
Comment by lioncub [ 2012 Nov 22 ] | ||||||||||||
Очень ждем этого функционала!!! | ||||||||||||
Comment by Andres Toomsalu [ 2013 Apr 01 ] | ||||||||||||
2013 and still missing this very helpful feature... | ||||||||||||
Comment by quentel [ 2013 Jul 08 ] | ||||||||||||
The only work around I found so far is to run periodically (every 2 min) a script that update the "value field" of triggers table in zabbix database. For mysql you can do it with the following query: update triggers set value=0,error='' | ||||||||||||
Comment by Joshua Cagle [ 2013 Sep 12 ] | ||||||||||||
So are we going to solve this anytime soon? I may have to do it myself. | ||||||||||||
Comment by Leandro Lana [ 2013 Oct 30 ] | ||||||||||||
Any solution? | ||||||||||||
Comment by Leandro Lana [ 2013 Nov 06 ] | ||||||||||||
affff feature request in 2011 Jul 13 15:50, and anybody resolve? Bad suport! :s | ||||||||||||
Comment by Dyego Bezerra [ 2013 Nov 27 ] | ||||||||||||
Please, more priority to this one | ||||||||||||
Comment by Leandro Lana [ 2014 Jan 14 ] | ||||||||||||
Priority: Minor Minor Crazy? resolve this problem sun! | ||||||||||||
Comment by richlv [ 2014 Jan 14 ] | ||||||||||||
please stop adding spammy comments. we will have to remove them. | ||||||||||||
Comment by Leandro Lana [ 2014 Jan 15 ] | ||||||||||||
solve it then! Five years to be resolved! | ||||||||||||
Comment by richlv [ 2014 Jan 15 ] | ||||||||||||
i'm not fully sure i have an obligation towards you. if it is so, could you please provide more information on it ? i'd like to know. | ||||||||||||
Comment by Cristian [ 2014 Jan 15 ] | ||||||||||||
richlv, I dont think is a solution to be sarcastic. As well, I dont think you have any obligation to anyone. My personal feeling (I use Zabbix for about 1 year only) is there are lot of small issues which could be easily fixed but are not for a long time, which could be quite annoying and users are dissapointed waiting years for a fix... Of course, there is the voting for proposals as well... | ||||||||||||
Comment by richlv [ 2014 Jan 15 ] | ||||||||||||
1) i do believe that rudeness level in certain comments (3 of them) was too high; | ||||||||||||
Comment by Leandro Lana [ 2014 Jan 15 ] | ||||||||||||
while discussing about solving or not solving, this little solution could be resolved. Paleativas are passed resolutions that simply do not solve all cases (.nodata). Cya (sorry bad inglês) | ||||||||||||
Comment by Andres Toomsalu [ 2014 Jan 15 ] | ||||||||||||
Hi Richards, I really dont want to spam this issue (feel free to delete this comment afterwords) - and being an open-source project owner myself I really understand how everybody can pressure the feature request yet not everybody wants to give a helping hand or cash I understand why this issue is low prio - as it does not block Zabbix usage and not many people report back then - yet I must say it is very annoying missing feature - which might/or might not be easy to implement (dont know in such details). It would actually improve the user experience a lot - and it feels kind of not so huge change implementation wise - so I hope you will give it another round of evaluation and consideration - if to raise the priority on this issue or not. I must say I have hoped for this feature for years now - yet it is also true that I have not made the patch or ordered the custom development - but still missing this simple feature a lot - and I really think it affects Zabbix user experience in a good way Kind regards, | ||||||||||||
Comment by Marc [ 2014 Jan 15 ] | ||||||||||||
The willingness of people to pay money for a feature is the strongest indicator, that this feature is really needed. | ||||||||||||
Comment by richlv [ 2014 Jan 15 ] | ||||||||||||
i guess i have to give up and we can use this issue for discussions andres, i have a list of issues that annoy me heavily when using zabbix. HEAVILY. this one is not on that list, yet... so priorities for different users differ a lot a) changing default history period from 90 to 7 days. sounds extremely simple, right ? just change one number... well, first it would require major release, because it is also in the database schema. second, that value also affects for how long web scenarios keep historical data, and it can not be configured by user. so we would have to implement that functionality. see how one number change drags in extra feature ? as for this specific one, see the link marc posted - this specific feature is now at the top of the list (thanks, sergey) | ||||||||||||
Comment by Alexei Vladishev [ 2014 Jan 23 ] | ||||||||||||
It is not a simple feature by any means. With all due respect, most of us do not understand all implications of this functionality since it affects core parts of Zabbix: triggers, events, actions, notifications; both server and front-end. That's why it is 4 years old and still not implemented. We need a good solution, which fits well into existing design, scalable and covers most of real-life use cases. I think we are talking about two feature requests here: 1. Ability to switch a trigger to OK state manually by ACK 2. Ability to have triggers that (all individual problem events) can be switched to OK state only by ACK. Automatic OK events are prohibited. I guess we have some good news. (1) is scheduled to be implemented in Zabbix 2.4. (2) is to be discussed, I hope it will also be implemented. I think that the functionality is linked to I'll keep you updated here. | ||||||||||||
Comment by Volker Fröhlich [ 2014 Jan 23 ] | ||||||||||||
| ||||||||||||
Comment by Andres Toomsalu [ 2014 Jan 23 ] | ||||||||||||
Alexei: Ack fully for the reasons behind that we dont see at first glance - but now I can understand these better when explained Actually now everybody can read it here and understand it perhaps - so I think its a positive thing (ie this discussion) and absolutely worth the effort! | ||||||||||||
Comment by Marc [ 2014 Jun 26 ] | ||||||||||||
Just in the unlikely case this might be achieved by something like 'virtual events', then this could possibly help with ZBXNEXT-97 too. | ||||||||||||
Comment by Vicenç Juan Tomas [ 2014 Sep 04 ] | ||||||||||||
How can I reset the trigger status right now? Anybody knows? | ||||||||||||
Comment by Steve mushero [ 2014 Sep 14 ] | ||||||||||||
Did this get into 2.4 as I don't recall it mentioned as new feature - we need this, too, and if not in 2.4 our temp solution is to probably try this:
| ||||||||||||
Comment by Oleksii Zagorskyi [ 2014 Sep 14 ] | ||||||||||||
Steve, If it would be included to 2.4 - it would be closed already. | ||||||||||||
Comment by Hilton Howie [ 2014 Oct 01 ] | ||||||||||||
I have version 2.4 and need this ability to reset a trigger to OK for windows events. This is an urgent requirement, please can someone from Zabbix let me know how to do this, we have just signed up to an Enterprise agreement and Im not going to deploy this to prod unless I can reset the windows events to OK as the majority of our monitoring is for our application that utilises the windows event logs. | ||||||||||||
Comment by Filipe Paternot [ 2014 Oct 23 ] | ||||||||||||
Well, i have looked into few comments and i think we are missing the point here. The trigger is supposed to show the current status of an logical evaluation based on the values collected. If that trigger has been acknowledged, it could not be shown on the trigger list, if the filter is set to do so.. This already exists.. Maybe, the issue # | ||||||||||||
Comment by Marc [ 2014 Oct 23 ] | ||||||||||||
fpaternot, from my point of view the main driver is to have an option to somehow "reset" a trigger, or send an virtual OK event, for triggers based on items that don't necessarily get values regularly. That's e.g. often the case for event driven items like log items or traps. | ||||||||||||
Comment by Filipe Paternot [ 2014 Oct 23 ] | ||||||||||||
Marc, i see. Items that Zabbix get the 'error state' but they do not notify (or take too long) to send an 'ok state'. I dont see this situation very often on my day-buy-day activity, however after reading every single comment, i think its a great feature if we could somehow use a macro inside that trigger to evaluate the acknowledge status. I'm not a fan at all if this would become the standard behaviour, but it we could use this inside the trigger, it could turn out to be quite useful for many people. | ||||||||||||
Comment by Marc [ 2014 Oct 23 ] | ||||||||||||
When using a macro is meant to be used in a way that a trigger expression is only TRUE, if the corresponding event is not acknowledged, then this might not help in every case. | ||||||||||||
Comment by Filipe Paternot [ 2014 Oct 23 ] | ||||||||||||
Yes you`re right, a trigger is only evaluated when new item data comes in. | ||||||||||||
Comment by Raymond Kuiper [ 2014 Oct 27 ] | ||||||||||||
Guys, see my comment from 2011 May 04 10:57, we can indeed use a trigger ack macro for this. ({Host:item.nodata(60)}#1 & ({TRIGGER.VALUE}=0) | ({TRIGGER.VALUE}=1 & {TRIGGER.ACK}#1) | ||||||||||||
Comment by Wojciech Wronka [ 2014 Nov 21 ] | ||||||||||||
It seems that enabling TIGGERS.ACK macro on 'trigger expression level' could do the trick. | ||||||||||||
Comment by Michał Grzędzicki [ 2015 Jan 14 ] | ||||||||||||
Patch against 2.4.3, adding support for TRIGGER.ACK works fine it schemas like {host:item.change()}<>0 or ({TRIGGER.VALUE}=1 and {TRIGGER.ACK}=0) | ||||||||||||
Comment by Michał Grzędzicki [ 2015 Jan 14 ] | ||||||||||||
about 104.patch file sql currently doesn't use indexes so it might be slow, Maybe it's not a cleanest approach but it works, when it will use indexes performance impact should be neglectable queries from https://support.zabbix.com/browse/ZBX-4357 aren't using indexes mysql> explain select count(*) from events where object=0 and objectid=13141 and value in (1,0) and acknowledged=0\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: events type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 25 Extra: Using where 1 row in set (0.00 sec) mine will mysql> explain select * from events where source=0 and object=0 and objectid=13557 and clock=1421166380\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: events type: ref possible_keys: events_1,events_2 key: events_1 key_len: 20 ref: const,const,const,const rows: 1 Extra: 1 row in set (0.00 sec) I will also change the syntax to TRIGGER.EVENTS.ACK to be more consistent with other parts of zabbix. Does anyone still care about this ? Is zabbix team interested in merging this feature if we manage toresolve issues (performance, better gui integration, naming) ? | ||||||||||||
Comment by Hilton Howie [ 2015 Jan 14 ] | ||||||||||||
Yes I still care about this and would be great to get it working. | ||||||||||||
Comment by Wojciech Wronka [ 2015 Jan 14 ] | ||||||||||||
Same here. This feature would optimize our workflow greatly. | ||||||||||||
Comment by Michał Grzędzicki [ 2015 Jan 14 ] | ||||||||||||
I think I have fixed the performance issue, now the query is using an index. I have moved the sources to github https://github.com/lazy404/zabbix/wiki so basically wget https://github.com/lazy404/zabbix/archive/trigger.ack.zip unzip trigger.ack.zip ./configure .... | ||||||||||||
Comment by Tomasz Pawelczak [ 2015 Jan 14 ] | ||||||||||||
+1 from me | ||||||||||||
Comment by Michał Grzędzicki [ 2015 Jan 23 ] | ||||||||||||
Hi, Did anyone test the patched version ? | ||||||||||||
Comment by Max N [ 2015 Feb 09 ] | ||||||||||||
I really like to have this feature implemented since logfile monitoring without the ability to reset a trigger is basically useless when one greps for "ERROR" in a logfile and the string ERROR only pops up once a day or even less frequent keeping the alarm up for all eternity. | ||||||||||||
Comment by Michał Grzędzicki [ 2015 Feb 09 ] | ||||||||||||
Max feel free to check my https://github.com/lazy404/zabbix/archive/trigger.ack.zip branch (based on latest 2.4 release). I have contacted zabbix devs and this issue isn't on the roadmap, so I don't expect it to be merged anytime soon. This patch is almost trivial and small under 50 lines of code, i don't think it whould take long to merge it or find problems if there are any. | ||||||||||||
Comment by Max N [ 2015 Feb 09 ] | ||||||||||||
Hey Michal, thanks for the patch, but it will take some time 'till we either update to 2.4 or test/port the patch to our current installed v 2.2.5. Sadly, we have no commercial support subscription :/. Until then, I configured an action that will execute a zabbix-sender which again will send "0" to the Item to reset the Trigger after 5 minutes. | ||||||||||||
Comment by Max N [ 2015 Feb 09 ] | ||||||||||||
Actually, i just pimped my workaround to have the fake "log-entries" to be deleted once the trigger was "reset". My reset-action, only triggered by the trigger to be reset:
where step 1 is basically a NULL action only to delay step 2 Step 2 fires the following remote command to a machine with set-up ODBC: user=<zabbix-database-user> password=<zabbix-database-password> for times in {1..5} ; do zabbix-sender -z <zabbix-server> -p <zabbix-trapper-port> -s <source-system-with-logfile> -k '<key-to-logfile-on-server>' -o '---Zabbix-Problem-Ack-Marker---' done sleep 60 #delay to give zabbix time reset trigger echo 'delete from history_log where value = "---Zabbix-Problem-Ack-Marker---" AND itemid = '<itemid>' ;' | isql -b -d" " ODBC-connection $user $password #delete prev. false "logentries". If you can live wit false logentries in your historical data, better skip the delete statement - it probably messes with your zabbix database and i'll watch this on a test system for a long while now. Hope this dirty trick will help someone who cant apply Michals test like me. The times {1..5}will have to be modifed depending on how many logentries your triggers looks in the past. Mine checks the last 5 entries so i'll have to send him 5 logentries wich do not match the triggers expression. | ||||||||||||
Comment by Oleksii Zagorskyi [ 2015 Feb 11 ] | ||||||||||||
Just FYI: If someone would want to just update trigger.value=0 in database - it will not work because the trigger.value is stored in configuration cache and zabbix server re-uses it. Here is my test on 2.4.3 14823:20150211:121033.728 In evaluate() expression:'77>5' 14823:20150211:121033.728 End of evaluate() value:1.000000 14823:20150211:121033.728 End of evaluate_expressions() 14823:20150211:121033.728 In process_triggers() values_num:1 14823:20150211:121033.728 In process_trigger() triggerid:13575 value:0(0) new_value:1 14823:20150211:121033.728 End of process_trigger():SUCCEED 14823:20150211:121033.728 query [txnlev:1] [update triggers set lastchange=1423649429,value=1 where triggerid=13575;] 14823:20150211:121033.729 End of process_triggers() 14823:20150211:121033.729 End of DCmass_update_triggers() 14823:20150211:121033.729 In DCmass_update_trends() 14823:20150211:121033.729 End of DCmass_update_trends() 14823:20150211:121033.729 In DCflush_nextchecks() nextcheck_num:0 14823:20150211:121033.729 End of DCflush_nextchecks() 14823:20150211:121033.729 In process_events() events_num:1 14823:20150211:121033.729 In DCget_nextid() table:'events' num:1 14823:20150211:121033.729 query [txnlev:1] [select max(eventid) from events where eventid between 0 and 9223372036854775807] 14823:20150211:121033.729 End of DCget_nextid() table:'events' [266:266] 14823:20150211:121033.729 query [txnlev:1] [insert into events (eventid,source,object,objectid,clock,ns,value) values (266,0,0,13575,1423649429,952917432,1);] manually executed: mysql> UPDATE triggers SET value=0 WHERE triggerid=13575; Query OK, 1 row affected (0.01 sec) PROBLEM value (6667) sent again:
14823:20150211:121103.755 In evaluate() expression:'6667>5'
14823:20150211:121103.755 End of evaluate() value:1.000000
14823:20150211:121103.755 End of evaluate_expressions()
14823:20150211:121103.755 In process_triggers() values_num:1
14823:20150211:121103.755 In process_trigger() triggerid:13575 value:1(0) new_value:1
14823:20150211:121103.755 End of process_trigger():FAIL
14823:20150211:121103.755 End of process_triggers()
14823:20150211:121103.755 End of DCmass_update_triggers()
14823:20150211:121103.755 In DCmass_update_trends()
14823:20150211:121103.755 End of DCmass_update_trends()
14823:20150211:121103.755 In DCflush_nextchecks() nextcheck_num:0
14823:20150211:121103.755 End of DCflush_nextchecks()
14823:20150211:121103.755 In process_events() events_num:0
14823:20150211:121103.755 End of process_events()
OK value (2) sent: 14823:20150211:121123.784 In evaluate() expression:'2>5' 14823:20150211:121123.784 End of evaluate() value:0.000000 14823:20150211:121123.784 End of evaluate_expressions() 14823:20150211:121123.784 In process_triggers() values_num:1 14823:20150211:121123.784 In process_trigger() triggerid:13575 value:1(0) new_value:0 14823:20150211:121123.784 End of process_trigger():SUCCEED 14823:20150211:121123.784 query [txnlev:1] [update triggers set lastchange=1423649479,value=0 where triggerid=13575;] 14823:20150211:121123.785 End of process_triggers() 14823:20150211:121123.785 End of DCmass_update_triggers() 14823:20150211:121123.785 In DCmass_update_trends() 14823:20150211:121123.785 End of DCmass_update_trends() 14823:20150211:121123.785 In DCflush_nextchecks() nextcheck_num:0 14823:20150211:121123.785 End of DCflush_nextchecks() 14823:20150211:121123.785 In process_events() events_num:1 14823:20150211:121123.785 In DCget_nextid() table:'events' num:1 14823:20150211:121123.785 End of DCget_nextid() table:'events' [267:267] 14823:20150211:121123.785 query [txnlev:1] [insert into events (eventid,source,object,objectid,clock,ns,value) values (267,0,0,13575,1423649479,752742380,0);] Configuration cache update after the SQL - doesn't provide any effect. dbconfig.c: /****************************************************************************** * * * Function: DCconfig_set_trigger_value * * * * Purpose: set trigger value, value flags, and error * * * * Author: Aleksandrs Saveljevs * * * ******************************************************************************/ void DCconfig_set_trigger_value(zbx_uint64_t triggerid, unsigned char value, unsigned char state, const char *error, int *lastchange) { ZBX_DC_TRIGGER *dc_trigger; LOCK_CACHE; if (NULL != (dc_trigger = zbx_hashset_search(&config->triggers, &triggerid))) { DCstrpool_replace(1, &dc_trigger->error, error); dc_trigger->value = value; dc_trigger->state = state; if (NULL != lastchange) dc_trigger->lastchange = *lastchange; } UNLOCK_CACHE; } | ||||||||||||
Comment by Florian Requardt [ 2015 Feb 24 ] | ||||||||||||
you could offer a timer as well to have a automatic resubmission if the problem had not been resolved by this time... | ||||||||||||
Comment by Marc [ 2015 Feb 24 ] | ||||||||||||
plexus, you're possibly interested in ZBXNEXT-1687 as well. Edit: | ||||||||||||
Comment by John Miezitis [ 2015 Apr 27 ] | ||||||||||||
After some consideration I believe this request should be changed somewhat. | ||||||||||||
Comment by Leonardo Rafael Morastoni [ 2015 May 12 ] | ||||||||||||
Hello! I have a log trigger that needs to be acknowledged every time that is triggered. I upgraded my zabbix server to 2.4.3 and I added the acknowledge verification(TRIGGER.ACK=0) in my trigger expression. I'm using the AND(E) operand. But my problem wasn't solved, it triggers every time yet. How can I configure my trigger to this feature works? Thanks, Leonardo | ||||||||||||
Comment by Oleksii Zagorskyi [ 2015 May 12 ] | ||||||||||||
Leonardo, the {TRIGGER.ACK} macro is not officially supported, it can work only if apply the patch, see discussion above. | ||||||||||||
Comment by Leonardo Rafael Morastoni [ 2015 May 12 ] | ||||||||||||
Oleksiy, I applied it. I forgot talking about it. | ||||||||||||
Comment by Leandro Lana [ 2015 May 14 ] | ||||||||||||
After install trigger ack... Item: log["/tmp/teste.txt","ERRO1"] Trigger: {hostname:log["/tmp/teste.txt","ERRO1"].str(ERRO1)}=1 >>Trigger OK {hostname:log["/tmp/teste.txt","ERRO1"].str(ERRO1)}=1 or ({TRIGGER.ACK}=0) >> Trigger error with status unknown: This error appears in dashboard. Invalid expression [{17469}=1 or ({TRIGGER.ACK}=0)] Someone could use this "trigger.ack"? | ||||||||||||
Comment by Michał Grzędzicki [ 2015 May 14 ] | ||||||||||||
Did you follow the instructions on https://github.com/lazy404/zabbix/wiki ? and are sure that You are running a patched version ? TRIGGER.ACK should be visible in the gui along with TRIGGER.VALUE | ||||||||||||
Comment by Leandro Lana [ 2015 May 14 ] | ||||||||||||
Yap Michael. I go to "Expression constructor" in trigger click in "insert expression" and open 4 options, after apply patch, open only 2 options. But don't work for me. | ||||||||||||
Comment by Michał Grzędzicki [ 2015 May 15 ] | ||||||||||||
don't use the patch it's outdated, please use https://github.com/lazy404/zabbix/archive/trigger.ack.zip instead | ||||||||||||
Comment by Leandro Lana [ 2015 May 15 ] | ||||||||||||
I use this patch Michal. Zabbix 2.4.3 Copyright 2001-2014 by Zabbix SIA, ZE 2.1.2 Gratz | ||||||||||||
Comment by Michał Grzędzicki [ 2015 May 15 ] | ||||||||||||
If You want to use my {TRIGGER.ACK} patch you have to use the sources from just as described at https://github.com/lazy404/zabbix/wiki | ||||||||||||
Comment by Leandro Lana [ 2015 May 15 ] | ||||||||||||
Michal. I am work with zabbix 2.2.4, update to zabbix 2.4.4, and execute your patch. (https://github.com/lazy404/zabbix/archive/trigger.ack.zip) Maybe my error is dont execute patch overwrite build. | ||||||||||||
Comment by Oleksii Zagorskyi [ 2015 May 15 ] | ||||||||||||
Guys, use please zabbix forum or IRC to discuss patching related questions, thanks. | ||||||||||||
Comment by Natalia Kagan [ 2016 Feb 28 ] | ||||||||||||
Hello, Could you update the status ? Are you plan to implement it in v3.0.x ? There was comment by Alexei Vladishev at 2014 Jan 23 16:48 : " ...I guess we have some good news. (1) is scheduled to be implemented in Zabbix 2.4. (2) is to be discussed, I hope it will also be implemented. ..." Thanks! | ||||||||||||
Comment by André Lauer [ 2016 Feb 29 ] | ||||||||||||
bump | ||||||||||||
Comment by richlv [ 2016 Feb 29 ] | ||||||||||||
please see http://zabbix.org/wiki/Docs/bug_reporting_guidelines#Reporting_an_issue | ||||||||||||
Comment by Alexei Vladishev [ 2016 May 13 ] | ||||||||||||
I have some good news for all of us. The functionality will be implemented in 3.2 as ability to close problems manually from the UI. Also it will be possible to configure on trigger level if it's allowed to close problems manually or not. | ||||||||||||
Comment by Andres Toomsalu [ 2016 May 13 ] | ||||||||||||
Nice! | ||||||||||||
Comment by Niumar Andre Klein [ 2016 May 13 ] | ||||||||||||
Thanks Alexei! This is really a good news! | ||||||||||||
Comment by Andris Zeila [ 2016 Aug 01 ] | ||||||||||||
(1) Database patch ready for testing in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-104 sasha Successfully tested! CLOSED | ||||||||||||
Comment by Andris Zeila [ 2016 Aug 02 ] | ||||||||||||
Server side ready for testing. | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 05 ] | ||||||||||||
(2) [I] data.tmpl
wiper RESOLVED in r61483, r61488 sasha CLOSED | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 05 ] | ||||||||||||
(3) [IS] problem.userid must be added into a database. wiper Database schema and patch done in r61490 wiper Added problem.userid handling. Also fixed closing of single event when multiple problem events from the same trigger are open. sasha CLOSED | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 08 ] | ||||||||||||
(4) [S] Template linkage ignore values of these fields: trigger.correlation_mode, trigger.correlation_tag and trigger.manual_close Related to wiper RESOLVED in r61515 sasha CLOSED | ||||||||||||
Comment by Gunars Pujats (Inactive) [ 2016 Aug 08 ] | ||||||||||||
(5) Translation string changes Strings added:
gunarspujats CLOSED | ||||||||||||
Comment by Gunars Pujats (Inactive) [ 2016 Aug 08 ] | ||||||||||||
(6) [A] New read-write attribute manual_close for trigger and trigger prototype methods create, update and get. Read-only for templated triggers and discovered triggers. RESOLVED in r61467 iivs CLOSED | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 08 ] | ||||||||||||
(7) [S] Task manager should process tasks every 5 seconds. I.e. pause between checks should be calculated by the same way as in timer processes. wiper RESOLVED in r61512 sasha CLOSED with small improvements in 61529. wiper Reviewed, added process title updates before entering main loop. sasha Thanks! CLOSED | ||||||||||||
Comment by Gunars Pujats (Inactive) [ 2016 Aug 08 ] | ||||||||||||
(8) [A] XML import/export. RESOLVED in r61473 iivs CLOSED | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 08 ] | ||||||||||||
(9) I think the time has come! src/zabbix_server/taskmanager/taskmanager.c
/* TODO: set problem_count to 0 after merging in 3274-3 changes */
diff->problem_count = 1;
wiper RESOLVED in r61509 sasha CLOSED | ||||||||||||
Comment by Gunars Pujats (Inactive) [ 2016 Aug 08 ] | ||||||||||||
(10) [A] New read-write attribute action for method event.acknowledge. RESOLVED in r61506 iivs CLOSED | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 09 ] | ||||||||||||
(11) [S] Have a look at my changes in r61524. wiper Thanks. CLOSED | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 09 ] | ||||||||||||
(12) Uninitialized variables: task manager ==25017== Conditional jump or move depends on uninitialised value(s) ==25017== at 0x41885D: update_correlated_trigger_problem_count (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x418A21: update_trigger_changes (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x419287: process_trigger_events (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x43F5E4: tm_execute_task_close_problem (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x43F80B: tm_try_task_close_problem (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x43F8F5: tm_process_tasks (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x43FA72: taskmanager_thread (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x48CC80: zbx_thread_start (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x41B738: MAIN_ZABBIX_ENTRY (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x48B636: daemon_start (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x41AE6C: main (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== ==25017== Conditional jump or move depends on uninitialised value(s) ==25017== at 0x418C12: update_trigger_changes (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x419287: process_trigger_events (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x43F5E4: tm_execute_task_close_problem (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x43F80B: tm_try_task_close_problem (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x43F8F5: tm_process_tasks (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x43FA72: taskmanager_thread (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x48CC80: zbx_thread_start (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x41B738: MAIN_ZABBIX_ENTRY (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x48B636: daemon_start (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) ==25017== by 0x41AE6C: main (in /home/sasha/zabbix-svn/branches/dev/ZBXNEXT-104/sbin/zabbix_server) wiper RESOLVED in r61537 sasha CLOSED with small fix in r61540. | ||||||||||||
Comment by Ivo Kurzemnieks [ 2016 Aug 10 ] | ||||||||||||
(13) [A] Please see my changes in r61538 gunarspujats OK thanks! iivs Thanks! | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 10 ] | ||||||||||||
(14) [F] CLOSING state is not displayed while server close a problem. iivs RESOLVED in r61552 gunarspujats CLOSED | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 10 ] | ||||||||||||
(15) [F] This message must be printed for OK event. Not for PROBLEM.
iivs RESOLVED in r61563 gunarspujats CLOSED | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 10 ] | ||||||||||||
(17) [S] "Manual close" operation closes triggers regardless of quantity of open problems wiper RESOLVED in r61542 sasha CLOSED | ||||||||||||
Comment by Alexander Vladishev [ 2016 Aug 10 ] | ||||||||||||
Server side was successfully tested! | ||||||||||||
Comment by Natalja Romancaka [ 2016 Aug 10 ] | ||||||||||||
(18) [F] checkbox 'Close problem' not disabled in acknowledgement form , if problem closed by a trigger and in state Resolved iivs RESOLVED in r61578 natalja.zabbix ui successfully tested gunarspujats CLOSED | ||||||||||||
Comment by Andris Zeila [ 2016 Aug 10 ] | ||||||||||||
(18) [S] Server crash when processing event correlation rules. sasha CLOSED | ||||||||||||
Comment by Natalja Romancaka [ 2016 Aug 10 ] | ||||||||||||
(20) [F] problem not closed manually when in first acknowledgement checked "Close problem" and selected "Selected and all unacknowledged PROBLEM events" or "Selected and all unacknowledged events" iivs RESOLVED in r61585 gunarspujats CLOSED | ||||||||||||
Comment by Ivo Kurzemnieks [ 2016 Aug 11 ] | ||||||||||||
(21) Resolved merge conflicts from trunk. Please review r61592 gunarspujats Reviewed, fixed dbupgrade error in r61596 iivs Thanks! | ||||||||||||
Comment by Ivo Kurzemnieks [ 2016 Aug 11 ] | ||||||||||||
Implemented in pre-3.2.0alpha2 (trunk) r61598 | ||||||||||||
Comment by Sandis Neilands (Inactive) [ 2016 Aug 12 ] | ||||||||||||
(22) [S] Use of uninitialized variable when task is not ZBX_TM_TASK_CLOSE_PROBLEM, see CID 152048. ** CID 152048: Uninitialized variables (UNINIT) /src/zabbix_server/taskmanager/taskmanager.c: 198 in tm_process_tasks() ________________________________________________________________________________________________________ *** CID 152048: Uninitialized variables (UNINIT) /src/zabbix_server/taskmanager/taskmanager.c: 198 in tm_process_tasks() 192 { 193 case ZBX_TM_TASK_CLOSE_PROBLEM: 194 ret = tm_try_task_close_problem(taskid); 195 break; 196 } 197 >>> CID 152048: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 198 if (FAIL != ret) 199 processed_num++; 200 } 201 DBfree_result(result); 202 203 return 0; wiper RESOLVED in r61601. sandis.neilands CLOSED. | ||||||||||||
Comment by Sandis Neilands (Inactive) [ 2016 Aug 12 ] | ||||||||||||
(23) [S] CID 152047: looks like sleeptime reset calculation is not working as intended, please take a look. ** CID 152047: Control flow issues (DEADCODE) /src/zabbix_server/taskmanager/taskmanager.c: 225 in taskmanager_thread() ________________________________________________________________________________________________________ *** CID 152047: Control flow issues (DEADCODE) /src/zabbix_server/taskmanager/taskmanager.c: 225 in taskmanager_thread() 219 DBconnect(ZBX_DB_CONNECT_NORMAL); 220 221 sec1 = zbx_time(); 222 sec2 = sec1; 223 224 if (0 == (sleeptime = ZBX_TASKMANAGER_TIMEOUT - (int)sec1 % ZBX_TASKMANAGER_TIMEOUT)) >>> CID 152047: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "sleeptime = 5;". 225 sleeptime = ZBX_TASKMANAGER_TIMEOUT; 226 227 zbx_setproctitle("%s [started, idle %d sec]", get_process_type_string(process_type), sleeptime); 228 229 for (;;) 230 { wiper RESOLVED in r61601. sandis.neilands CLOSED. | ||||||||||||
Comment by Ivo Kurzemnieks [ 2016 Aug 12 ] | ||||||||||||
(24) [D] API documentation needs to be updated gunarspujats Updated API documentation:
iivs The given information is not enough for API changelog. New fields should be also described in methods. Import/Export examples should be updated. The order of issues is also wrong and too many methods are mentioned in the changes. REOPENED gunarspujats Updated api changes, also updated following API documentation:
iivs Outdated and incorrect examples updated: Please, review. sasha Looks good to me. CLOSED | ||||||||||||
Comment by Leandro Lana [ 2016 Sep 14 ] | ||||||||||||
Hello, this change affects this new version 3.2? i am wait. Edited. Great i am update now | ||||||||||||
Comment by Leandro Lana [ 2016 Sep 17 ] | ||||||||||||
GREAT... function working perfectly... Thx | ||||||||||||
Comment by André Lauer [ 2016 Oct 12 ] | ||||||||||||
Am I missing something or is it possible to close a trigger / problem for a specified time? | ||||||||||||
Comment by Alexander Vladishev [ 2016 Oct 12 ] | ||||||||||||
alauer, now is not possible to close problem for a specified time. Existing functionality is very usable to close problems, generated by triggers with disabled OK events (OK event generation = None). | ||||||||||||
Comment by Vladimir Silin (Inactive) [ 2017 Feb 02 ] | ||||||||||||
(26) [D] Documented in: sasha Perfect! CLOSED |