What is the point of the Host configuration 'Monitored by proxy" drop down list?

[little_martian]

It might sound dumb, but hear me out:
I have a Zabbix Server (S), Zabbix Proxy (P), Zabbix agent on the monitored host (H).

I configured the agent on host H (ServerActive) with both proxy P and server S. This tells the agent to request active checks from the proxy P and the server S. The proxy is configured first in list, so this action triggers the registration of the agent on host H with the proxy P and thus, in the frontend host configuration, the host appears as "Monitored by proxy: P".

With proxy P in active mode, it connects to the server and requests configuration from it for the registered host on this proxy. With proxy in passive mode, the server pushes configuration of the hosts configured as monitored by proxy P to the proxy.

The proxy P has performance problems (too many hosts on this proxy) so I decided to change configuration in frontend for some hosts to be monitored by server S (agent should check for active checks with server also, as is configured, and Server configuration contains S and P so both server and proxy have direct access to the agent on H).

Initially, the host H appears to be monitored by server S now, but at the next configuration push (passive proxy) or configuration request (active proxy) the host changes as monitored by the proxy P.

1. Is this the normal behavior ? or is it triggered because I changed the proxy from active to passive and the host H was already registered with the proxy P ?
2. If this is normal behavior, what is the point of the drop down list in 'Monitored by proxy' ? It should be a read-only field.
3. If the drop down list is specifically designed (is also present in the mass update options) to be changed via frontend, is this a bug that I should report ?

Thank you.

[little_martian]

I forgot to mention, this happens on Zabbix 6.0.3

[cyber]

The whole idea of proxies is to take polling away from server. So why you configure both proxy and server to do the job? If it has too much to do add another proxy, do not set server to do it. You will take a lot of performance away from server...

I think your autoregistration rules turn it back to "monitored by proxy"... First you set it to monitored by server, then proxy updates and "forgets" that host, then your host comes again to ask items from proxy, because it is configured to and proxy finds it to be a new host and forwards data to server, where autoreg rules do their job and assign that proxy to that host again.

[little_martian]

I can understand this behavior when the proxy is in active mode, it requests data from the server for all hosts registered with the proxy
But when the proxy is in pasive mode, it should only monitor hosts presented by the sever as monitored by this proxy, even if a host is registered with the proxy, if it is not present in the server configuration pushed to the proxy, the proxy should ignore agent requests for active checks, just as the server does when a host is set to be monitored by proxy, it should not change the 'monitored by' in the server.
I do not have any discovery rules set (Configuration/Discovery) and the only options on Administration/Autoregistration are Encryption level parameters
I suspect it will be the same if I add another proxy. The only way I see to fix this is to reconfigure the agents to remove the proxy from ServerActive and reset the proxy database and let all hosts re-register with the proxy (except the ones I reconfigure the agents). This defeats the purpose of the configuration in the frontend.

[little_martian]

I opened a ticket (ZBX-20912), let's see what the developers say about this behavior.

[cyber]

You are mixing up things here a little bit...
Active proxy means, that proxy will send away to server its data periodically, without Server requesting it. And also requests monitoring config changes. Passive proxy means, that Server polls gathered data from Proxy. and also sends monitoring changes to proxy.
Neither does not change agent behaviour. If you have "ServerActive" parameter in your agent config, you already have "active agent", which goes and requests items to monitor from proxy. Items, that are of type "zabbix agent (active)" will be given over to agent and proxy will not poll them. If you have no such items, then your proxy will poll everything, and it looks the same as with "passive agent". But from the moment you assign "active" item to that host, it will deal with it by itself... And agent still goes and asks for config periodically... Which will trigger registration and config change...

[little_martian]

Well, then I come back to my point: what is the purpose of a configurable value in frontend in this case ? It should be a read-only value.
But on the usability front, it is very useful to be able to change who monitors a host, the server or one of the proxies, regardless of the agent configuration, otherwise, moving hundreds or thousands of hosts from a proxy to another proxy or from a proxy to the server is a full manual task of reconfiguring all agents and maybe resetting the old proxy database to "forget" previously registered hosts.

[cyber]

That dropdown will work for passive agent setup. Or network devices, which have no agent at all.

If you have something under "ServerActive", that agent will turn to those endpoints and request data. Triggering update to proxy value etc... You should not have proxy and server both there. Multiple values are only for using different Zabbix instances with same agent

For moving thousands of hosts you should probably approach it from other side... distribute config change to agent and point it to other proxy. Currently agent is pretty much tied to the proxy in its config.

There is note in roadmap for 6.2, that they should provide HA and loadbalancing for proxies... That might be of interest for you. Then you can build a proxy cluster and add nodes there in case of performance issues ..

[little_martian]

Thank you for the info.
If that is the logic of that dropdown list, it is really confusing. On the other hand, I do not understand why it was implemented like this and not more flexible and take the full advantage of that dropdown list.

Anyway, the roadmap in question appeared on another question I had regarding single point of failure, I can't wait for it to get implemented

[cyber]

Its called history.. Historically server has never been able to update any config option in agent, but agent starts up based on options in config file... Then here you go, cannot update on the fly. Have to change config externally and restart agent...