Split Zabbix Server Class into Components

[ben-albon]

The Zabbix Server class, as is currently defined in the wdijkerman-zabbix module, could actually be split into the 3 components:

• Zabbix Server
• Zabbix WebUI
• Zabbix DB

In order to scale zabbix effectively, it's best practice to run each of these components on separate nodes.

(for example, http://blog.zabbix.com/scalable-zabbix-lessons-on-hitting-9400-nvps/2615/)

As it stands, it does not seem possible to use the wdijkerman-zabbix module to install the zabbix server on one node, the WebUI on a second, and the Database on a third.

[dj-wasabi]

Hi ben-albon,

Yes, I noticed this when "Nekroze" opened "zabbix.conf.php.erb wrong zbx name #9 " issue. The plan was to solve this with the 1.0.0 release, as this is an major change in one of the most important classes. But there are some other changes that I would like with the 1.0.0 release, so it can take some time when this release comes to live... I think somewere in november, maybe december..

Don't know if this is an problem for you?

Kind regards,
Werner

[ben-albon]

I can see how removing the WebUI and DB features from the zabbix-server class would break backwards compatibility with existing implementations.
ATM I'm only using puppet on my personal infrastructure - so there's no pressure to get it fixed :-)

[dj-wasabi]

Hi,

I've been thinking about this split and this is the main "attraction" for the 1.0.0 release.

For now I have two ways getting forward.

1. Add them all 3 in the node configuration.
   When you have 1 node which does all three roles:

node 'zabbix.example.com {
  class { 'zabbix::web':
    zabbix_url => 'zabbix.example.com' 
  }
  class { 'zabbix::server':
    dbhost => 'server3',
  }
  class { 'zabbix::database':
    dbtype => 'postgresql',
  }
}

And when you have 2 or 3 hosts, you can split it really nice per host. But when you only have 1 host, it is extra configuration what has to be done (If compared with the setup in the current releases).

2. You can choose what you want to do.
   Using just one class like doing it now when you only have 1 host:

node 'zabbix.example.com {
  class { 'zabbix::server':
    zabbix_url => 'zabbix.example.com' 
  }
}

Or splitting it up when having multiple hosts:

node 'zabbix.example.com {
  class { 'zabbix::web':
    zabbix_url => 'zabbix.example.com',
    zabbix_server => 'zabbix-server.example.com',
  }
}
node 'zabbix-server.example.com {
  class { 'zabbix::server':
    dbhost => 'database.example.com',
    manage_vhost => false,
    manage_database => false
  }
}
node 'database.example.com {
  class { 'zabbix::database':
    dbtype => 'postgresql',
  }
}

In the end, it is all about if people are reading the documentation (and if the documentation is clear about this).

But for now, I don't know what path I should take on this.
@ben-albon As you have created this issue, what is your preference about this?
@lucas42 & @karolisc (as you 2 were really active the last few days 👍 ) what are your preferences?

Thanks!

Kind regards,
Werner

[lucas42]

My preferred approach would be number 1, but with the addition of an init.pp file which includes all three components (and any glue needed to make them work together).
This is roughly what puppetlabs' puppetdb module does: https://github.com/puppetlabs/puppetlabs-puppetdb/blob/master/manifests/init.pp

Ideally, if someone were to do:

node 'zabbix.example.com {
  class { 'zabbix':
    zabbix_url => 'zabbix.example.com' 
  }
}

they'd end up with a fully functioning zabbix box and not have to write any more puppet code themselves.
For people who want more control (like installing different bits on different machines, or using custom apache configuration), then they can use the zabbix::web, zabbix::server and zabbix::database classes directly.

[dj-wasabi]

HI Lucas42,

Thanks! That is the better way to solve this.
Unless I'm hearing (Or reading ;-)) something else, I'll go this way.

Kind regards,
Werner

[ben-albon]

sounds good, can't wait!

[dj-wasabi]

Don't want to get people to excited, but locally with vagrant (one or with 3 vm's) it is working. Works with both databases (Postgres or MySQL) 8-). Started with updating the documentation in the manifests file and when I have some time left this week I continue with the readme.md.

I do try to get the 1.0.0. release releases this year, but won't make any promises.

[dj-wasabi]

I just released v1.0.0.
I hope you enjoy it. :-)

[karolisc]

Hi Werner,

Nice work, but I would like it to be more structured.

It could have such classes:

    zabbix::server::server
    zabbix::server::web
    zabbix::server::database (pseudo)

same for proxy:

    zabbix::proxy::proxy
    zabbix::proxy:database  (pseudo)

Pseudo classes for all in one scenarios

   zabbix::server (){
     class { zabbix::server::server:
     }
     class { zabbix::server::web:
     }
     class { zabbix::server::database:
     }
   }

and

   zabbix::proxy (){
     class { zabbix::proxy::proxy:
     }
     class { zabbix::proxy:database:
     }
   }

Advanced setups would call real classes directly.
I think this way node manifest would be much more readable.

Karolis

[dj-wasabi]

HI Karolis,

Let me think about it. For now this setup is something I can live with.
So if I take this road, don't expect it the next month/release, as this take some time. :-)

I've created in my own personal jira an ticket for this.
As the original request is solved, I'll close this ticket.

Kind regards,
Werner