- From: Sean OMeara <
>
- To:
- Cc:
- Subject: [chef] Re: Re: Re: Re: Re: How to tell when recipes fail?
- Date: Mon, 8 Nov 2010 10:15:05 -0500
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IPaJcWLonx9GmDpHnOH9GacDe4jCGTlpp7+M3tsgo1Ew0oHsqsZOU6oQ/9nYi9XLET u1Vwiyf1A2SoHo4QlHh4YyyOxWJGuIX2XLlFkROjSzUmx3WsTKI5jAQSN9efgtrru2nl gmRPhzt00IRtX3X+9HXraNpqEt590MOqDxCa8=
I run chef-client from cron and check the exist status with $?
On Mon, Nov 8, 2010 at 10:01 AM, Rob Guttman
<
>
wrote:
>
I've taken a different approach to monitoring failed recipes. I use a
>
nagios passive check to monitor each chef-client's log file using LMF
>
(similar to swatch) for both failed and successful runs. By adding a
>
freshness threshold, it also doubles as a check that each chef-client is
>
still running (i.e., the check goes critical if it hasn't received a passive
>
check update within the chef client interval + splay + some buffer). Works
>
well so far.
>
>
- Rob
>
>
>
On Mon, Nov 8, 2010 at 1:36 AM, Daniel DeLeo
>
<
>
>
wrote:
>
>
>
> On Sun, Nov 7, 2010 at 9:25 PM, Mike Williams
>
> <
>
>
> wrote:
>
> > On 08/11/2010, at 15:49 , Daniel DeLeo wrote:
>
> >
>
> >>
>
> >> Also, I've been working on a handler paired with a simple sinatra app
>
> >> that stores run history in redis. It's still pretty early going, but
>
> >> you can find the source here:
>
> >> https://github.com/danielsdeleo/nom_nom_nom
>
> >
>
> > Nice one, thanks Daniel.
>
> >
>
> > Out of interest, why Redis, as opposed to CouchDB? I was thinking that
>
> > it might make sense to store the result of the last Chef run in the
>
> > existing
>
> > server data-store, along with everything else, so that (for example) you
>
> > could target failed nodes using "knife". Are you intentionally trying to
>
> > keep "node status" and "run history" separate?
>
>
>
> I wrote it on the side as a way to get some exposure to technology I
>
> find interesting but don't use day-to-day. My plan is to get some
>
> experience using/operating what I have so far and then re-evaluate the
>
> technology decisions.
>
>
>
> The app as it is allows you to fetch the list of only successful or
>
> failed nodes (it's part of how the data is modeled in redis) and the
>
> UI shows failed/success in the node list, so I'm not trying to keep
>
> them separate. But I did want to take the opportunity to design the UI
>
> (and the whole app, really) from first principles instead of trying to
>
> shoehorn it into what already exists so I can have a fresh perspective
>
> on the problem.
>
>
>
> Cheers,
>
>
>
> Dan DeLeo
>
>
>
> >
>
> > --
>
> > cheers,
>
> > Mike Williams
>
> >
>
> >
>
>
Archive powered by MHonArc 2.6.16.