- From: Booker Bense <
- Subject: [chef] Re: Re: Re: CM/Chef API access for monitoring systems?
- Date: Wed, 26 Sep 2012 12:49:06 -0700
On Wed, Sep 26, 2012 at 10:38 AM, Ranjib Dey
> 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
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
Archive powered by MHonArc 2.6.16.