RE: OT - RE: SNMP Freeware server

From: keith tokash (ktokash@hotmail.com)
Date: Tue Apr 22 2008 - 17:41:44 ART

Next message: Ryan Morris: "Re: Canadian CCIEs"
Previous message: Botha Michael: "RE: Static route pointing to an interface"
Maybe in reply to: keith tokash: "OT - RE: SNMP Freeware server"
Next in thread: Scott Morris: "RE: OT - RE: SNMP Freeware server"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

The problem he mentioned was 100 data sources *per graph*. Sorry, should have
been clear. We have a couple of instances where that would have required a
workaround. Overall I'd say the developer just got excited about building
something, so I encouraged the enthusiasm. The other idea was to separate the
different engines on to separate hardware to scale horizontally instead of
vertically - so polling things from one box and housing that DB there, then
you can have multiple instances of the graphing software daemon hit that DB
instead of each separate daemon hitting our routers (and CPUs). The goal is
for different business units to be able to deploy their own graphing servers
without increasing the polls on our boxes linearly. In five years we might
have 14 different units wanting their own graphs, and this is our ticket out
of maintaining those for them. :)

But to be honest I'm not a coder, so I have to kind of go along with whatever
the developer wants to do. If I dictate the solution he'll just tell me to
bugger off, or string me along and phone in the effort. I don't want to tell
him the solution, I want to tell him the requirements and have him tell *me*
the solution. That's not to say I won't push back, so now that I've explained
our efforts, if you know of a package out there that's pretty close I'll go
knock on his door.

With a few exceptions, secrecy is deeply incompatible with democracy and with
science.
--Carl Sagan

From: tvarriale@flamboyaninc.com
To: ktokash@hotmail.com; ccielab@groupstudy.com
Subject: RE: OT - RE: SNMP Freeware server
Date: Tue, 22 Apr 2008 14:15:58 -0500

If Cacti was only going to 100 data
sources, your consultants did not know wtf they were doing.

How big is your system? If its not
huge, there really isnt a reason to build something from scratch. You
could easily get away with modifying existing open source systems out there
and
meeting almost all your requirements.

Tony Varriale

Flamboyan, Inc.

630-546-7610

tvarriale@flamboyaninc.com

From: keith tokash
[mailto:ktokash@hotmail.com]

Sent: Tuesday, April 22, 2008 2:01
PM

To: Tony Varriale;
ccielab@groupstudy.com

Subject: OT - RE: SNMP Freeware
server

We're currently dealing with this
problem as well. In fact during a recent meeting with our Cisco peeps I
asked an old-school ISP guy what other large enterprises and ISPs are using
(we're actually content + some ISP for other business units) and he said
everyone pretty much rolls their own solution.

We used to use a consulting company that had some home-grown, Cacti-based
bandwidth graphs. They were snakes so we dumped them, but that still left
us needing a BW graph solution. Cacti didn't scale enough, something
about not being able to handle >100 data sources. To fix that and the
other crap our developer thought needed fixing would have taken so much
effort
that he just started making something home-grown. While he bangs away on
that we set up MRTG, which is quick and works, but sucks in its own way (like
having a 23,000 line config file ... no, I'm not exaggerating).

Hopefully our dev gets re-railed from the stuff he got de-railed to work on
and
finishes our long-term solution soon, because he was planning on open
sourcing
it, and we would be putting some really groovy features in there, like
dynamic
graph generation based on if.Alias tags - prepend "[ LAX1 TR L3 ]" to
your normal interface description and it would include that particular
interface in any graph you defined that used those tags (LAX1=data center
name,
TR=transit, L3=Level3, arbitrary number of tags, configurable values).
After that's working the sky's the limit really. Scan if.Alias nightly to
pull interfaces out after a neteng whacks the port description, add new ones,
move them around, all automagically. Build new graphs with a iTunes
"smart playlist" style interface - "All interfaces with TR and
LAX1, but not with L3". Really the only way I could think of moving
forward with a graphing system without guaranteeing the need for a full-time
geek sitting there fiddling with graph interface config files ... and still
making mistakes.

I'll cop to being proud of the idea. :) And this email constitutes
prior art from what I understand, so anyone can run with this, and not do the
patent troll crap where they jack everyone else trying to use it.

As for traps, we have Cisco LMS, but we're not 100% Cisco (and LMS could be
the
single most retarded software suite I've used in years) so we're probably
going
to throw a FBSD box up with OpenLMS to catch traps.

With a few exceptions, secrecy is deeply incompatible with democracy and with
science.

--Carl Sagan

> From: tvarriale@flamboyaninc.com

> To: ccielab@groupstudy.com

> Subject: RE: SNMP Freeware server

> Date: Fri, 18 Apr 2008 15:04:07 -0500

> I would recommend Cacti or Zenoss.

> Tony

> > > -----Original Message-----

> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On

> > Behalf Of

> > > Noor.Yousuf@shell.com