local threshold configuration

[mkwinco]

Hello,

we are currently evaluating possible options for replacing our present monitoring/reporting infrastructure by an OpenSource alternative. Zabbix is one of our first choices to test because at first glance it really looks like made by someone who really did the job himself, and it's not all about useless autodiscovery network maps as many other projects.

However, there are certain features we require and I am not sure whether zabbix has them. This is the first and probably the most important one of them:

- For some very good reasons we require, that a system owner of a monitored server must be able to set up some monitored thresholds (for generating alarms) locally on the monitored system, preferably via a simple configuration file. (We have developed such monitoring solutions for HP OVO ourselves.) It is completely unacceptable for our business model to grant access to the monitoring server for anybody else than its administrators, but those administrators are not supposed to be the ones deciding about particular details (such as the thresholds) of monitoring setup for all monitored systems. Therefore a local config is a great way how to let the full responsibility of monitored thresholds to the system owner.

Has anyone already encountered with such requirement or developed such monitoring solution for zabbix? From that very little I know about zabbix it seems to me like mission impossible, because it has different philosophy of defining alarms.

Any advice will be very appreciated, since I like zabbix, but this would be a showstopper for us.

Thanks,
MKWinco

[richlv]

zabbix is based on the principle that all configuration that is related to actual monitoring is centralised, so somebody can't break monitoring of some systems by changing an obscure bit of configuration. so i'd say this is a bad idea

nevertheless, there might be a way to do this.
you could have a file defining specific thresholds. a process (a script would do) could read this file, then modify zabbix configuration using the api.

if you had a configuration management system, these thresholds could be set in there, and api access would happen from it.

you could still benefit from zabbix templating system by making this process modify host level macros.

there might be security implications, as the process will need write access to those hosts inside zabbix - thus somebody in control of the process could modify also items (monitored metrics) etc.

personally, i don't see the benefit in disallowing access to monitoring system, but allowing to modify its configuration remotely - sounds more like a way to push some specific feature in a specific monitoring solution

[mkwinco]

Thanks a lot for your answer richlv.

The local config is not the goal itself for us, it is the easiest way how to delegate the responsibility for the particular monitoring configuration to the platform support specialists without giving them access to the monitoring infrastructure as such.
Our present monitoring solution is based on a local script (distributed from mgmt server and executed regularly by monitoring agent), collecting the metrics (such as CPU or filesystem utilization), evaluating them against local config thresholds and generating and sending alarms to the mgmt server via the agent. However, it seems now, that this is not the best philosophy if we wanted to use zabbix. The zabbix agent purpose is very different than the one we use now (HP OVO).

Therefore we will have to think about the setup 'out of our current box'. The local config as such would be no longer feasible, but CMDB-based configuration sounds better, though there are some security consideration as you correctly noted.
Our reason why not to let access to management system configuration to other people is security. The system, that is capable to communicate and execute actions on various critical systems should not be in any circumstances easily accessible from outside (we have system owners scattered around . However, since I do like zabbix so far, I will try to reconsider whether there is any way out. Correctly implemented VPN tunnels, https, etc. could help.
Btw, I haven't found out so far if the agent-server communication is or at least could be encrypted in zabbix. Is it?

Cheers,
MKWinco

[richlv]

Our reason why not to let access to management system configuration to other people is security. The system, that is capable to communicate and execute actions on various critical systems should not be in any circumstances easily accessible from outside

definitely. with zabbix, you can actually make it so agents have very little permissions on the target system. if you are using only the built-in items, it's not a problem at all. if you need custom scripts, you can define this list on the agent, and you can't run arbitrary commands from the zabbix server in that case. so agents would only run the commands that are allowed in the local agent configuration file.

in that case you would not be able to run remote commands (action operations in reaction to some event), of course.

Btw, I haven't found out so far if the agent-server communication is or at least could be encrypted in zabbix. Is it?

not by some built-in method. of course, you can always tunnel and encrypt it with other means.