Provide UserParameter entries via include directory

[xaeth]

I understand the need for the UserParameter to be defined in the zabbix-agentd.conf file, but this mades large deployments a bit difficult. What would be nice would be the ability to have an entry at the bottom of the agent's config file that basically looked like this:

include "custom/*.entries"

And you could use your favorite package manager, config manager, or bash script to just push the files into the directory.

For a great example of a very efficient (imo) way of doing this look at how Debian/ubuntu manage include for the apache config. Its awesome.

[Alexei]

I believe it is already supported! You may include both files and directories:

Include=params.conf
Include=/etc/zabbix/user_params/ # In this case all files under the directory will be included

[xaeth]

thats awesome! i hadn't seen it mentioned before. thank you very much.

[troffasky]

What would be nice would be the ability to have an entry at the bottom of the agent's config file that basically looked like this:

include "custom/*.entries"

If you're wanting to configure multiple clients, then you need the client to be able to get its config from a central point, so something like:

include "zabbix://includes/client.conf"

so the Zabbix agent can get its config file from the server.

Thinking outside the box somewhat, how about have Zabbix listening on a multicast address? An unconfigured Zabbix agent would by default try to connect to 224.99.43.3 [for example, I don't know how one acquires a multicast address], from which it gets a config which contains the real IP address and relevant config details.

[nmail_uk]

Thinking outside the box somewhat, how about have Zabbix listening on a multicast address? An unconfigured Zabbix agent would by default try to connect to 224.99.43.3 [for example, I don't know how one acquires a multicast address], from which it gets a config which contains the real IP address and relevant config details.

Awesome idea! Along the same lines as Bonjour for auto service discovery?

[troffasky]

On second thoughts, just having it connect to 'zabbix' if unconfigured would make more sense than multicast.

[nmail_uk]

Would that not require that your host is called zabbix? Or a relevant DNS entry, which implies some form of configuration is required?

How about a command-line tool where you point it your Zabbix server and it grabs the configuration from there? Then everytime the agent starts up once configured, it pings the server to see if the config has changed (or the server could even "push" the new config out and remotely reload the agent?)

e.g. zabbix_config --server=12.34.56.78

I'm thinking of ways to keep Zabbix as simple, but usable as possible - e.g. zero-configuration client-side, centralised configuration server-side.

[troffasky]

Would that not require that your host is called zabbix? Or a relevant DNS entry, which implies some form of configuration is required?

Yes, it would. However, IME setting up an A record or a CNAME to point to a host is easy compared to getting multicast to cross subnets, as it would need to do in any non-trivial network design.

How about a command-line tool where you point it your Zabbix server and it grabs the configuration from there?

What, like the zabbix agent? Seriously, this should just be built into the agent itself, and it should try to connect to 'zabbix' or a multicast address or whatever, if unconfigured and fetch its configuration from there, at which point it'll be configured.

Some models of IP phone, for example, will pull down a default config file when they boot, and then a $MAC_ADDRESS.xml file. The default config contains general config parameters for all phones, the MAC-address specific one contains config parameters specific to the individual handset, eg phone number. Presumably we'd use hostnames rather than MAC addresses for this, but the general point stands.

I'm thinking of ways to keep Zabbix as simple, but usable as possible - e.g. zero-configuration client-side, centralised configuration server-side.

I'm pretty sure we both want the same thing. Multicast will work with minimal configuration in flat network designs [ie one subnet with everything on], a default DNS entry will work better on more complex network designs.

Another thing to consider is pushing the agent onto Windows clients over the network. There's a script that does this with VNC server [Fastpush - which neatly solves the chicken and egg problem of installing VNC on a machine you don't have remote access to], but it's cmd script. There may be equivalent tools in Samba that could be used from a Zabbix server.

[nmail_uk]

Yes, it would. However, IME setting up an A record or a CNAME to point to a host is easy compared to getting multicast to cross subnets, as it would need to do in any non-trivial network design.

Yes this is true, but IMO having to have a specific DNS entry is inflexible - I think it would be much better to provide a way of the user giving the server IP address or DNS entry specific to their server. Also what about those with a distributed setup? They wouldn't have a way of pointing different agents to different servers.

What, like the zabbix agent? Seriously, this should just be built into the agent itself, and it should try to connect to 'zabbix' or a multicast address or whatever, if unconfigured and fetch its configuration from there, at which point it'll be configured.

Yeah definitely, but again I think it should be something the user tells the agent, so for example any issues with the configuration could be spotted without starting the agent and thinking "ooh why didn't that start?" and having to dig through the log files.

Something like:

# zabbix_agentd --configure myserver.network.com
Connecting to Zabbix on 10.20.1.100... OK
Checking if my IP address is configured (10.20.1.90)... Yes - hostname "myagent1.network.com"
Downloading configuration... 20K received
Applying configuration... OK - written to "/etc/zabbix/zabbix_agentd.conf"
Starting agent... OK
[agent forks to the background as normal]
#

The server address "myserver.network.com" could also be written into the agent configuration file, so the next time the agent starts normally (i.e. without the --configure parameter) it can check the server and pull down a new config file if it's changed.

Some models of IP phone, for example, will pull down a default config file when they boot, and then a $MAC_ADDRESS.xml file. The default config contains general config parameters for all phones, the MAC-address specific one contains config parameters specific to the individual handset, eg phone number. Presumably we'd use hostnames rather than MAC addresses for this, but the general point stands.

That's what I was thinking - starting with nothing and pulling down a zabbix_agentd.conf file generated by the server, using the connecting IP address to work out which client host it is.

I'm pretty sure we both want the same thing. Multicast will work with minimal configuration in flat network designs [ie one subnet with everything on], a default DNS entry will work better on more complex network designs.

I agree we both want the same thing, however I feel both multicast and DNS both have their limitations, and we need to be as flexible (and simple) as possible.

Like you say, multicast won't work across network boundaries and certainly wouldn't help in my situation - my Zabbix servers are on a network in a completely different datacentre to my main production network.

Equally a static DNS entry called "zabbix" won't work as I have 2 Zabbix servers watching different parts of the network.

[troffasky]

Yes this is true, but IMO having to have a specific DNS entry is inflexible - I think it would be much better to provide a way of the user giving the server IP address or DNS entry specific to their server. Also what about those with a distributed setup? They wouldn't have a way of pointing different agents to different servers.

I meant a zabbix agent should default to connect to the host 'zabbix' if it has no configuration. It could then pull down its config from the server. This would not preclude you configuring agents in the way you configure them now.

That's what I was thinking - starting with nothing and pulling down a zabbix_agentd.conf file generated by the server, using the connecting IP address to work out which client host it is.

The connecting IP address should be usable as a parameter for including bits of config - for example, if it matches 192.168.10.0/24, include ServerA.conf, if it matches 10.35.93.0/24 include ServerB.conf. That way you can direct a client to the most appropriate server for the network it's on.

[nmail_uk]

I meant a zabbix agent should default to connect to the host 'zabbix' if it has no configuration. It could then pull down its config from the server. This would not preclude you configuring agents in the way you configure them now.

That then makes zero-configuration useless for me - I have two Zabbix servers. If I have 100 client agents to install and configure, why should I have to manually configure 50 to point to one server, and 50 to another?

The connecting IP address should be usable as a parameter for including bits of config - for example, if it matches 192.168.10.0/24, include ServerA.conf, if it matches 10.35.93.0/24 include ServerB.conf. That way you can direct a client to the most appropriate server for the network it's on.

That's after the client has connected to one of the servers. Again if I have 2 Zabbix servers (on the same network) I would have to set up all 100 clients on the server that issues the configuration, and 50 on the second server that they will report to.

Wouldn't a much better solution be to point all agents to the relevant server in the first place, and still benefit from zero configuration?

[Calimero]

Wouldn't a much better solution be to point all agents to the relevant server in the first place, and still benefit from zero configuration?

Magic ? Casting a spell ?

[nmail_uk]

Magic ? Casting a spell ?

Lol! Magic would be not having to even install the agent in the first place - just give Zabbix the IP address and it does it all for you!

We can dream

[troffasky]

Wouldn't a much better solution be to point all agents to the relevant server in the first place, and still benefit from zero configuration?

I'm not clear how pointing the agents at a server counts as zero configuration.

[nmail_uk]

I'm not clear how pointing the agents at a server counts as zero configuration.

Neither is forcing administrators to have to a DNS entry called "zabbix", which would be useless in a distributed/HA environment, or any environment where more than 1 Zabbix server is used.

At the end of the day, administrators have to install Zabbix on the agent servers, so it's a better solution to point the agent to the relevant server at the time of installation rather than having to have all agents configured on both the "master" server (to get their configuration) and the secondary that they will send their results to (if different from the master.)