[chef] Re: Re: Re: Re: Re: How to tell when recipes fail?


Chronological Thread 
  • From: Gilles Devaux < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: How to tell when recipes fail?
  • Date: Tue, 16 Nov 2010 09:40:18 -0800
  • 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 :content-type:content-transfer-encoding; b=gAoCBtGx8Hw3n0zby2z5zzRpnalSBtGduATRoNQ2uzTBkLnwKDrWHPGoz9dCyGpKPb KT4xdRu1NsVFTkL11wmXEL65QydjXfrDeYGGX95q12LJ+HqPAILNpXMihVfd1vmdPz+r XK6RO8rs8tFKdJmfJnxOUfYb/COALDdX8Jrss=

Same here

On Mon, Nov 8, 2010 at 7: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.

§