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

[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. That way, snmp with its traps, on demand request processing and extensible with custom min/scripts can suffice. Even NRPE can be configured to do the exact same thing , with only a single line in its configuration file. What we really need is better api's around them, and that is already captured in this thread. 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. This thread has already  highlighted the pain of not having any standard api around monitoring systems. Nagios still been easy to work with as it represent the entire configuration as raw text file, while sensu is even more easier as it can eat json.

just my 2 cents.

On Wed, Sep 26, 2012 at 10:53 PM, Brad Knowles < " target="_blank"> > wrote:

On Sep 26, 2012, at 7:14 AM, Booker Bense < "> > wrote:

> Let the fruit fly... But isn't this more or less what SNMP is supposed
> to do? (i.e. Standard Network Monitoring Protocol...)

SNMP could address part of the problem, if there are SNMP agents on all the nodes to be monitored, and if the monitoring system itself supports SNMP.  And of course, SNMP can actually be a pretty heavy weight protocol/service to support on either end, although there is much that it can do for you.

But with Chef we already have agents on each node to be monitored, and we already have a process of centralizing all the known information about a given node, and then putting that information into a central database that can be easily accessed and searched.  Is there no way to leverage this existing infrastructure for the benefit of the monitoring system?

Contrariwise, is there no way for Chef to be able to leverage the additional information that the monitoring system could provide, which can then also be centralized to be easily accessed and searched?  Or perhaps even an API to access that information live in near real-time?

> I think you have the right concept, though. One of the main reason
> "monitoring sucks" is that they are all vertically integrated. There
> is no way to "mix and match"
> pieces easily. There are no standard protocols for moving from one
> level to the next.

I don't have any answers.  But the discussion brought up certain questions in my mind, which I am interested in pursuing.

--
Brad Knowles < "> >
LinkedIn Profile: <http://tinyurl.com/y8kpxu>