Zabbix has an issue tracker for reporting bugs and feature requests. Users tend not to notice a voting feature in the upper right corner. But even when users find out about this feature, they might get a question – is it worth voting on issues?
Various projects use issue trackers in different ways. Various projects handle votes in different ways. How does Zabbix handle these votes?
Issue votes do not guarantee anything. Having 100, 200 or 500 votes alone will not make a feature top priority. On the other hand, votes can increase priority of a feature request. Many factors can affect this, among them:
- ease of implementation – if a simple change gets a lot of votes, it is more likely to be implemented than a major feature
- internal perception – if Zabbix developers see the improvement as a great thing, they are more likely to invest time
- exposure – if an issue has been raised in a major way publicly, that can be an extra motivation to implement it
Obviously, financed development will have a higher priority – but Zabbix team still evaluates the votes every now and then. A feature with 100 votes is more likely to get their attention than one with 2 votes. What’s the current top-voted feature?
Get me a value NOW
The top-voted feature request is ZBXNEXT-473, Ability to Check Now a specific passive item.
This feature request has been created back in 2010. Since then, it has accumulated 172 votes. It was also voted as the most important feature at the Zabbix Conference 2014 and was scheduled to be developed – but the feature turned out to be too complicated to properly implement at the time. So what is it about?
Older versions of Zabbix stored a nextcheck value in the database. This was a UNIX timestamp when the item should be checked next. It was relatively easy to force an item to be polled – just update nextcheck and server polls it again. It wasn’t very convenient and only worked with polled items (didn’t work with active agent items, for example), but it was very helpful to have.
Unfortunately, having such a field in the database also meant a lot of queries. Imagine selecting and updating this field every time an item had to be polled… The field was removed from the database and we lost the ability to hackishly force item polling. This was pretty bad for infrequently updated items (like versions or serial numbers that get polled once per week or so) and for unsupported items. When an item fails for some reason, by default it will be checked 10 minutes later. If you are fixing something, you have to wait 10 minutes before seeing the result. Another frequently desired thing is polling items after assigning a template to a new host. Often one has to wait for hours or even days to get the first value for items, and there is no way to speed this process up in a reasonable way.
This feature requests asks for a way to force item polling. It was evaluated by the Zabbix developers, and it turned out to be fairly complicated to do properly. For example, if one changes a user macro or a global regexp, then forces item polling, it would be reasonable to expect the new values to be used. But Zabbix server would have these cached, and thus the item would still not work as expected right away. Doing a full configuration cache update would also be resource-intensive, thus partial configuration cache update would be needed. And then there’s the question how to handle proxies and active agents… You can see the specification draft for more detail.
Does that make voting useless? Definitely not. If this issue would not have had that many votes, it would not have been considered at all. If you do not have an account in the Zabbix issue tracker, register and vote on all issues that are important to you. Maybe your vote will result in something nice getting enough attention.