Am 29.05.2017 um 17:34 schrieb Rudy Gevaert:
Ofcourse it depends how much node specific information one wants to put
in $monitor::host::vars. Maybe this should be kept to generic things?
::vars could be a nice addition. Would require some hack in your Puppet
manifests (or a custom type/function combination), as I'd prefer to say
something like this...
monitor::host::var { 'location': value => 'Somewhere' }
...anywhere in my catalog. Just, it's a little bit tricky to create a
construct allowing you to then have all ::var properties available as a
Hash named "vars" on monitor::host. It's possible, just hacky - Puppet
has no "export/collect 'data'" mechanism.
...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.
Did you try to define an import source fetching apache::vhost? I'd then
create a sync rule creating single services from that source. When doing
so please follow the host!service convention when defining the "key"
column. I have no Puppet environment to play with at disposition right
now, so no practical example - sorry.
You could btw also introduce monitor::service following a similar logic.
That would...
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?
...also target these concerns I guess.
I hope I'm not overloading you with questions/remarks.
Well... when I stop answering I either started to prepare dinner for my
kids - or you managed it to overload me ;-)
Also, if I may, the director configuration (import+sync rules) can this
they stored in in Puppet?
No. Kickstarting Director with Puppet is easy, but Import/Sync/Jobs are
not accessible through the API or CLI right now. This will be tackled
sooner or later, goes back to a historic Icinga/Normal Object
distinction. Doesn't make much sense any more, but that's currently a
hard barrier when it goes to certain object capabilities.
A complete or partial DB-Dump and Puppet filling the DB with that dump
when empty usually makes a comfortable workaround for this.
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.
Makes sense to me. Just, your API is the DB right now for Import/Sync
definitions. In case you feel comfortable dealing with it that way,
there is nothing wrong with this approach. I know that a solution for
this would make quite some people happy, and sooner or later we'll have
a better solution here. It's more complicated that it might look at
first sight, as things usually do not stop with Import/Sync. Very soon
you'll then need Data Fields, Lists, Templates, Apply Rules. Not all of
those objects are very API-friendly. Some do not have unique names, like
Apply Rules. Fields with the same name but different properties are
perfectly valid, and so on. All those issues can be solved, it's just a
matter of time ;-)
Thanks in in advance for your time,
Rudy
You're welcome!
--
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
