[ZBXNEXT-4756] Add the possibility to have listeners listen on more than one port Created: 2018 Sep 25  Updated: 2018 Sep 28

Status: Open
Project: ZABBIX FEATURE REQUESTS
Component/s: Server (S)
Affects Version/s: None
Fix Version/s: None

Type: Change Request Priority: Minor
Reporter: Ben Garrison Assignee: Andris Zeila
Resolution: Unresolved Votes: 0
Labels: ports, server, usability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian 9 Stretch
Zabbix 3.4



 Description   

It would be nice if there is a possibility to have listeners listen on more than one port.
In my scenario, I have multiple devices I want to monitor behind a NAT of which I have no control over, so I have to do active checks.

Since I'm too lazy to deploy a proxy in that LAN, I figured it would be comfortable to have the option of skipping that and having each agent on each client communicate with a different port.

I have already tried that by issuing IP's in the format IP:PORT for those clients and there is certainly a connection being tried to be made by both the server and agent on that port.
I checked that with a netcat on that port and I am getting "ZBXD4{"request":"active checks","host":"test3"}"

The issue seems to come from the fact that Zabbix server listens in only on one port (by default 10051)

Please consider this as it will greatly increase the usability I can find in your project.



 Comments   
Comment by richlv [ 2018 Sep 25 ]

What's the plan/goal of using a different port?

Comment by Ben Garrison [ 2018 Sep 26 ]

Well the overall idea is to be able to communicate to other clients via the same public IP (when they're in the same internal network behind a NAT).
You could do that with a proxy, but as I said, it would be nice to have the option to skip installing and configuring a proxy and just let the server and agent communicate as normal, but with a second listener on, say 10053

Comment by richlv [ 2018 Sep 26 ]

I'm slow today - could you please clarify on how another port helps here?

Comment by Ilya Kruchinin [ 2018 Sep 27 ]

What's preventing a thousand of agents within LAN from connecting to a single port on Zabbix server in WAN?
I tried reading the feature request several times, couldn't understand what problem you're trying to solve.

Comment by Ben Garrison [ 2018 Sep 27 ]
Get value from agent failed: cannot connect to [[publicip]:10051]: [4] Interrupted system call

I assume that is.

Even if the issue isn't to do with multiple clients communicating via 10051, having the option of setting a client per port will make managing clients more easily, since you can cut them off just by closing the port they're using for example.

Comment by richlv [ 2018 Sep 27 ]

That message only indicates a connection failure - how would multiple ports help?
And having a port per client would be absolutely not manageable, and just impossible in bigger environments. Not to mention that cutting off a single source would be much simpler than restarting a daemon to make changes to the listen ports.

I have to concur with Ilya - what is the problem actually?

Comment by Ben Garrison [ 2018 Sep 27 ]

That message only appears when I enable more than one client from the same internal network. All three work fine if running alone in the network.
And having a port per client would provide people without access to a shell or zabbix, the ability to just close the port the specific client is talking over to interrupt their connection.
Sorry if I'm making this confusing.

Comment by richlv [ 2018 Sep 27 ]

The problem is highly unlikely to be related to ports, but that would be a more suitable topic to an interactive communication channel like IRC - consider asking at https://zabbix.org/wiki/Getting_help#IRC .

Comment by Ben Garrison [ 2018 Sep 28 ]

I have tried asking on there several days ago. They reccomended me what I think the solution would be to be requested as a feature. So I did just that.

Generated at Fri Apr 26 13:07:01 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.