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 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. 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. Best, Thomas -- Thomas Gelf Principal Consultant NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg Tel: +49 911 92885-0 | Fax: +49 911 92885-77 CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461 http://www.netways.de | thomas.g...@netways.de ** OSMC 2017 - November - osmc.de ** ** OSBconf 2017 - September - osbconf.org ** _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
