On 27/09/10 22:27, Arvon Griffiths wrote:
> That being said, it sounds like the headaches involved in running it in 
> Daemon mode are greater than the performance gain.  Opinions?

        There's more to it than just choosing between daemon and cron
        modes.  Running multiple instances of MRTG partitions the
        target space so that the effect of non-responsive units is
        contained, as is that of restarts occasioned by the release
        of a new configuration file.  Choosing to do this has likely
        a bigger impact on how the configuration is managed than the
        daemon/cron choice has.

        I've set up a SysVInit script which finds all the MRTG config
        files in the standard configuration directory and starts an
        instance of MRTG for each one.  Every config file specifies
        daemon mode.

        We record traffic, wireless clients, DNS quality, DHCP leases,
        arp cache entries, server load and disk occupancy, router
        load and environmentals, and probably some other special stuff,
        using a mixture of classic SNMP and a variety of helper scripts.

        I've found it really convenient, when developing some new
        helper script, to have a dedicated instance of MRTG so that
        testing doesn't interfere with production data collection.
        Likewise, whenever we roll out or upgrade a cluster of
        networks, and partially commissioned equipment is in yo-yo
        mode for a while, isolation of the affected MRTG targets
        helps. I've never been minded subsequently to merge
        configurations and reduce the instance count.

        Our main network-monitoring MRTG boxes have 50+ instances
        collecting 10k+ target data series from 800+ units of network
        equipment (wireless APs, switches, routers).  Our DHCP servers
        each have a couple on instances: one for monitoring the leases,
        another for local server monitoring (CPU, disk, ...), and
        sometimes a third.

        Our navigation and display functions are based on HTML::Mason
        and support both RRDtool and classic modes of operation of
        MRTG.  This allowed instance-by-instance migration to RRDtool
        with seamless continuity of display.

        We got here because of where we were coming from, and probably
        would choose a different path if we were starting now from cold.
        It works for me.  Steve's approach is quite different, as he has
        explained.  It works for him, as far as I can see from the
        opposite side of the world.  8-)

        Your mileage may vary.
        I hope this is of some interest.


        Best regards
        Niall O'Reilly
        University College Dublin IT Services

_______________________________________________
mrtg mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg

Reply via email to