Hi List! I'm blown away by what I'm able to achieve with very little effort using Icinga Director. In an hour I wrote a script to pull out the wanted information from a REST API (Cisco Prime if you wanted to know) and store it in a table for use by Icinga Director.
What I am a bit stuck on is how to handle parents/relations to other hosts/services in a flexible manner, as it appears now I should have this already from "somewhere" other than Director and let it apply the information to Icinga. Are there DO's or DON'Ts in regards to the black magic one uses Director for? I have no difficulties using Director as a straight up import tool via a database but I'd like some feedback/thoughts on how to make sure that it doesn't "follow through" with a run/execution if it doesn't meet some criteria, maybe force query errors or similar in that regard? There might be cases where a job has ran but failed, emptying a table, which could be disastrous to the import/sync mechanism. Similarly if it stopped partway through, it could also spell disaster for whatever didn't sync after it stopped. I guess this is all down to how you write your scripts to feed tables/databases with information for Director to pull, maybe some guidelines/principles on this should be present so your monitoring doesn't blow up while you sleep or work through the surprise downtimewhen Icinga2 is suddently very empty. Some failsafe in Director would be a nice approach to this, unless you decide never to deploy automatically, just import, sync and see what changed before deploy. I would like to see some of the sources are auto-deployed while yet others are manual before being pushed to Icinga2. Inb4 some if not all of this is already answered somewhere but my googlefu is off. Regards, Rune Darrud
_______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
