How to Allow Server=*.*.*.* (from all) in agent conf

[yogi]

Hi,
How can i make zabbix (version 3.01) agent to accept connection from allor from subnet?? my zabbix server has a dynamic ip... so i need my agent to accept connection from all...
Thanks,

[jan.garaj]

https://support.zabbix.com/browse/ZBXNEXT-12 - probably next Zabbix release

[yogi]

Thanks! Do you know what is the next version? and when it's comming out?

Thanks!
Do you know what is the next version? and when it is comming out?

[jan.garaj]

Release date of Zabbix 3.4 is March, 2017, http://www.zabbix.com/life_cycle_and_release_policy

[kloczek]

Hi,
How can i make zabbix (version 3.01) agent to accept connection from allor from subnet?? my zabbix server has a dynamic ip... so i need my agent to accept connection from all...
Thanks,

First question is: why you are still using passive agent setup?

[jan.garaj]

Because Docker world. Container IP is not static. OK we can use DNS - it's available in some mature Docker solutions out of the box (Kubernetes, Consul, ...). However it's additional part in your infrastructure, which you need to manage.

Server=*.*.*.* is simple solution, for people who just started with Docker or they manage small Docker cluster(s). That's also reason why my https://github.com/monitoringartist/zabbix-agent-xxl doesn't validate Zabbix server IP (Server=*.*.*.*).

[yogi]

Thank you Jan, is there a beta version (of 3.4)?

Thank you Jan, is there a beta version (of 3.4) that already support it?

[kloczek]

Because Docker world. Container IP is not static. OK we can use DNS - it's available in some mature Docker solutions out of the box (Kubernetes, Consul, ...). However it's additional part in your infrastructure, which you need to manage.

Server=*.*.*.* is simple solution, for people who just started with Docker or they manage small Docker cluster(s). That's also reason why my https://github.com/monitoringartist/zabbix-agent-xxl doesn't validate Zabbix server IP (Server=*.*.*.*).

Seems you do not understand that above factors are completely not relevant in case passive/active agent setup.
As well zabbix agent does not need to validate srv/prx IPs by IPs range.

[jan.garaj]

Seems you do not understand that above factors are completely not relevant in case passive/active agent setup.
As well zabbix agent does not need to validate srv/prx IPs by IPs range.

Yep, it's possible. But I expect real example, which will prove your thesis. Please go ahead, create swarm cluster (at least 2 nodes), deploy zabbix server there and then start to monitor swarm nodes. How do you set Zabbix agents and what are pros and cons of your Zabbix agent setup?

I'm happy to change my mind, but please be professional and provide real example.

[guzzijason]

So, you're deploying your zabbix server inside a docker container? Is that really necessary? Just because something *can* be containerized, doesn't necessarily mean that it *should* be.

__Jason

[jan.garaj]

Nope, that's not necessary. However I want it. My environments are dynamic and heterogenous. I don't need to care about OS, because all dependencies are included in the Docker image (see some threads about Zabbix 3.2 installation issues on Ubuntu 16 - no problem if they use containers). If you are agile, then probably you want to dockerize all the things (zabbix included).
Also some OS are designed to use containers (CoreOS, Photon OS, ...). Any non containerized solution will be hackish in their case.

If you are "enterprise" with legacy apps (Java 1.4, Oracle DB), then don't touch containers. Of course, you can find another valid reasons, why not to use containers in some cases.

So, 2 groups of users with perfectly valid reason to use or to avoid dockerized zabbix are here. This thread is to help that Docker boys please.

[guzzijason]

I still think that containerizing an app that perhaps wasn't designed with containerization in mind could be considered shooting yourself in the foot, but that's just my opinion.

At any rate, I think that given that your server is going to be addressed dynamically, the only way to get the agents to play nice with it will be to make sure that DNS gets updated for your server address, and then use active agents to talk to the server's DNS address. You can probably do it the other way around with passive agents, but I think (not positive) you would need to add the DNS FQDN to the Server= section of your agent config, and then ensure that the reverse DNS (PTR) record is correct for your server address, because the agent will need to resolve that.

I haven't actually tried this myself.

__Jason

[jan.garaj]

Yes, that can be good solution if your container IP is more or less stable. But it's not. Restart/redeploy/upgrade container and it will get new IP. Do we really want to update zabbix DNS server records manually all the time?

[guzzijason]

Yes, that can be good solution if your container IP is more or less stable. But it's not. Restart/redeploy/upgrade container and it will get new IP. Do we really want to update zabbix DNS server records manually all the time?

DDNS. Or some sort of service discovery solution, like Consul.

__Jason

[jan.garaj]

DDNS. Or some sort of service discovery solution, like Consul.

__Jason

Definitely good idea. It will be additional moving part in your infrastructure. Try to deploy consul/consul-template - no official rpm/deb packages. It must be part of your core infra with HA - you will need to form a consul cluster -> not a KISS (keep it simple, stupid) solution. Good idea, but a huge challenge for people who don't have a deep knowledge. It's not worth it for them.

My conclusion: Server=*.*.*.* (or IP range of your cluster)+ passive items and people in the Docker world will be happy, you/your scheduler can restart/move container in the cluster and it won't affect Zabbix functionality.