RE: OT - RE: SNMP Freeware server

From: Scott Morris (smorris@ipexpert.com)
Date: Tue Apr 22 2008 - 18:30:11 ART

Next message: Net Plus: "FW: Passed the CCIE in San Jose"
Previous message: Leo Leung: "Re: IP Accounting on Doc CD"
Maybe in reply to: keith tokash: "OT - RE: SNMP Freeware server"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Now, I really hate to interject (actually I hate network management, but
it's a necessary evil)... But the important thing that is leaping out at me
right now is your stataement of "100 data sources *per graph*". Who the
hell reads a graph like that???

My big concern would be trying to build something that became so mired in
detail that it became unusable in any efficient matter.

Just my two cents.... :)

Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE-M
#153, JNCIS-ER, CISSP, et al.
CCSI/JNCI-M/JNCI-ER
VP - Technical Training - IPexpert, Inc.
IPexpert Sr. Technical Instructor

smorris@ipexpert.com

Telephone: +1.810.326.1444
Fax: +1.810.454.0130
http://www.ipexpert.com

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
keith tokash
Sent: Tuesday, April 22, 2008 4:42 PM
To: tvarriale@flamboyaninc.com; ccielab@groupstudy.com
Subject: RE: OT - RE: SNMP Freeware server

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