On Mon, Oct 17, 2011 at 11:02 AM, Marcus, Allan B <al...@lanl.gov> wrote:
> All good ideas. > > Once issue I se with the 'have nagios run the puppet client' approach is > that we want to monitor puppet more closely than once per hour. I'd like to > come up with a intensive than a full puppet run, even if the run is > inventory only. > I'm a big fan of setting up a dedicated environment for monitoring. I usually put several file transfers into it with source parameter specified files resources and keep that list static. Then I monitor how long it takes for a client to retrieve and to apply the monitoring environment catalog. I used to run environments like this far more frequently than once an hour, as the load itself is small, but it's a reliable set of metrics for observing variation. > > I think we will monitor the MySQL server (runs on a different machine), > Apache port 80 on the puppetmaster machine, and a puppet run hourly. We will > also monitor disk, cpu, and IO on the server. All of those should give us a > good view. > > Thanks for your ideas. > > > > -- > Thanks, > > Allan Marcus > 505-667-5666 > al...@lanl.gov > > From: Chris Phillips <ch...@untrepid.com> > Reply-To: <puppet-users@googlegroups.com> > Date: Wed, 5 Oct 2011 06:13:53 +0100 > To: <puppet-users@googlegroups.com> > Subject: Re: [Puppet Users] AW: How best to monitor puppet? > > Our approach is to combine the monitoring and the execution. Totally ditch > the puppet client service and use nagios to run a "check_puppet" script > which does the puppet run and reports the exit codes. This also covers > things like having a defined retry interval, so if puppet runs and there are > no changes, it'll come back and run again in an hour, but if there are > changes, it will run in 10 minutes etc... works really well. > > On 5 October 2011 04:36, Scott Smith <sc...@ohlol.net> wrote: > >> It doesn't matter if puppetmasterd or puppetd are running and working if >> your clients are failing catalog runs. >> >> Send reports, write a check that alerts on N hosts with failed reports >> over X timeframe or something. >> >> >> On Tue, Oct 4, 2011 at 8:09 PM, Tim Connors <tim.w.conn...@gmail.com>wrote: >> >>> On Tue, 4 Oct 2011, Bernd Adamowicz wrote: >>> >>> > > -----Ursprüngliche Nachricht----- >>> > > Von: puppet-users@googlegroups.com [mailto:puppet- >>> > > us...@googlegroups.com] Im Auftrag von Marcus, Allan B >>> > > Gesendet: Dienstag, 4. Oktober 2011 15:47 >>> > > An: puppet-users@googlegroups.com >>> > > Betreff: [Puppet Users] How best to monitor puppet? >>> > > >>> > > We want to use Nagios to monitor out puppet server so we can be >>> > > notified >>> > > if it goes down. We are using Fusion Passenger and Apache on Red Hat. >>> > > >>> > > Any suggestion for what and how to monitor? >>> > >>> > We use the basic checks for any Unix machine along with special checks >>> for running Puppet master and client process where appropriate. A service >>> which uses NRPE and a check_procs call on the Puppet boxes like these two >>> examples works fine for us: >>> > >>> > Command[check_puppetmaster]=/usr/lib64/nagios/plugins/check_procs -w >>> 1:1 -c 1:1 -C puppetmasterd >>> > Command[check_puppetclient]=/usr/lib64/nagios/plugins/check_procs -w >>> 1:1 -c 1:1 -C puppet >>> > >>> > Bernd >>> > >>> >>> What about checking the logfile on the master to make sure that >>> everything >>> is checking in? Theoretically, the client daemons could be running and >>> accepting port 8140, but the daemon could be locked up: >>> >>> http://cafuego.net/2011/09/24/keeping-eye-puppet-updated >>> >>> >>> -- >>> Tim Connors >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Users" group. >>> To post to this group, send email to puppet-users@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. >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@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. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@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. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@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. > -- Nigel Kersten Product Manager, Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
