I guess I'm not 100% on what I'm trying to do yet, nor am I sure it's a good idea or too complicated... Which is why I'm asking what other people do :-)
I already bypass exporting and realising resources for our Nagios service checks. This was a performance enhancement - we've got 10s of 1000s of Nagios checks per server, and realising all those resources into Ruby objects was really slow (this is back before PuppetServer). Instead we have a template making a PuppetDB API call, getting back a blob of JSON and parsing that into Nagios Service definitions. It is querying Defined Type resources from Puppet though so it's pretty easy to parse into Nagios: url4 = 'http://puppet:8081/pdb/query/v4/resources/Nagios::Config::Service' However that requires that we add a Nagios::Config::Service resource into a Puppet catalog somewhere in order to get a check. Some part of me thinks this is a bit wasteful... Here's a simple contrived example: if I was monitoring PuppetLabs Apache::Vhosts, I would have two resources in a catalog: apache::vhost { 'foo.com': } nagios::config::service { 'https_check_foo.com': } Why do I need the second resource if all the information I need is already in the first resource? Could I not just parse the PuppetDB data looking for Apache::Vhost resources directly? That would mean I wouldn't have to have a Profile of my own code to add my own monitoring resource. If I had something that could do that and generate Nagios config, perhaps it wouldn't be too hard to extend it to generate boilerplate Goss or ServerSpec config for acceptance testing, the same way Puppet Retrospec does for unit tests... The monitoring config would be somewhat decoupled from my Puppet runs, I could change the way checks are defined without a Puppet Agent catalog compilation needing to occur. There are two big disadvantages I can see. If the interface of Apache::Vhost changes, the generated monitoring breaks with it. The second is that any complicated monitoring that requires an extra package or script to be installed on a machine is going to be defined in Puppet anyway, so moving the check definitions out of Puppet in order to avoid wasteful code doesn't make much sense any more. I think I've just talked myself out of it :-) Thoughts? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3477c4b2-7607-4dfb-ad6a-c7f4af885877%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
