On Feb 13, 6:45 am, Trevor Vaughan <peiriann...@gmail.com> wrote:
> Just out of curiosity, is there a problem with good old fashioned log
> monitoring and cron?
>
> I.e. logwatch -> email -> poke puppetmaster combined with cron to
> check if puppetmaster is still rolling along.
That is definitely an option and easier to implement. Though I do like
monitoring off server, via nagios in this case. Also looking at the
logs won't tell ya if some stupid change was made like blocking the
port via a firewall rule, or other network related problems. I look
at it from the angle checks should occur at the same level you need
the service to operate. Other checks like memory leaks I do consider
important if the daemon has a known issue otherwise overall memory and
swap usage monitoring should be enough.
>
> In the case of PHP, it makes sense to monitor the page, however the
> puppetmaster is a system daemon that should have things checking into
> it and should be regularly generating logs like "compiled manifest for
> blah.foo".
I could actually do via log files also, but choose to do it this way
for the same reasons above.
If you wanted to tie that into cacti, you could watch the
> heuristics graph and see if there is a drop in trending.
Yea I'm wondering out loud to the group what metrics should be graphed
with Puppetmaster. Maybe per time period (ie 5min)
- Avg time to store acatalog
- Avg time to compile a catalog
- amount of nodes connected
- Amount of modules
Maybe some other things related to the internals of puppetmaster
itself?
> Of course, this could also mean that your client networks all just
> blew up but, either way, you have a serious problem.
>
> Trevor
>
> On Thu, Feb 12, 2009 at 21:19, Larry Ludwig <larry...@gmail.com> wrote:
>
> > Yea I want to make sure puppetmaster returns some sort of valid
> > result. Though the monit for memory leaks is not a bad idea.
>
> > More than just pinging a port.
>
> > For example in our case we monitor PHP. We've had PHP crap out for a
> > few customers, so we monitor a phpinfo page to make sure php returns a
> > valid result.
>
> > I also mentioned to Luke about getting some metrics out of
> > puppetmaster at least via command line. I would LOVE to be able to
> > monitor it via Cacti to see how performance is going. Not sure what
> > the metrics would be, but something to help with when to scale to
> > bigger hardware. At least from the baseline graphs we do (CPU, disk
> > IO, memory, bandwidth) the Puppetmaster appears to be primarily CPU
> > bound first, memory second.
>
> > -L
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
