Voted. The only thing I don't like is a separate utility. It needs to be installed separately (which may be an issue in some environments) and it's kinda weird to have Zabbix but not have control over it. How is zabbixctl different from zabbix_<something> -R?

glebs.ivanovskis We already install the zabbix_get, zabbix_sender utilities. Out of the name (just preferences) that in this case is just an example, keeping the utility code separated is more a matter of keeping the server code clean and making it easier to do something like:

zabbix_<whatever> log verbose

or

zabbix_<whatever> show stats

Without adding the code to the (already) big codebase of the server. It's more semantic separation than anything else. But any approach will do the job anyway

I think it will be reasonable to use some platform-independent MQ to send commands to zabbix components. For example, ZMQ is very small library that can be compiled in each unix and on Windows as well.

So we need to simply create 1 queue for every zabbix component running on the server: for example. we can send proxy control commands to zabbix-proxy-NNN queue (where NNN is a unique instance id in the system) and agent control commands - to the zabbix-agent-YYY queue. Instance id can be stored in any place defined by the service configuraton file (zabbix_[proxy,server,agentd].conf).

Actually zabbix already have an internal library for performing
IPC operations. As a starting point it could be a good idea to
just be able to control the server and maybe, if it tuns out that
the feature is flexible enough and useful, extend it to control
other areas of the subsystem.