Drill Down Facility in APAN

[Carroll, Jim P [Contractor]]

> Dear Sir,
> 
> I am writing to thank you for your letter and suggest you have your
> mailer wrap text at about 70 columns.

Interesting.  I've made no changes to Outlook.  I don't know why it's
not wrapping.  (I manually wrapped this, just in case.)

> I beg to disagree. Those frontends that are network box oriented, yes.

I'm not sure what you mean by this.  I'm trying to envision a useful
host which isn't networked, and am having some difficulty.

> AFAIK, others whose main purpose is graphing anything such as 
> Orca (and
> perhaps MRTG) can accept data from other inputs - usually the file
> system with data in a specific format. 

I know cacti can do this out of the box, too.  However, it's the local
filesystem.

If you mean running a program/script (such as check_nrpe or check_by_ssh)
to retrieve data remotely, I can see that.  The drawback is that we
would have Nagios collecting the data, and then RRD solution X collecting
the data again.  More network traffic, more CPU churn.  If that's the
only option, then that's the only option, albeit somewhat sub-
optimal.

> What Nagios data do you have in mind that an RRD front-end could
> leverage ?

serviceperf.log

> RRDs are simply a good choice to store time series (ts)  in. If
> you are collecting time series, storing it in RRDs will solve a few
> problems for you (graphing, light-weight fixed size storage and
> 'adequate' data access).

I'm not refuting the utility of RRDs at all.  And if there were a
delightfully painless implementation (as LARRD is to Big Brother),
I'd be all over it.  If there were an obvious solution, this would
become a FAQ, and not a topic of ongoing discussion.

> Since Nag doesn't at the moment collect ts data, the challenges are
> actually thinking about the role ts plays with Nag.
> 
> These may include, 
> 
> . considering having the plugins build with an option that causes them
> to write performace data RRDs

*blink*  Hey, great idea!  :)

> . as you say, ad-hoc custom checks of ts data collected by something
> else. Again, as you say, probably collected by an SNMP collector

See comments above.

> . having RRD add-ons or front-ends submit passive service 
> checks to Nag

Also an interesting idea.  I suppose one benefit to this would be that
we could centralize the warning/critical threshold definitions, which
historically hasn't been the way that NRPE operates.  (Yes, I'm aware
of the changes underfoot for NRPE.)

> I suggest that these problems are licked in SNMP v3, caveat lack of
> commercial implementations. Until then, ad-hoc solutions such as ACLs;
> don't run v2 or v1 in 'public' places'; be aware (and scared)  of the
> gaping holes - eg public SNMP community string brute force breakers -
> try them out on your boxes; keep up to date code etc etc.

$ snmpget -V
UCD-snmp version: 4.2.5

On keeping code up-to-date:

  apt-get for Red Hat:  http://freshrpms.net
  yum:  http://www.linux.duke.edu/projects/yum/

> I think Poul Henning-Kamp wrote some software (on the RRD page) that
> securely gets data from a remote RRD.

Yes... I remember seeing that last night.  But I was pretty beat and
wasn't thinking about all permutations.  I'll have to reconsider that.

jc

> Yours sincerely. 
> 
> -- 
> --------------------------------------------------------------
> ----------
> Stanley Hopcroft
> --------------------------------------------------------------
> ----------


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null