Include of option to rearm triggers only manually.

[zabbix_es]

Hello everybody:
It could be helpful if triggers had a checkbox to allow be rearmed only manually by users (no only automatically when the parameter supervised by trigger returns to its normal status).
I am thinking in triggers like checksum of files to check if configuration files have changed, versions, etc.
Now, if you check, for example each hour, if a file has changed, the trigger is only active during the first interval after change and next it will be rearmed automatically because next value will be the same that the value after change.
Yes, I know, you could check in events but I think that this triggers could be forgotten without taking any action.
I don’t now if it could be done with hysteresis.
Therefore I have the feeling that in past versions triggers were no rearmed automatically.

Best regards!

[Kai-Kai]

I think it's a good suggestion. I'm also interested in this feature.

[Alexei]

I don’t now if it could be done with hysteresis.

Yes, I think it can be done with hysteresis.

[Kai-Kai]

Sorry... but what is "hysteresis" ?

[Calimero]

Sorry... but what is "hysteresis" ?

Hysteresis is defining different conditions for "Up" and "Down". For example (as given is the manual): trigger is ON when room temperature is above 20° but only goes OFF when temperature is again below 15°.

Some monitoring tools have explicit "On" conditions and "Off" conditions.

In zabbix you can emulate that behavior by writing triggers using TRIGGER.VALUE. See page 132 of current manual.

[Kai-Kai]

Oh !
Seems to be wonderfull...

So, if I right understand, hysteresys is the answer to this topic I've made a few days ago isn't it ?

http://www.zabbix.com/forum/showthread.php?p=48201#post48201

[Calimero]

Looks like it is.

[zabbix_es]

Could someone explain how to implement this functionallity with, for example, checksum of a file?.
I suppose that, even if were posible to do it with hysteresis, it could be a bit annoying to repeat it for all triggers of that type.

Were triggers rearmed automatically in earlier versions of zabbix?

Yes, I think it can be done with hysteresis.

[Kai-Kai]

According to me, if you replace the trigger :
{xxxx.xxxx.test()=X}
with :
({xxxx.xxxx.test()=X}) | ({TRIGGER.VALUE}=1)
the trigger won't come back to the normal even if the problem is solved.
This line mean, the trigger activate itself is test()=X become true, or if it's active. So if it becomes active, the second part stay true, and so the trigger stay active...

But... now I wonder how we can "rearm" manually...

Were triggers rearmed automatically in earlier versions of zabbix?

I don't know because I haven't use previous versions of Zabbix, but I think yes because the trigger is a logical expression which is active as long as the expression is true... if the expression become false, the trigger become unactive.



If your problem is you're afraid to forget a trigger, you can also configure your zabbix to send an email on a specific mailbox, when a specific trigger is activated. This way, even if the trigger come back to inactive state, you have your notification.
I think it's another way to proceed.

[dougbee]

Could someone explain how to implement this functionallity with, for example, checksum of a file?.
I suppose that, even if were posible to do it with hysteresis, it could be a bit annoying to repeat it for all triggers of that type.

Were triggers rearmed automatically in earlier versions of zabbix?

I'm wondering if you ever found a solution for this, particularly in regard to the checksum of a file. Assuming we have a trigger that indicates a problem when a file's checksum or timestamp has changed, it will of course reset to "OK" upon the next check.

Changing the trigger to this:
({my.host.com:vfs.file.time[/etc/testfile,modify].diff(0)}>0) | ({TRIGGER.VALUE}=1)

... does indeed leave the trigger in a "PROBLEM" state, even at subsequent checks. What I'd like to do is have the trigger go back to "OK" once it's acknowledged.

Any ideas on how this can be achieved?

thanks!

[Bennie]

In your situation i think the only way is to set the OR value to something that can only be done by hand. Let me try to explain.

Your current trigger:

({my.host.com:vfs.file.time[/etc/testfile,modify].diff(0)}>0) | ({TRIGGER.VALUE}=1)

As said this will keep your trigger active till the end of time. You want to 'reset' it again after you have modified the trigger. This can be done by adding a condition after the TRIGGER.VALUE=1 part. Since you want to control this it might be easiest to create a new item e.g. testfile.reset and give it value 1

Setup the following trigger

(TRIGGER.VALUE}=0&{my.host.com:vfs.file.time[/etc/testfile,modify].diff(0)}>0) | ({TRIGGER.VALUE}=1&{my.host.com:testfile.reset.last(0)}>0)

Filetime changes making your trigger fire. It stays 1 until testfile.reset is set to 0. This will be a manual thing and can be done with the zabbix_sender. Once it has been reset and the trigger goes back into normal you need to set the testfile.reset to 1 again to keep it triggered until reset.

This is some work if you have lots of filechanges. Not sure how else to do it with these timestamp values.

If macro's get supported in triggers you can easily set a macro for reset on the host and change the value to 1/0 for reset. The acknowledgement status macro is not supported in trigger either so thats a no go atm.

Hope this works out for you and if not someone might get some ideas how it work from it.

[dougbee]

Thanks Bennie, I'll have to see if using zabbix-sender is feasible. I did notice a couple of requests along the same lines:

https://support.zabbix.com/browse/ZBXNEXT-104

https://support.zabbix.com/browse/ZBXNEXT-645

So perhaps it is something that will get incorporated in the future..

[Bennie]

The tickets seem active.

The option to use a macro "ACK.STATUS" in the trigger could be a solution.

[qix]

The option to use a macro "ACK.STATUS" in the trigger could be a solution.

Good one, I added a comment to the ticket.

[qix]

Thanks Bennie, I'll have to see if using zabbix-sender is feasible.

I used a similar approach for windows eventlogging.

A former collegue of mine build a little C# tool that when clicked send a couple of values with zabbix sender so a trigger could be reset by a windows admin that was logged in on the box where the trigger had come from. He had to login to inspect the problem anyway

We included the tool in the zabbix agent installer we made, so it was on all the windows hosts.

There are of course other ways of doing this, but it seemed to work ok.