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

[Rob Guttman < >]

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
>
>