I am trying to use the Voxpopuli Puppet Module to use Puppet (instead of the Director) to distribute and configure all the servers I have.
So far, setting up a master with a zone, a satellite with a second zone and agents work so far as the configurations are parsed to the agents (and master / satellite) and the command icinga2 daemon -C doesn’t throw any errors, it only shows warnings about service apply rules not matching, not all though.
If I dump the objects on the agents, they are listed (e.g. the host itself or services), so they don’t seem to be broken in general.
The correct files arrive on the servers and changes are distributed via puppet if they are made.
In the web interface though, I only see the master node with its working services.
There is no agent of any kind.
I have been looking for the issue now for a while and I don’t know where to look anymore for errors.
I assume that the agents don’t report back to the master very well (or aren’t queried).
There also aren’t any errors in the logfiles on the hosts, just the notification, that the api listener has started and is running etc.
I don’t know where to start looking for errors or fear that I might have grossly misunderstood some topic about how the communication between master and agents work.
If it’s useful, I can of course parse the master / agent / or satellite configs.
But I wanted to refrain from just spamming loads of config files since I don’t know where to look for errors yet.
Does the master have to be configured to know about all the hosts? How are they imported if one does not use the director?
I don’t know Voxpopuli, but I’d assume it takes care about distribution of all required Objects. At the end you’ll have several files which contains all object definitions and icinga reads those files during (re)start.
My first guess is, that the puppet module “only” does the setup, but does not create the actual monitoring configuration (“Host” objects for your hosts).
And, after reading your post completely, yes, icinga2 has to be configured separately to actual monitor stuff.
What you have right now is “infrastructure” configuration, who talks to whom and who is the boss.
This is not configuration about what to do and how to do it.
You do not need to use the director for creating configuration (it “only” creates icinga2 configuration itself), but you can the text based configuration in /etc/icinga2/zones.d.
In /etc/icinga2/conf.d should be some example configuration which you can use as inspiration.
Thank you very much for the replies, this clears up a lot of misceonceptions.
My original plan was to not use the director because of the hacy web interface, I would prefer to use the Webinterface just for the purpose of displaying data and do as much configuring as possible (e.g. data import) via puppet or in general cli tools and configurations via files.
Can I use the director module without all the web interface imports, if the configs are already on all the servers?
That would be the result I’d been looking for.
I just find the director to be very inflexible or for a better term hard to integrate with other configuration management tools.
There is no need to use the director or any of its modules, especially if you use puppet or any cli tools anyway. You just need to know where to store conf files and configure puppet and cli tools accordingly.