It may be useful to consult with how OpenNMS implements this feature, which it calls "Downtime Models":

http://www.opennms.org/wiki/Polling_Configuration_How-To#Downtime_Models

The incentive is to report more accurate SLA:

By default, the poller will poll every five minutes. If that polling rate was static, then the shortest an outage could be would be five minutes: one poll to note the outage and the next to note it was restored.

...

To help combat this, OpenNMS uses adaptive polling. Once an outage is detected, polling is temporarily increased to try and detect, as soon as possible, when the service is restored.

<downtime interval="30000" begin="0" end="300000"/> <!-- 30s, 0, 5m -->
<downtime interval="300000" begin="300000" end="43200000"/> <!-- 5m, 5m, 12h -->
<downtime interval="600000" begin="43200000" end="432000000"/> <!-- 10m, 12h, 5d -->
<downtime begin="432000000" delete="true"/> <!-- anything after 5 days delete -->

The "Downtime Models" by OpenNMS is good exaple. The other options is to use the "action" function yet present in zabbix by execute a shell action that change the item.
You can call API from shell but is not easy to implement without variable. The flow can be 1) trigger go into PROBLEM 2) execute action "call API and alter item's update interval" 3) trigger go into OK 4) execute action "call API and alter item's update interval" .

One major issue with using the API to alert the item's update interval is the caching that goes on. For instance, the configuration syncer runs every 1 minute by default on a Zabbix server. If I modify the item interval in the method mentioned by Luca, then I will up to a one minute timeframe before that change goes into effect. This doesn't sound so bad in a very basic default install, but it becomes much worse as you add in proxies and refresh intervals for active items.

For instance, in my Zabbix environment my server updates its config cache every 10 minutes, my proxies update their cache every 10 minutes, and my agents update their active checks every 10 minutes. So in the situation given above, I would have to wait up to 10+10+10 minutes (30 of course ) before my item interval could change.

I see that this feature request is already 3 years old, but has not yet been implemented.
I found this through this forum thread; https://www.zabbix.com/forum/showthread.php?t=14113 . which links to ZBXNEXT-1475.

I see that web-monitoring has implemented retries.
https://www.zabbix.com/documentation/2.2/manual/web_monitoring

Can the same technique that is used for web_monitoring be used for simple checks?

Quote for a re-check interval feauture.
If someone look also for bypass first failure trigger, look at https://www.zabbix.com/forum/showpost.php?s=a2cf4ca16769d1443c0c78d862dd1c5f&p=51870&postcount=2

Nagios also has this (retry_check_interval) details: http://serverfault.com/questions/329125/nagios-check-service-frequency-based-on-service-status

Related

Very interested in this feature. Would dramatically improve the quality of our open alerts both inside of zabbix and when brokered to services like PagerDuty.

+1

Once we have ZBXNEXT-1675, ZBXNEXT-3704 offers a more general approach to achieve same result.

a hack using the api has been described at http://www.zabbixbook.com/2016/10/24/using-the-zabbixtiny-to-change-an-item-interval-based-on-a-trigger/

I believe that it is quite good use case for throttling functionality, which was introduced in 4.2.

Hello,

Any update ?

See ZBXNEXT-8609