"next gen dm" would be a better fit for this functionality, but i can't find an issue about it right now - if it's found, this should be closed as a duplicate

I don't recall already existing issues about "next gen dm".

Probably it's time to create and use new label
I think "dm-nextgen" should be ok.

Actually, this would be an absolute killer feature! I often stumble over desired setups where it would be very benefitial to have, say a Zabbix server in a natted network, a proxy having a public fixed IP address and then other proxies, again behind NAT devices. Also, larger organization structures with networks spread over the world would benefit from this feature quite a lot.

I'm a bit concerned about the increased delay by DataSenderFrequency resp. ProxyDataFrequency of each proxy in the chain.

When it's just about breaking the TCP connection, then this can likely justified by a reverse proxy like HAProxy:

Zabbix server --> HAProxy --> Zabbix proxy <--> Zabbix agent
Zabbix server <-- HAProxy <-- Zabbix proxy <--> Zabbix agent

When it's on the other hand about a connection direction change, then there's indeed something new required. Something that may act like a configuration cache and data queue or data transceiver, depending on the proxy mode:

Zabbix server --> Queue       <-- Zabbix proxy <--> Zabbix agent
Zabbix server <-- Transceiver --> Zabbix proxy <--> Zabbix agent

Where I'd actually limit it to the latter, the Zabbix transceiver. But I think now I'm slightly off-topic

Edit: Transceiver does not appear appropriate. Mediator is possibly a better term.

Yes, it's usually the second setup that I see a need for, and the "Queue" and "Tansceiver" is actually exactly what the Proxy does, but unfortunately not in such a chain. Sure you would have to set your DataSenderFrequency accordingly, but it should be OK to just take a little longer until agent configuration drops through the chain of proxies.
Btw for the first of the scenarios (with HAProxy), do you have an example config on how this could look like on the HAProxy side?

I have some hosts that are in a remote DC and have some nodes connected via a VPN to those hosts. I monitor the remote hosts via a proxy and want to start monitoring the far nodes but don't have a direct connection to them (so would like to connect

zabbix server -> DC proxy -> system (with zabbix-proxy) ->
remote vpn nodes with no direct route (zabbix-agent)

Hi all,

I stumbled upon that, and as a matter of fact, I always thought that chaining proxies in any way was not supported. Currently running 3.2.7.

However, I have a setup that's like this:

zabbix agent <-- zabbix proxy in DMZ (passive) <-- zabbix proxy internal network (passive) <-- zabbix master

It seems I am getting values for all, no error. Everything looks fine.

Am I just getting lucky? Or that configuration is actually supported?

Thank you.

@Fred, as far i understand Zabbix Master sends configuration to zabbix proxy internal, so you setup it on zabbix gui,  but in what way zabbix proxy in DMZ receive configuration from proxy Internal ? How do you setup it ? can you share some config ?

My main take on this one is regarding security. Zabbix server often has lots of key to many kingdoms (e.g. ssh keys for remote commands) and creeps me out letting its server port opened to the world. One single vulnerability in a publicly available 10051 could be a catastrophe.

A passive proxy in a DMZ consolidating all the data from agents and other proxies could avoid exposing the server to the world entirely.

                ,-------------,
ZBX server ---> | ZBX passive | <--- ZBX remote active proxy <---> ZBX active/passive agents
                |   proxy     | <--- ZBX active agents
                `-------------`

My approach so far is to restrict access to the zabbix server based on source IPs of the proxies, but this is cumbersome, specially in environments where active proxy resides behind failovers and can arrive from many source IPs (some backup links are dynamic)

It's a very important feature now that Zabbix integrate a proxy in Kubernetes monitoring.

In our case, we have 2 proxies per region of data housing.
In case of we had the supervison of Kubernetes, it would be interesting to plug the Kubernetes Zabbix proxy to others proxies.

Agree with the last comment.

akalimulin, we just discussed it on Zabbix Summit 2024.
This enhancement request gradually becomes more important now.

Use case #1: as mentioned above, the Kubernetes monitoring. It installs a Zabbix Proxy inside the Kubernetes cluster; however if this cluster is located on the remote site (for example, reserved data center) which is already monitored via proxy, then it can cause to problems. It would be logical to have that Kubernetes proxy be chained through the remote site proxy.

Use case #2: migration of Zabbix server to cloud. Some companies could prefer to migrate their Zabbix servers into a cloud. However, if they already have some monitoring infrastructure, it could be troublesome enough. As one of the possible migration paths, it could be a transformation of the existing Zabbix server into Zabbix proxy: it will allow to avoid a hard work for reconfiguration of existing infrastructure ("Server=" and "ServerActive=" parameters on each Zabbix agent, destination host for "zabbix_sender" utility in scripts, firewall rules modification, etc.).
However, if the existing monitoring infrastructure already includes some Zabbix proxies, then the same problem occurs: it will require a reconfiguration of these proxies, firewall rules for them, etc. It could be much more comfortable just to keep an existing configuration, but to have another Zabbix proxy chained instead of the existing Zabbix server (to collect all data and then transmit them into a new cloud Zabbix server).

Use case #3: just a complex network infrastructure (with a lot of subnets, VPN's, NAT's, etc.) where some remote sites can not access the central Zabbix server directly (or it is troublesome), but can access another Zabbix proxy.

I would add one more case to Case 1 of Constantin Oshmyan. With the new proxy groups, it makes sense in large implementations with multiple sites—for example, VM resources in Azure and AWS—to have a proxy group that meets all the needs of each region. The problem arises when there are multiple Kubernetes instances with networks that have no outbound access other than reaching the proxy group. This makes it impossible to use Helm to deploy the proxy within the Kubernetes cluster, as it will never have access to the Zabbix server.