On Thursday, January 3, 2013 4:08:54 AM UTC-6, Luke Bigum wrote: > > > I'm taking shortcuts in my spare time with a tool that's probably 70% > right for the job. It's for monitoring - I really like the idea of a Puppet > module to describe or advertise how to monitor itself, it keeps them very > self contained. > > Just a bit more on this - I generally see three categories of monitoring > tools. Ones that are configured separately from your CRM and end up being a > source of truth on their own are in my mind the worst. The next level up > are ones either defined from or derived from your CRM. The best are > auto-discovery, but they cost an absolute fortune. I'm trying to move my > team from the first one to the second one with as little "new tools" as > possible, which is where the "70% right for the job" comment comes from. > > I'm using exported resources to describe how modules are monitored. The > problem is that exported resources are not the equivalent of raw > information passing. So when I want to start doing trickier things like > group and analyse what is collected, exported resources don't cut it > because it's not what they are designed for. > > Specifically what I was trying to do was collect exported resources of the > same type and group them on the monitoring server. There is no predefined > list of service names anywhere (unless you parse the node definitions) so > that's why I wanted to go from resource collection to Array of Strings. A > colleague has managed to reduce my 300 lines to 50 though so the need for > craziness is reduced somewhat. We still need to do the "Export a File" > trick and run a script on the monitoring server to build the complex > configuration that exported resources are not designed to handle. > > The next iteration of this work might be to scrap resource collection in > favour of querying PuppetDB directly to figure out what to monitor, but > that's a lot more work than I'm prepared to do at this stage. Maybe in a > few months... ;-) > >
Querying PuppetDB in fact sounds like a good approach. One alternative I see would be to extend the main Puppet engine. Possibly that could take the form of a new Puppet face (which, now that I think of it, might just end up a front end to the DB query). You could also inspect the master's catalog cache instead of hooking directly into compilation. That would give you all the information you want, without parse-order issues. You could monitor the cache directory for changes to make the system nearly as immediate as what you you're doing now. Or if you have a list of known systems to monitor, then you can generate catalogs for them at any time via the "puppet catalog" face. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/BbIJAdmSA7gJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
