OOPS!  I forgot to include the list on my reply!

On 05/15/2013 12:03 AM, John Carpenter wrote:
> is the idea to piggyback on the possible already existing
> infrastructure to gain more insight about what the environment looks
> like or is it to avoid reinventing the wheel and not have to write a
> monitoring agent from scratch?
The idea is to allow people to avoid reinventing the wheel and not have
to write the agent from scratch - for a couple of reasons at least: (1)
less effort, hopefully fewer bugs (2) simpler to be able to convert
people to the AMP.
> also, do we put the links to their apis in the trello section called
> competitors, inside their existing card?
That's a great idea!  Go ahead and edit the description - don't put it
in a comment.

I'll do that with Dejan's comment.

>
>
> On Tue, May 14, 2013 at 6:52 PM, Alan Robertson <[email protected]
> <mailto:[email protected]>> wrote:
>
>     Hi,
>
>     I'm sure several of you know the APIs used by other systems for
>     monitoring.  Perhaps others want to investigate?
>
>     If you can point at documents that describe their APIs (a howto for
>     writing monitoring agents) that's the kind of thing I'm looking for.
>
>     Nagios is an obvious candidate - and there are at least two clones of
>     Nagios.
>
>     Others that come to mind are Zenoss, Zabbix, Pandora FMS, OpenNMS,
>     Xymon, HypericHQ, and so on...
>
>     The point of this is that if we understand these APIs, then we can
>     write
>     code to talk these APIs and then perhaps we can use many of the
>     resource
>     agents written for these various platforms.
>
>     It's best if we understand how to model their configurability.
>
>     For example, in the OCF RA APIs, there is an action called meta-data
>     which spits out an XML snippet describing how to configure them (what
>     parameters, etc).  It's not hard to write an OCF resource agent (in
>     spite of the XML), but it _is_ non-zero work to write and to debug
>     them.
>
>     For other systems, we might have to create something that provides the
>     metadata.  But that's still less work than writing the monitoring
>     agents
>     over.
>
>     If a resource agent only works if it's remote, then it's not very
>     interesting to us - which may limit us a lot...
>
>     Of course, if any given systems' monitoring agents are ALL written so
>     they have to run remotely, or require a lot of packages to be
>     installed,
>     then that system is likely uninteresting from a compatibility
>     standpoint.
>
>     --
>         Alan Robertson <[email protected]> - @OSSAlanR
>
>     "Openness is the foundation and preservative of friendship...  Let
>     me claim from you at all times your undisguised opinions." -
>     William Wilberforce
>     _______________________________________________
>     Assimilation mailing list - Discovery-Driven Monitoring
>     [email protected]
>     <mailto:[email protected]>
>     http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
>     http://assimmon.org/
>
>


-- 
    Alan Robertson <[email protected]> - @OSSAlanR

"Openness is the foundation and preservative of friendship...  Let me claim 
from you at all times your undisguised opinions." - William Wilberforce



_______________________________________________
Assimilation mailing list - Discovery-Driven Monitoring
[email protected]
http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation
http://assimmon.org/

Reply via email to