Looking for hosted Zabbix-server solution

[dreas]

Hi guys,

I was wondering if anyone is offering Zabbix server hosting. We're currently running our own Zabbix server in a VPS, but would be nice to have it located in a different network and not have to maintain the software. Possibly a service with multiple monitoring "nodes" to ensure something is really wrong.

It's just an idea Anyone offering such a service? Maybe zabbix.com could consider offering something like that?

[Alexei]

I am not aware of any company offering such services.

[suran]

I don't want to violate any forum rules, so please let me know if I'm out of line for offering.

I work (like so many of us) at a datacenter/hosting company. Offering hosted Zabbix is an idea I've been throwing around in my head for a little while now, and I'm starting to really like it.

What would your price-point be for a hosted Zabbix solution?

[dreas]

What would your price-point be for a hosted Zabbix solution?

I'm not sure. Basically you're competing with VPS pricing I guess. You'd probably want to price based on the amount of items (average per minute?) and hosts. Ideally it's a distributed setup so random network routing issues don't result in problems. I guess you could earn money with SMS notifications as well

[Vince]

I am also looking for a hosted zabbix solution. I've setup a small but growing monitoring system. It has about 330 hosts from 10 proxys that report in. It should not take much resources to host it, but we want to keep it separate from our other site, and need better uptime than our office's cablemodem can provide.

Please PM me with your offers for zabbix hosting.

Thanks!

[tekknokrat]

I am also interested in the hosting of monitoring services.
What keeps me from that is the current state of zabbix and my current lack of experience of zabbix in bigger hosting environments:

This is what I am missing for ZaaS (Zabbix as a service):

Permission model in frontend needs to be stable + extended:
There are still a few open bugs regarding issues of permission.
It should be possible to define "owner" of hosts. The current group read/write concept is not very clear and don't say anything about responsibilities in case of notification etc.

Customers should be able to put their own set of items, without breaking the server/client. It should be possible to create usage reports with the count of services/frequenzy and hosts monitored per customers.

By all - if an api is introduced it should be possible to create a webinterface with simplified functionality for such a customer purpose.

Global trigger dependencies:
Dependencies should be able to go into templates, too.

Redundancy and load balancing support for servers/proxy:

If the server dies the configuration of clients still needs to be adapted to a another server. This involves manual configuration on the clients. Using passive checks at whole would possibly work but it is a performance killer on both server and clients. So it should be at least possible to configure backup server ip on the clients.

Using virtual ip addresses for services gets more and more importance in enterprise environment. It should be possible to add and select from multiple ipv4/6 addresses to an interface either in host configuration and also for adding items.

Of course there are a lot of other features important for hosting i am not aware of.

[Calimero]

If I were to offer zabbix as a service, I would have multiple instances. Trying to have all your customers on a single instance seems quite suicidal to me.

The main problem to me with remotely hosted services is security. You would have to setup some kind of VPN and you should trust the service provider (who somehow as access to all your services as user zabbix if monitoring scripts are not carefully written).

[tekknokrat]

Having a single server instance for each user is of course the easiest way out of the security implications. But with one single instance configuration is easier. I see a nightmare managing the items and triggers on several servers also with use of a template system. Also it will still lack failover.

[suran]

There are still a few open bugs regarding issues of permission.
It should be possible to define "owner" of hosts. The current group read/write concept is not very clear and don't say anything about responsibilities in case of notification etc.

What's unclear about it? It seems pretty hierarchical to me. User->User Group->Host Group, and Notification Rule->Host Group->User/Group.

Customers should be able to put their own set of items, without breaking the server/client.

Is this not currently possible? I've never managed to break a server/client by adding a new item, but I'll admit, I haven't tried anything crazy.

By all - if an api is introduced it should be possible to create a webinterface with simplified functionality for such a customer purpose.

Heck, it's possible now - it's just a MySQL/etc database. It should be possible to create a new interface into it. Don't get me wrong - I'm all for the API - but this is the advantage of an unlocked platform - all the components are there to touch.

Global trigger dependencies:
Dependencies should be able to go into templates, too.

Absolutely yes!

Redundancy and load balancing support for servers/proxy:

If the server dies the configuration of clients still needs to be adapted to a another server. This involves manual configuration on the clients. Using passive checks at whole would possibly work but it is a performance killer on both server and clients. So it should be at least possible to configure backup server ip on the clients.

I believe this is already mostly possible. Redundancy on the server level can be accomplished with a package like heartbeat or whatever its equivalent is these days. I know that agents can already be configured with multiple zabbix servers. However, this is a failover configuration - load balancing would be nice!

Using virtual ip addresses for services gets more and more importance in enterprise environment. It should be possible to add and select from multiple ipv4/6 addresses to an interface either in host configuration and also for adding items.

Could you expand on this?

Of course there are a lot of other features important for hosting i am not aware of.

We wouldn't want Alexi to get bored.

If I were to offer zabbix as a service, I would have multiple instances. Trying to have all your customers on a single instance seems quite suicidal to me.

The main problem to me with remotely hosted services is security. You would have to setup some kind of VPN and you should trust the service provider (who somehow as access to all your services as user zabbix if monitoring scripts are not carefully written).

I'm not sure I agree with your assessment, but maybe I don't know better. I have quite a few customers on my existing shared Zabbix platform - it seems to work just fine and customers are not aware of each other's existence. What are the risks?

