Quoting Thomas Gelf <thomas.g...@netways.de>, Mon, 29 May 2017:
Am 29.05.2017 um 17:01 schrieb Rudy Gevaert:
If I understand you correctly you advise to specify which facts to
export. (Not export all of them).
Absolutely. Otherwise volatile facts like free memory and similar would
trigger imports again and again, generating too much noise. IMHO it
would have been better to separate metrics and non-volatile facts in
Puppet from the beginning, but now we have to deal with what is there.
So: yes, exporting only the facts you need is definitively the way to go.
I see with the monitor::host defined resource an elegant way to easily
export the facts one wants to export.
(I'm just thinking here, in the hope to get feedback and to inspire
other users too).
One could add monitor::host to some module that is on all nodes.
However one needs to easily be able to add extra values to specific
nodes (or groups of nodes). I think by putting extra information like
that in Hiera should be possible. Certainly with the extra hiera 5
lookup features, it could maybe work.
Ofcourse it depends how much node specific information one wants to
put in $monitor::host::vars. Maybe this should be kept to generic
things?
I like the idea to export all classes in a node and to define apply
rules based on that.
Well, your PuppetDB contains all classes and all resources - regardless
of whether they have been exported or not. And given that...
Can you advise how to collect all apache::vhosts e.g.?
...there is nothing wrong with defining multiple import sources, with
one of those fetching all apache::vhost definitions.
Could you share this, please. I got stuck on that.
If you are
experienced with Puppet you could also define:
Apache::Vhost <| |> -> Monitor::Host <| |>
And then use a custom function to pass a list of all vhosts as a named
parameter to your monitor::host.
I'm not sure if this is good on the long term. Would that mean for
every resource one would like to monitor one needs to add an extra
parameter. Which could lead to an explosion of parameters?
I hope I'm not overloading you with questions/remarks.
Also, if I may, the director configuration (import+sync rules) can
this they stored in in Puppet?
The GUI is nice and I hope our developers will use it to add extra
overrides or extra alerts. And that we can generate many checks
automatically with the director. However I'm feeling a bit
uncomfortable with managing the director config through the GUI. This
makes it error prone in trying in a test setup, and then needing to
redo the work in the production setup. Which could lead to inconstancy.
Thanks in in advance for your time,
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Rudy Gevaert e-mail: rudy.geva...@ugent.be
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
