Any

items, not triggers, i suppose ?

Items is correct.

I am happy if we can setup even a script option that could force a refresh of all items on that host.

Seems to be like requests:
ZBXNEXT-653
ZBXNEXT-416

related to ZBXNEXT-388 ("deal with new items sooner")

We recently upgraded from Zabbix 1.6 to 1.8, and noticed that this doesn't seem to be possible anymore. Previously we'd just call reset_items_nextcheck($triggerids) in our customized triggers.php, which would trigger an item update within the next 0-30 seconds or so.

In 1.8 this function is gone, and recreating its functionality doesn't seem to affect anything. I also tried changing various fields in the DB directly, also without success.

Until this feature is added to Zabbix, is there any way to force an item update through the DB or something?

Something like this would be an awesome feature to have. Periodic monitoring is great, but the monitoring Zabbix does is like a set of unit tests for a running environment. The ability to force all of the tests to run as a way to validate a major change to the environment or to check everything after recovering from an outage of some sort would add a lot of value.

We run servers all over the world and really need this to check something we've just fixed or configured, network configured, etc. Especially for some things we only check each hour, etc.

Any progress on this? This is key feature for us.

For us too

This would be a really useful feature to have.

Would love to have it.

I think, I was able to make a patch for this issue.

Zabbix version: 2.1.0
Zabbix revission: 33506
Configure options: --enable-server --enable-agent --with-mysql
Kernel: Linux 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux
Distro: Debian GNU/Linux 7.0 (wheezy)
Tested in web-browsers: Google-Chrome v24.0.1312.57, Iceweasel v10.0.12, Mozilla Firefox v18.0, MS Internet Explorer 8.0
Patch's "svn diff": http://pastebin.com/grHQw3vT

Espessialy thanks to volter
Without him, I would not have been able to write this patch.

Implementation

Data for various item types is actually gathered and stored, using the regular server mechanisms. A new item status in the database indicates the server to poll data early for a particular item. No schema changes are necessary.

The server runs a certain number of StartDBSyncers processes, as specified in the config file. They're looking at the database once every minute and synchronize the server's cache.

I defined a new item status – ITEM_STATUS_CHECKNOW = 6, which signals, that an item should be checked as early as possible. Once a DBSyncer catches this status, it schedules this item's next_check at now()+1 seconds and changes the status back to 0 (ACTIVE).

Limitations

1) Doesn't work for trapping items (SNMP, Zabbix) and active agent items
2) The item's update interval must be 60 seconds at least. It's not useful to force a check for more frequently checked items, as it may take up to 1 minute for the DBSyncer to pick up the changed status.
3) Doesn't work on templates by design; Hosts must be in either "Monitored" state or "Maintenance with data collection". Forced checks for hosts in "Maintenance without data collection" don't take place.

Changes to the frontend

Latest data

Two additional columns show the item's status and a "Force check" button for everybody with read access to the particular host, except guests. Since there's a certain risk involved in this feature, users are warned of the consequences by a JS pop-up. Clicking the "Force check" button puts the item in the force check status and refreshes the view to reflect that.

Configuration/Hosts/Items

One additional column holds the "Force check" button. Forcing checks here gives you no warning. You're expected to know what you're doing. The behaviour is the same as on Latest data otherwise. Alternatively, you may use the checkboxes and drop-down menu at the button. The latter approach gives you a JS pop-up, alarming you about the potential risk involved in checking many items at once. Checking disabled items leaves them in enabled state afterwards.

Discussion:

This implementation is versatile, as it's capable of dealing with any polling-type item – not just agent items. It can therefore force simple checks, external checks, SSH, SNMP and others. Data is not just shown, like it would be the case with zabbix_get, but actually recorded. This can be beneficial, if a problem is already solved, but the respective item will only be polled in 24 hours. Forcing a check can recover that flawed trigger. In cases where Zabbix is the only source of data for its users, forcing a check gives them up to date information.

The potential downside of this implementation is, that you may spring triggers by polling for data more often than expected. Imagine an item polled every 5 minutes and the following trigger belonging to it:

= 0. Given the normal interval, you'd expect the trigger to spring after around 15 minutes. Forcing checks may reduce that span. The audit log can help to unveil such cases.

Nice solution, thanks !
I want to discuss it.

They're looking at the database once every minute and synchronize the server's cache.

It worth to mention that actually not every minute but every server's config parameter /CacheUpdateFrequency/ seconds.
Of course many people use defult value which is 60 seconds, but I know that many middle/big size installations use much bigger such value - 600-3600 seconds. So this delay can be unaccepted if we consider the feature "Check Now".

I defined a new item status – ITEM_STATUS_CHECKNOW = 6, which signals, that an item should be checked as early as possible.

I'm afraid it can be problem for frontend and server because new (additional) item status should be correctly processed in many places (server & frontend side).
Zabbix Devs should answer to this question to bu sure.

Also, forcing a check shifts the schedule for the next check. Hourly upated items, originally polled at the full hour, will be polled at quarter past, if a forced check took place at quarter past.

hmm, I remember I once investigated the calculate_item_nextcheck() function and I'm not sure it will work as you described. I mean there should not be shifts for next checks after one forced shifted check.

Here is my own internal notes to zabbix code about this, sorry that no comments:

delay = current_delay;
                shift = (ITEM_TYPE_JMX == item_type ? interfaceid : itemid);
                nextcheck = delay * (int)(now / (time_t)delay) + (int)(shift % (zbx_uint64_t)delay);
#                           21600 * 1323910698/21600           + (25933      % 21600) = 1323911533
#                           1323907200                         + 4333                 = 1323911533
#                           less on 3498
                while (nextcheck <= now)
                        nextcheck += delay;
 
 
32477:20111215:025818.679 In calculate_item_nextcheck() interfaceid:30292 itemid:25933 delay:21600 flex_intervals:'' now:1323910698    Thu Dec 15 2011 02:58:18 GMT+2
32477:20111215:025818.679 End of calculate_item_nextcheck() nextcheck:1323911533 delay:21600                                           Thu Dec 15 2011 03:12:13 GMT+2

I know this feature request already long time and had my own vision.
I want to share how I see its implementation:

• frontend user clicks "Check Now" for item(s);
• Zabbix frontend performs a special request (let's say similar to global scripts) to zabbix trapper port.
• this request processed (permissions check etc) and will be passed to zabbix server core and then it will be executed in nearest second by one of zabbix pollers;
• received value will be processed further as usually.
• optionally new fresh received value could be displayed in frontend (latest data page ?) immediately.

This scenario looks to me more interesting

zalex_ua Some details above seems will not be true FOR icmpping checks after ZBX-4284 implementation.
Also - JMX checks have similar logic from very beginning, described here https://www.zabbix.com/documentation/2.2/manual/concepts/java#overview

It worth to mention that actually not every minute but every server's config parameter /CacheUpdateFrequency/ seconds.

Of course many people use defult value which is 60 seconds, but I know that many middle/big size installations use much bigger such value - 600-3600 seconds. So this delay can be unaccepted if we consider the feature "Check Now".

You are right, but i tried to make minimal changes to the server's code and especially to working principle.

I'm afraid it can be problem for frontend and server because new (additional) item status should be correctly processed in many places (server & frontend side).

I have already made this changes

hmm, I remember I once investigated the calculate_item_nextcheck() function and I'm not sure it will work as you described. I mean there should not be shifts for next checks after one forced shifted check.

you are right. sorry.

I want to share how I see its implementation...

I will try to make something like this

zalex_ua thanks for your advice =]

heh , usage of internal Jira syntax [~username] by community members leads to unexpected results - in the comment above it looks like a conversation between devs - looks like I wrote text "thanks for your advice =]", but actually Stas done that

Probably write just text like "Oleksiy, thanks for your advice =]" would be cleaner

i am not a programmer, but i has an idea, for this one we can use zabbix_get with a special option to insert the resul into the database.. now i want the actual data, the frontend run zabbix_get --insert-db $HOSTNAME -k $KEY

(1) considerations for final implementation :
a) must work (and be tested ) both with server and proxy;
b) if server/proxy is instructed to update missing item, failure should be returned
c) if server/proxy is instructed to update template item, failure should be returned
d) if server/proxy is instructed to update web monitoring item, failure should be returned
e) must work with lld rules
f) must work with web scenarios (scenario is passed, not it's items)
g) what about config sending to passive proxies ? scheduling is very similar to the polling...

There may be a way to accomplish the sentiment of this request (certainly what Sefan K. mentioned) with the zabbix_get tool / protocol:

Ref: Docs/protocols/zabbix proxy/2.0

Preconditions:

• PROXYNAME proxy is in an active proxy configuration
• monitored.host.name is assigned to proxy PROXYNAME

$ zabbix_get -s server.name -p 10051 -k '{"request":"history data","host":"PROXYNAME","data":[{"host":"monitored.host.name","key":"system.hostname","clock":1395680522,"ns":236229445,"value":"Hello, World"}]}'
{
        "response":"success",
        "info":"processed: 1; failed: 0; total: 1; seconds spent: 0.000045"}

(This is very similar to using the zabbix_sender tool with active items, but effectively emulating the data sender of the proxy.)

Ok, this is my try for passive check "check now" function: https://github.com/zabbix/zabbix/pull/1

Using trapper interface for passing request from PHP to zabbix server and simply updating the `nextcheck` to `now`.

This is a very important feature for us.
We are very happy to use Zabbix for our new infrastructure (we are aiming to monitor millions of items), but this is a very important feature for us, which can lead us to move to a different NMS.

Note: we can currently perform instant check using Check_MK + Nagios or Shinken (just to mention a couple of them).

"Check now" should also available to active zabbix agent items. Zabbix agents should perform a blocking read on a tcp channel to get information which items should be delivered by "Check now"

active agent item forcing is ZBXNEXT-810

Hi All,

In Zabbix-Extras we have this option in web interface

Hi Adail,

I do not see this option in the web interface with Zabbix Extras (ZE 2.1 with Zabbix 2.4) - how do you navigate to it? Do you have any screenshots of it?

Regards,
Joan

Hi Joan,

Go to a ITEM definition of any HOST (not template... a host because need a interface to get the data ) and look at "Key line"... you have a extra button for this function

Go to a ITEM definition of any HOST...

But "Latest data" page seems to be more suitable place for data requiring and receiving, isn't it?

note that this was voted by zabbix conference 2014 participants as the most needed feature and was supposed to be developed for zabbix 3.0 - but it turned out to be too complicated, thus it has not been implemented yet

Ok, none vote on ZBX Conference... but ... 138 here...

Currently I are making a new build of Zabbix-Extras... for Zabbix 3... I will still continue supporting this for Zabbix Agent (directly) requests.

no, this got the biggest amount of votes back then, but properly implementing the feature was too complicated, so it was not done - but let's move detailed discussions to irc

far, but a bit related - ZBXNEXT-388 asks to poll new items immediately.

Guys, I came from KS Advanded Host Monitor, and it has this feature from YEARS. Please add it, it's a MUST HAVE!

I also miss this feature, Please add it.

vukomir, how about expressing your demand by considering (co-)sponsoring development

Please add this feature? Many monitoring systems still has nagios and this is a feature where I am blamed when I have to tell zabbix doesn't have that feature.
Yes, I can do a check with zabbix_get and do a snmpwalk from a host; but that's too difficult..

I just can't afford the spend money for the developers...

Zabbix 3.4 has added the ability to run remote commands over proxys.
While I'm unfamiliar with the code of Zabbix, this leads me to think that this feature might be an opening to implement this?
Can the communication channel perhaps now also be used to implement this?

One more question, plz. (3, on their own)
I just added new [SNMP] items to my templates to collect serial numbers with period eq to 1 month. Do I really have to wait a whole month to gather data? How the scheduler works? Is there existing ticket about pulling data for new items in the nearest time?

your new items would be polled any time between now() + server config cache update interval + item interval.
with the default setting that would be one month and one minute.

i clearly recall a feature request to automatically poll new items sooner, but i cannot find it right now.

edit : pidzero on irc found it - ZBXNEXT-388

ZBXNEXT-4426 sounds similar, doesn't it?

ZBXNEXT-4426 does not give any guarantees that he check will be done with latest database data. So this issue is still left open for proper 'check now' implementation. What do we need is not only item check rescheduling, but also refreshing corresponding data in configuration cache before it.

Not similar to https://www.zabbix.com/documentation/4.0/manual/introduction/whatsnew400#retrieve_metrics_immediately ?

Can you close this request ? Similar to https://www.zabbix.com/documentation/4.0/manual/introduction/whatsnew400#retrieve_metrics_immediately for me.

Quoting Andris from his last comment:

this issue is still left open for proper 'check now' implementation. What do we need is not only item check rescheduling, but also refreshing corresponding data in configuration cache before it

OK, I understand. Thank you very much for your return richlv
I greatly appreciate this update from you on this pending ticket for a few years already.

Zabbix 6.2 has introduced nearly instant update of Zabbix server configuration cache and also ability to "Check now" from the "Latest data" . I am ready to close this issue. Any objections?

I agree. This is done. But may I shift your attention to ZBXNEXT-6169 to truly solve this request?

alexei, it is very valuable part of functionality, thank you very much.
At the moment it's possible to perform a "check now" for the most of check types performed by a Zabbix Server/Proxy – like Zabbix agent (passive), HTTP agent, SNMP agent, Simple check, etc. However, it's impossible to perform the same task for the network discovering. Is this functionality planned? Maybe, is there existing ZBXNEXT about that?

(added)
Unfortunately, I didn't find the appropriate ZBXNEXT, so I've created a new ticket. If there was already similar ZBXNEXT I missed, this my ticket could be closed as a duplicate.

Ok for me, alexei

I wait update for ZBXNEXT-6169 as starko

Closing Won't fix based on comments above. Feel free to re-open if you disagree.