On 6 July 2016 at 10:25, Thomas Gelf <thomas.g...@netways.de> wrote: > Hi Rune! > > Am 04.07.2016 um 22:49 schrieb Rune 'TheFlyingcorpse' Darrud: > > I'm blown away by what I'm able to achieve with very little effort using > > Icinga Director. > > Glad to hear that :-) > > > 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. > > Nice! This could be a candidate it for a nice add-on module. Did you > know that Import Sources are hook'able in Director? It's pretty easy, > have a look at the AWS module to see a similar example: > > https://github.com/Thomas-Gelf/icingaweb2-module-aws
I tried that as a first approach, copied what the PuppetDB module did to reuse for CiscoPrime, but I faced a few hurdles in this that I was unable to figure out in a limited timeframe. To prove that Director is right for us I went the script(to rest api)->sql table->director(sql import) approach which has worked out great for us as a proof of concept. > > > 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. > > Dependencies are not there yet, please see here for related feature/pull > requests: > > https://dev.icinga.org/issues/11332 > https://github.com/Icinga/icingaweb2-module-director/pull/14 > > It's no problem at all to keep apply rules for your dependencies in your > local config. Still, it's preferable to have those also deployed with > Director, even if he doesn't "understand" them yet. That's what the > "fileshipper" module has been made for: > > https://github.com/Thomas-Gelf/icingaweb2-module-fileshipper > > > Are there DO's or DON'Ts in regards to the black magic one uses Director > > for? > > Black magic: DO IT :D Seriously, just use it. Experimental features and > DON'Ts are either hidden pretty good or not even pushed to public GIT. > > > There might be cases where a job has ran but failed, emptying a table, > > which could be disastrous to the import/sync mechanism. > > Will not happen. Import is a all-or-nothing operation, and every import > run stores it's new data in a single transaction. Any exception during > the import will roll back the whole operation. > Excellent :) > > > Similarly if it stopped partway through, it could also spell disaster > > for whatever didn't sync after it stopped. > > In your case you opted for a custom DB placed in between Cisco Prime and > the Director. If that table is empty or missing a bunch of rows, > Director wouldn't know. You told him that this is your source of truth > and he will blindly trust it. Import would be triggered, and Director > would also happily accept an empty Import Run. Sync would then later on > purge all related hosts. > > There is no "please do not run if there are less than X objects" > feature. I'm also not sure whether this would be a good idea. It's the > responsibility of the Import Source to fail when something bad happens. > > > 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. > > Well, the preferred way is not to write custom scripts to fill > intermediary tables, but that's perfectly legal of course. You just > should take care that your script is doing so in an atomic way and that > it does nothing in case there is no/wrong/erroneous/missing data. > > The preferred way remains a custom Icinga Web 2 module providing an > Import Source. All you need to do is to provide at least a fetchData and > a listColumns method in a class extending the ImportSourceHook. And let > fetchData throw an Exception in case anything goes wrong. > > > 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. > > That's perfectly possible, Job definitions allow you to trigger actions > or to just check for changes. In case something went wrong and you > deployed an empty/half-baked configuration the first steps to recover > should be: > > * Go to your jobs, stop them. Either by stopping the service or by > disabling them in the web front-end > * Go to your deployment history, pick the latest correct one, click on > "Config" and "Re-deploy now" > > Your monitoring is now fine again and you can relax, grab a coffee and > try to figure out why there was an empty export from your CMDB. Fix it, > re-enable your jobs. > > Sure, in case Cisco Prime ships an empty host list on Friday evening > without throwing an error, you might still deploy an empty config and > not realize that you have been left with no active monitoring. You can > still decide to run "Sync Cisco Prime hosts" only during business hours, > timeperiods can be configured for every Job. You could also create two > distinct sync rules looking exactly the same, but only one of them with > the "Purge" flag enabled. And then run "Sync with purge" during office > hours and "Sync without purge" at night and on weekends. > > And if this is still not enough there is still our bug tracker: > > https://dev.icinga.org/projects/icingaweb2-module-director/issues > > Let me know your thoughts and dump your ideas into a feature request. > I'm struggling with the following test/concepts: 1. Host is supposed to be member of more than one host group, currently I am limited to one as the next property in the list overwrites the membership rather than adding the next group to it, at least as its an array with the object itself set to Merge, not Replace. 2. It is really based on the same problem as above, but as adding something to a hash key in the vars as a multi key, unless you propose a different approach, example #1. This is something I plan to get out from Puppet's facts to monitor my services based on the values inside the key. In a similar way I'll monitor what is inside IIS (WebSites/AppPools), Apache, Tomcat, HAProxy, etc... As a proof of concept I already use the values below in a test setup where I've filled it in manually to test how to use it with an auto-apply rule. 3. Auto apply rules, I see that it does not evaluate auto apply rules until restart officialy when modified via API, however when I tested it seems to do so, is it because of the "package" being evaulated as a whole? 4. Will it be possible in the future to create auto apply groups via director as well? I Have some inputs which could solve the problem initially described if it was possible and #3 is supported behaviour (re-evaluate auto apply rules on deploy). Example #1 ------ vars.windows_service["RpcSs"] = { name = "RpcSs" display_name = "Remote Procedure Call (RPC)" startup_type = "Automatic" category = "OS" } vars.windows_service["Schedule"] = { name = "Schedule" display_name = "Task Scheduler" startup_type = "Automatic" category = "OS" } vars.windows_service["NTDS"] = { name = "NTDS" display_name = "Active Directory Domain Services" startup_type = "Automatic" category = "Role" } ----- > > Cheers, > Thomas > > NB: In case you are interested in publishing a Cisco Prime addon and > need some help with it please let me know! > I will look into it if I get my head around some of the concepts used in Director instead of my dirty scripts, maybe a RackTables addon as well :-) Cheers, Rune > -- > 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 > > ** OSBConf 2016 - September - osbconf.org ** > ** OSMC 2016 - November - netways.de/osmc ** > _______________________________________________ > icinga-users mailing list > icinga-users@lists.icinga.org > https://lists.icinga.org/mailman/listinfo/icinga-users >
_______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
