(old post from few months ago)

So it was a while when posting something on the website, but I’ve achieved a new goal with my zabbix puppet module. I took some vacation days and the weather wasn’t that great, so I had some time to make this work. Offcourse this was not only thing I did in my vacation, I also had to watch some movies. 🙂 Guardians of the Galaxy! 🙂 anywayz…

As of release 0.4.0 it also make use of exported resources. Offcourse the puppet infra must be configured to work with exported resources.

Idea

The main idea of making this work was about 2 things:

1. Fully automated installation/configuration of monitoring environment
2. I wanted to focus on writing my own puppet type/provider.

Monitoring environment

Ideally, you want everything fully automated to be configured so you won’t forgot anything. In previous versions with this module, every zabbix component was installed en configured, but you still had to logon into the web interface and manually create the hosts and assign templates to it.

So this needs to be automated. Luckilly zabbix has an API which can be used for these kind of actions! Nice!

I found an excellent rubygem for saving a lot of headaches: zabbixapi. With this gem, I can easily create new hosts like this:

zbx = ZabbixApi.connect(
  :url => 'http://localhost/zabbix/api_jsonrpc.php',
  :user => 'Admin',
  :password => 'zabbix'
)

zbx.hosts.create(
  :host => host.fqdn,
  :interfaces => [
    {
      :type => 1,
      :main => 1,
      :ip => '10.0.0.1',
      :dns => 'server.example.org',
      :port => 10050,
      :useip => 0
    }
  ],
  :groups => [ :groupid => zbx.hostgroups.get_id(:name => "hostgroup") ]
)

First we create the connection to the api, by specifying the url, an valid user which has enough rights to create and edit hosts with the password.

When we have an valid connection, we create the host. When creating the host, it will put it into the “hostgroup” hostgroup and it will create 1 interface for the agent ( :type => 1). It will configure both ip as dns name, the port on which the agent is running and it will connect via dns ( :useip =>0).

So now we can create the hosts automatically in zabbix. We want to create hosts on 1 machine, the zabbix-server, so we have to make use of exported resources. Why do we want to do this on 1 machine? Not every host is able to connect to the zabbix-server, like when you use an zabbix-proxy on different (sub)net. Also you’ll have to install the zabbixapi gem on all servers with an admin like username/password on the clients. Could be an security issue. Also we want to make use of exported resources, they rock! 🙂

exported resources

With exported resources you are able to “send data” into an puppet database which other hosts can download and use it. Ideal for monitoring. We add an zabbix-agent to host a, this will send some data into the puppet database. On host b, the zabbix-server, the puppet run will and gather this data and do some actions with it.

Easier said than done, we have to create an specific type for this. We can’t use the “file” type, or “package” or even the “nagios_host”. We have to create our own type before we can use of exported resources.

Puppet type/provider

So I had to write my own puppet types en providers. I won’t go in details about this, but I’ll show you some basic code.

With the following, we are able to export resources into the puppet database:

@@zabbix_host { $hostname:
  ipaddress   => $ipaddress,
  use_ip      => $use_ip,
  port        => $port,
  group       => $group,
  templates   => $templates,
  proxy       => $proxy,
  zabbix_url  => '',
  zabbix_user => '',
  zabbix_pass => '',
}

It has some basic stuff, like hostname, ipaddress and port. But I also had 3 extra parameters which I could override on the zabbix-server. These are the zabbix_url, zabbix_user and zabbix_pass. The above will be executed on every zabbix agent which has the parameter “manage_resources” set on true.

When an puppet runs on the zabbix-server, we have the following that collects the data:

Zabbix_host <<| |>> {
  zabbix_url  => $zabbix_url,
  zabbix_user => $zabbix_user,
  zabbix_pass => $zabbix_pass,
}

This specific class (zabbix::resources::server) has 3 parameters and will be used for overriding the default empty parameters.

The provider will only do something when the “zabbix_url” has information, so we know that it will only run on the zabbix-server.

With the following components, we make use of exported resources:

• zabbix-agent
• zabbix-proxy
• zabbix-userparameters

With the zabbix-proxy, it will create the zabbix-proxy via the zabbix-api. When you use an proxy, you can set one of the parameters on the host which proxy it needs to be monitored by.

With the zabbix-userparameter you can install 1 or more specific userparameters into the host. Mostly this is done because an template needs these parameters. You can now specify the name of the template to which belongs to the userparameters you install.

Final note

So, exported resources gives the puppet module a lot of extra power to automate stuff. But when you have a lot of hosts, this will cause the runtime of the zabbix-server to increase a lot. For every host that exists, it will check via the zabbix-api if the host exists. If not, it will create it. But this takes time. Around 2 seconds for an host. So ..