I've been thinking about this myself, and I've come up with a few possibilities.
1) Leverage the reports on the puppet master. This could be done with a daemon that watched /var/lib/puppet/reports, for instance. 2) Leverage the reports on the puppet clients. Each puppet run could ship the report of the previous puppet run off to nagios via a custom function. It would run behind, though, which is an issue. 3) Leverage Dashboard/Foreman. Both of those have APIs that can be queried to determine host status and get the errors from the report. 4) Leverage puppet's report subsystem: create another report (e.g. "nagios") and have it send Nagios the correct information. Of all the choice here, I like 4 the best, and it's what I'm planning on implementing when I've got a stock of round tuits. Basically, I'll get the report status and use send_nsca to send the results to Nagios. Alternatively, if the rest of the team insists that Nagios should do active polling, then I'll write a check that will query either Foreman or ask the DB directly (which ever is easier). 2010/11/15 Nicolas Szalay <nsza...@qualigaz.com> > Le jeudi 11 novembre 2010 à 06:09 -0800, Tim a écrit : > > Hi, > > Hello, > > > Anyway what other approaches are there? I'd like to simply see 2 > > things: > > 1) If there were any failures during the puppet run on the client > > 2) When the last puppet run on each client was (ie. if it was more > > than 50 mins ago raise a warning) > > I check point 2 with the help of mcollective and its puppetd agent. See > http://www.rottenbytes.info/?p=387 for more information. > > Regards, > > Nico. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
