[mrtg] RunAsDaemon vs. cron job

[Andrew Bowie]

Hi;
 
My thoughts follow with Ian but the difference I see between the Cron
and RunAsdaemon would be around the timings.
 
Cron setup does not rely on the scans completing before the next
starts.
RunAsDaemon will depend on the Perl script deciding that the right time
has passed for the next scan.
Now the Cron design also allows you to update the CFG files when every
you need and not interrupt the current timings.
 
Personally I prefer the Cron setup as it will also close the process
and therefore reduce the full load (should make very little difference
really).
 
Hope this helps.
 
Andrew
 
 
*****************************************
Andrew Bowie
Principal Computer Systems Officer
Public Trustee of Queensland
Ph 07 3213 9177
Mobile 042 302 8518
Fax 07 3213 9485
*****************************************


>>> "Brogden, Ian" <Ian.Brogden at COORS.COM> 20/02/2008 9:07 am >>>

You need to ensure each of the cfg files can be processed in under 5
minutes, even if some devices are down (this actually makes the
queries
take much longer, due to timeouts and retries).

I usually split my files to contain under 200 interfaces each, and
just
run multiple instances using runasdaemon, but it depends if you
frequently have multiple devices down.

Right now, I have about a dozen running, totalling somewhere around
1000
counters, on a 7 year old Dell Wintel server.

Ian Brogden
EDS - CTO @ MolsonCoors Account

( Mobile Phone:+1-303-961-1850
+ mailto:ian.brogden at eds.com

-----Original Message-----
From: mrtg-bounces at lists.oetiker.ch
[mailto:mrtg-bounces at lists.oetiker.ch] On Behalf Of Michael Silver
Sent: Tuesday, February 19, 2008 3:56 PM
To: mrtg at lists.oetiker.ch
Subject: [mrtg] RunAsDaemon vs. cron job

Hello,

Another newbie question...

I want to use MRTG to track traffic patterns on 51 devices, most
having
6 interfaces I want to monitor. That brings us up to ~612 queries (51
devices x 6 interfaces x 2 counters) assuming worst case scenarios.
The
machine running MRTG runs two other services - Nagios and Request
Tracker. The 15 min. load averages running those services plus
monitoring 3 of the above devices runs around 0.02 with 1 min. spikes
as
high as 0.50.

Given those loads, I don't think the server is going to have issues
with
the added snmp traffic. Still, I would like to set up MRTG to be
reasonable in terms of its resources. As I see it, I could divide my
devices into 5 groups, each with their own cfg file, so I can stagger
the mrtg load across 5 minutes using cron, or I could run one big cfg
file using RunAsDaemon. (I guess I could run one big file and cron,
but
I don't see the point in that.) 

Does anyone have any recommendations or experiences with this before I
shoot myself in the foot by not seeing the obvious? I gotta admit, I'm
leaning towards 5 groups and cron right now.

Thanks for any pointers or advice.

Michael

Michael Silver, Network Administrator
Parkland Regional Library
5404 56 Avenue Lacombe, AB T4L 1G1 
Phone: 403.782.3850    Fax: 403.782.4650
http://www.prl.ab.ca/  msilver at prl.ab.ca


_______________________________________________
mrtg mailing list
mrtg at lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg


_______________________________________________
mrtg mailing list
mrtg at lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg

****************************************************************************
This correspondence is for the named person's use only. It may
contain confidential or legally privileged information or both. No 
confidentiality or privilege is waived or lost by any mistransmission. 
If you receive this correspondence in error, please immediately
delete it from your system and notify the sender. You must not 
disclose copy or rely on any part of this correspondence if you
are not the intended recipient. Any opinions expressed in this 
message are those of the individual sender, except where the 
sender expressly, and with authority, states them to be the 
opinions of the Public Trustee of Queensland.
****************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/mrtg/attachments/20080226/a5055a4b/attachment-0001.html