[mrtg] Re: Feature Request

[Jozsa, Brandon]

Sorry, but welcome to UDP 101. I guess that beggars can't necessarily be
choosers. After all, if we got other machines to do ALL the work for us then
where would we work? I don't know about anybody else, but I will never FULLY
trust one machine to monitor another without some follow through. As the
good old expression goes...If you want things done right then do it
yourself. (I give a great deal of credit to those people have spent a lot
time and effort into this effort, and I for one am very appreciative).
Really now, we all using a FREE product. Which would you choose? If you want
some reliability go for Concord, which is what was used at the last
telecommunications firm that I worked for. But I will assure you that will
be paying for it! If there is one lesson to be learned it is that there is
nothing flawless in this world...including ourselves. Heck, it that weren't
the case then why would we even bother helping each other? We wouldn't need
help, right?


bbj

-----Original Message-----
From: Jeff Liebermann [mailto:jeffl at comix.santa-cruz.ca.us]
Sent: Monday, July 19, 1999 4:13 PM
To: mrtg at list.ee.ethz.ch
Subject: [mrtg] Re: Feature Request


Why is this beginning to sound like the ANSI C "Null Wars"?

> I dont think to graph 0 is the best way to do it, if you do it
> you are graphing something that is not real.

There are a variety of other options for graphing the lack
of data.  The most obvious one is no graphing at all or a
gap in the line.  IMHO, this would be ideal for the rotten
Ascend SNMP with the disappearing OID's.  However, the current
issue that I'm complaining about is that MRTG will graph
a bogus traffic value when there is no traffic.  This is just
plain wrong.  I've lived with it for quite a while, but
it just became a problem.

At this time, I can see several types of failures:
1.  Router is down but responding to SNMP (comastose IOS).
2.  Router fails to respond to SNMP queries (Ascend disappearing OID's).
3.  Heavy traffic or DOS attack causes SNMP responses to timeout.
4.  Polling server ceases MRTG polling or rateup fails to update data.

In all cases, the graphs will appear to show traffic where there
may or may not be any.   This is not good.


> From: Alex van den Bogaerdt <alex at slot.hollandcasino.nl>

> >alone, I really must read my mail. (are there still people using
> >that horrible ">/dev/null 2>&1" ?)

Yes.  It's manditory for the brain dead Ascend SNMP that has
the OID's disappear when the router goes offline.  As many
of my routers dial only on demand, this makes trapping the
error messages a necessity.  Since there is no return value,
MRTG graphs the last recorded value and results in a horizontal
line.

> >Tobi already responded and recommended to use rrdtool for these
> >kind of wishes.

I read his reply as a response to someone asking about rrdtool
for NT and not in reference to this issue.  The person asking
didn't bother changing the subject which may have caused some
confusion.

> >A quick workaround for you: Poll the device using an external script,
> >let the script handle any timeouts or other problems by returning
> >the values from the 1st line in the mrtg log (and the current time).
> >Warning: unchecked code. Just ment as a starting point:

Good idea.  Unfortunately about half my servers are NT without
MKS Toolbox or assorted GNU Unix tools installed.  The rest are
mostly SCO Unix OSR5 which is cursed with a broken getone (snmpget)
and getmany (snmpwalk).  I'll have to port the CMU SNMP tools to
make it play correctly.  I'll give the script a try and report the
results sometime this week.  However, I would prefer that someone
with Perl experience could point to where in the code I could hack
the results so that the lack of a data point will return a zero
or a blank instead of a bogus value.  Methinks that would be
easier than butchering some of my larger mrtg.cfg files.

Incidentally, the telecom tech sent my faxed MRTG graphs to his boss
who declared that everything was just fine because the MRTG graph
showed that there apparently was traffic.  Not only did he not believe
my story about the "anomaly" in the graphing, but he declared that
any monitoring tool that displays bogus traffic is useless.  

-- 
# Jeff Liebermann  Liebermann Design  150 Felker St #D  Santa Cruz  CA
95060
# 831.336.2558 voice  wb6ssy at ki6eh.#cca.ca.usa.noam  wb6ssy.ampr.org
44.4.18.10
# 831.421.6491 digital_pager    73557,2074  cis [don't]
# jeffl at comix.santa-cruz.ca.us  http://www.cruzio.com/~jeffl

--
* To unsubscribe from the mrtg mailing list, send a message with the
  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg

--
* To unsubscribe from the mrtg mailing list, send a message with the
  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg