Zabbix API Sessions

[insertcoin]

Hi,

I have developed a simple dashboard for Zabbix using the API, however after we upgraded from Zabbix 2 to Zabbix 3 I have been advised that it no longer works due to the way Zabbix 3 handles sessions with the processlist for MySQL filling up with session table updates due to 5-10 API requests every second or so.

The dashboard makes a request every second, with around 4-5 browsers open at any 1 time displaying the dashboard. Would this be too much, and is there a way the sessions can be improved.

Can anyone let me know if there has been a change between the way the sessions are handled from Zabbix 2 to 3?

Is there a solution to stop the tables from locking due to the API requests?

Cheers

[insertcoin]

Can this be moved to "Zabbix Help" please

[kloczek]

Can this be moved to "Zabbix Help" please

It is really hard to say anything not seeing what exactly your application is doing.

[insertcoin]

Here is what the application looks like, this refreshes every 500ms to make sure we have accurate information.

I have been told that this is generating a very large volume of sessions in the zabbix database, which are not being deleted.

(there are better ways to do this I agree, however this worked perfectly fine until we upgraded to v3).

[jan.garaj]

Do you use user.login method every 500ms?

[insertcoin]

Looking at the API I am using, that does appear to be the case.

This didn't cause a problem on Zabbix 2, only since we upgraded to Zabbix 3.

[Linwood]

This is not a technical comment at all, but a human/management one -- how would your staff react differently if this refreshed every 5 seconds instead? Or 30?

Given that 30 second polling rate for a device is fairly high, and that many polls require a few failures before they fire a trigger.

It's a very fair question why something changed, I'm not trying to say that's a bad question. But the 500ms caught my eye and I just wonder if, even if problem solved, you aren't pushing more work on the server than needed.

[kloczek]

Given that 30 second polling rate for a device is fairly high, and that many polls require a few failures before they fire a trigger.

Polling with higher rate make sense in many cases.
Example: polling CPU context switches/s with interval 5 or lower shows band of fluctuations of cs/s. On Solaris I'm using 5s interval for all fast changing metrics like many kstat *::arcstat:* on monitoring ZFS.
Another example could be MySQL com_{select,delete,insert,update}
Such metrics usually are not associated with any triggers and lower sampling interval is used only to show some temporary changes.
I have few few examples of metrics where I'm using even 1 or 2 seconds as sampling interval on some storages IO monitoring. Without such low sampling interval is not possible to figure out that storage is time saturated from point of view number of IO/s or byte/s.

At the moment it is not possible over agent sample metrics data with interval below 1s.
Only method avalaible is use trapper items.
Howwever far as I remember agent code it should be realatively easy change sampling rate to use interval below 1s but this change will need to redefine current meaning history interval stored in DB because it holds interval in seconds. Probably it would be good to redefine meaning this column to nanoseconds, multiple all currently used values of intervals by 10^9, add couple of changes in API and web front end and finally in agent code as well.

[Linwood]

Sorry, I guess I focused on sample rate, but I was really trying to focus on it as a dashboard item (I understood this to be the update rate of the dashboard?).

And a need for the dashboard to update at 500ms intervals.

If your staff reacts that fast, your network admins must be real serious coffee drinkers.