[chef] Re: Re: Re: CM/Chef API access for monitoring systems?

[Booker Bense < >]

On Wed, Sep 26, 2012 at 10:38 AM, Ranjib Dey 
<
 >
 wrote:
> chef agent is not really a on demand tool, its a daemon that periodically
> polls the chef server, when we say agent, we generally mean something that
> can cater to on demand requests. An mocllective/chef agent can act like one,
> for example.

Monitoring is really two distinctly different problems.

1. Record the state of the system

2. Alert on "failure"

The real problem is that you want a "bubble up" architecture that
allows aggreation and pushes data from local systems (i.e. ganglia, et
al )
for 1. and a completely different "top down" pull a service request for 2.



> In fact I 'll also add CI servers in the mix. I
> find it really difficult to plug the CI systems with rest of the tools. I
> want treat change as a common event , deployment, software upgrades,
> migration, backup everything to be treated as change and for me to model
> such generic notion of change I need chef api to be available as first class
> domain objects in a CI server , or the reverse.

I think doing "chef client API as first class object" would be
possible in Jenkins.

If we look at CI as fundamentally an action system based on "change of state",
I think you could easily use it to replace much of the current #2 use case of
monitoring. Both CI and alerting have essentially the same internal engine.

The more I look at Jenkins, the more I see "Personalized Alerting Dashboard".

- Booker C. Bense