[cacti-announce] Cacti 0.8.6j Released (fwd)

Wed Jan 24 21:10:24 UTC 2007

On 1/24/2007 3:05 PM, Paul Vixie wrote:

> glibly said, sir.  but i disasterously underestimated the amount of time
> and money it would take to build BIND9.  since i'm talking about a scalable
> pluggable portable F/L/OSS framework that would serve disparite interests
> and talk to devices that will never go to an snmp connectathon, i'm trying
> to set a realistic goal.  anyone who want to convince me that it can be done
> for less than what i'm saying will have to first show me their credentials,
> second convince david conrad and jerry scharf.  (after that, i'm all ears.)

Trying to do a comprehensive monolith will certainly make it a 5-year
process. It seems that such an effort is doomed from the start though (as
you say, who would fund it?) so I'm not really sure why it would be
offered up as the only available outcome.

Take a different approach, it wouldn't be that hard to develop the
framework alone. The killer for all these things is in the widgets that
hang off them, but if the framework was usable and the widgets were easy
to write (say, documented better than BIND9's API for example), the users
would take care of providing the widgets. Look at all the noobs writing
plugins for cacti and spamassassin and... users will write the plugins if
the framework is accessible.

Don't give me a package that tries to provide everything, give me a daemon
with inter-process messaging, event triggers, an extensible OO inheritance
model and I'll do my own damn widgets... It wouldn't take five years to
write that. It's a summer project.

Some of the things I want in an NMS that I can't find in end-all-be-all
monolithic packages:

  self-config stuff
    default polling cycle
    authentication
    data-storage interfaces
    etc.

  host/device information
    static info (hostname, etc)
    dynamic info (hardware inventory, software inventory, etc)
    browser interface
      MIB browser
      CIM browser
      others

  polling events
    ICMP
    SNMP GET
    WBEM
    script interface
    TCP connection interface
    etc.

  alarm events
    SNMP traps
    WBEM notifications
    syslog
    eventlog
    etc.

  action events
    alerts (mail, pager, whatever)
    run local script
    run remote script
    manipulate
    escalation interface
      event unanswered, chain to other event
      event cleared, chain to other event

  reporting
    browser meters (eg, watch this mib with realtime tachometer)
    long-term graphing
    trend analysis/reporting
    etc.

Really it comes down to having a framework in place that can be extended
by end-user admins. IOW it's the section heads, not the list items.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/