Also, what are the security implications of running a zabbix active check over the internet? My understanding is that the active checks are simply 'Agent, please check this thing that you know how to check, and give me a value', and 'OK, that thing's value is x'.

Given that Agents are restricted by server IP address, isn't this already rather secure - especially if firewall rules are used to only open the agent port to the correct IP?

[Calimero]

I'm not sure I agree with your assessment, but maybe I don't know better. I have quite a few customers on my existing shared Zabbix platform - it seems to work just fine and customers are not aware of each other's existence. What are the risks?

Security ?
Stability ?

Of course it depends on how much control you want to give to users.

Also, what are the security implications of running a zabbix active check over the internet? My understanding is that the active checks are simply 'Agent, please check this thing that you know how to check, and give me a value', and 'OK, that thing's value is x'.

Given that Agents are restricted by server IP address, isn't this already rather secure - especially if firewall rules are used to only open the agent port to the correct IP?

The problem is more on the client side: zabbix_agentd acts somehow as a trojan horse executing orders from a remote box. As a customer I'd be a bit reluctant to have all of my servers get instructions from a remote box without proper authentication, and over an unencrypted channel.

VPN or SSL would be required. And again, I don't like the idea of having anyone not inhouse having some kind of remote shell to all of my servers.

But then again it depends of what type of monitoring we're talking about and how sensitive monitored devices are. You could use a zabbix proxy + SNMP which would be quite harmless.

[suran]

Security ?
Stability ?

Of course it depends on how much control you want to give to users.

The problem is more on the client side: zabbix_agentd acts somehow as a trojan horse executing orders from a remote box. As a customer I'd be a bit reluctant to have all of my servers get instructions from a remote box without proper authentication, and over an unencrypted channel.

VPN or SSL would be required. And again, I don't like the idea of having anyone not inhouse having some kind of remote shell to all of my servers.

But then again it depends of what type of monitoring we're talking about and how sensitive monitored devices are. You could use a zabbix proxy + SNMP which would be quite harmless.

Again, though, I don't see where the security issue is. I have a nicely designed set of generic templates that users have read only access to. They also have write access, but only to their host group. I can't find something, logged in as a user, that I can do to affect the security or stability of the platform.

Scratch that, there's one thing. In the default GUI, users can edit the notifications, system wide. This is easily solved by removing portion of the GUI that allows viewing and manipulation of notification rules. However, this isn't really a great fix, so this issue is currently reported as a bug.

In terms of zabbix_agentd acting as a trojan horse - isn't that only if you explicitly turn on the remote commands functionality in the configuration file?

Unless I'm seriously mistaken, you cannot execute arbitrary commands on a server if all you have access to is the Zabbix server that its agent would communicate with.

[btoovey]

We host Zabbix

My name is Brian Toovey and I am the operations manager for the Bat Blue Corporation. We offer managed zabbix and consulting services. Please contact our sales team at 212-461-3322. Ask for Robert or Babak.

Thanks,
Brian

[Calimero]

Firstly, I'm not only talking about what the GUI permits or not. I'm talking about letting someone not inhouse with access to my servers.

The problem is not the templates, the problem is to have give some provider access to all servers from a remote location.

And yes of course as any multi-user/mult-customer application, you'd better check and recheck every release for potential security regressions and stuff.

That's why I think "1 instance per client" is much more manageable and less risky.

In terms of zabbix_agentd acting as a trojan horse - isn't that only if you explicitly turn on the remote commands functionality in the configuration file?

Yes, that's how you openly enable/use remote commands.

But consider this which is quite common, I believe.

UserParameter=my.check[*],/whatever/somehow/generic/stats/collector $1 $2 $3 $4

And then run:
/usr/local/zabbix/sbin/zabbix_get -s myhost -k 'my.check[|| ls]'

Hooray !

Of course you should write:

UserParameter=my.check[*],/whatever/somehow/generic/stats/collector "$1" "$2" "$3" "$4"

Then at least zabbix won't run whatever you give it. But of course you have to make sure that every single script you use won't allow any kind of code injection: check (maybe against a regexp) each and every parameter you get.

I admit that most scripts here only have some fairly simple checks and in no way would I ever allow remote access to our agents. Not before a thorough review of every piece of code/scripting.
On some specific servers user zabbix can sudo a specific set of commands as some stats must be collected as root. This again speaks against remote monitoring.

[suran]

Then at least zabbix won't run whatever you give it. But of course you have to make sure that every single script you use won't allow any kind of code injection: check (maybe against a regexp) each and every parameter you get.

I admit that most scripts here only have some fairly simple checks and in no way would I ever allow remote access to our agents. Not before a thorough review of every piece of code/scripting.

You should really be doing this anyways, no matter -who- controls your Zabbix server. Treat every system like it is publicly accessible - there are no 'trusted' networks or systems, and a self hosted zabbix platform is no exception.

If using a hosted zabbix platform would force you to evaluate your custom commands to remove command injection vulnerabilities, then it would actually be -better- for your security than remaining self hosted.

[Calimero]

If using a hosted zabbix platform would force you to evaluate your custom commands to remove command injection vulnerabilities, then it would actually be -better- for your security than remaining self hosted.

I wish my clients had the time and resources needed for an extended audit/fixing session.

But that's not how the real world works.