From nickmbugus at gmail.com Mon Sep 6 15:06:47 2010 From: nickmbugus at gmail.com (Nick Wambugu) Date: Mon, 6 Sep 2010 16:06:47 +0300 Subject: [mrtg-developers] Aggregate switch mrtg Message-ID: I have installed and run mrtg on a 52 port switch which is running. Now i want to generate the aggregate for ports in use. How do I get the file to run to generate this. Thsnks -- "STRENGTH DON COME FROM PHYSICAL CAPACITY. COMES FROM AN INDOMITABLE WILL" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/mrtg-developers/attachments/20100906/9d651e08/attachment.htm From nickmbugus at gmail.com Mon Sep 6 15:50:45 2010 From: nickmbugus at gmail.com (nyugus) Date: Mon, 06 Sep 2010 13:50:45 +0000 Subject: [mrtg-developers] generate aggregate for a switch Message-ID: Have a 52 ports switch running mrtg, now i want to generate aggregate for the first 40 ports how does the code look like or how do I do it.. Thnx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/mrtg-developers/attachments/20100906/93a34fba/attachment.htm From s.shipway at auckland.ac.nz Tue Sep 7 01:01:46 2010 From: s.shipway at auckland.ac.nz (S Shipway) Date: Mon, 6 Sep 2010 16:01:46 -0700 (PDT) Subject: [mrtg-developers] Aggregate switch mrtg In-Reply-To: References: Message-ID: <28E447343A85354483BCF7C3E9D5EAA509C5F2C4@uxcn10-1.UoA.auckland.ac.nz> If all you are interested in is having a summary graph of the Incoming traffic, and another summary graph of the Outgoing traffic, then Routers2 does this automatically. You can put 'showtotal=yes' in your routers2.conf and the Incoming and Outgoing graphs will be generated with additional Total traffic lines. However if you want to do this by a subset of ports, or on a single graph, then you'll need to do more work. What you will need to do is to define a UserDefined summary graph over the ports that you are interested in. This summary graph can optionally include the separate lines for the ports, optionally stacked, with a Total line. I would suggest you suppress display of the numerical per-port data and per-port lines, and only include the total numbers and total lines, else it would be confusing - though you could use stack-mirror mode and include the per-port data. To generate this automatically from cfgmaker, you'll need to use interface templates and host templates. The Host template should define the display parameters for the summary graph; the interface tmeplate should add the interface to the summary graph (if it meets the criteria you specify). This will require a bit of Perl coding knowledge. Here is an EXAMPLE that needs a bit of work to complete. Host template: $target_lines .= < https://lists.oetiker.ch/cgi-bin/listinfo/mrtg-developers ________________________________ View message @ http://mrtg-mailinglists.795376.n2.nabble.com/Aggregate-switch-mrtg-tp5503082p5503082.html To start a new topic under MRTG Developers Mailinglist, email ml-node+795384-758908351-56796 at n2.nabble.com To unsubscribe from MRTG Developers Mailinglist, click here. -- View this message in context: http://mrtg-mailinglists.795376.n2.nabble.com/Aggregate-switch-mrtg-tp5503082p5504630.html Sent from the MRTG Developers Mailinglist mailing list archive at Nabble.com. From steve at steveshipway.org Wed Sep 15 00:51:58 2010 From: steve at steveshipway.org (Steve Shipway) Date: Wed, 15 Sep 2010 10:51:58 +1200 Subject: [mrtg-developers] Making MRTG work with rrdcached Message-ID: <000101cb545f$734b1d80$59e15880$@org> Is anyone currently working on making MRTG 2.16.x work correctly with rrdcached (RRDTool 1.4.x)? Currently (MRTG 2.16.4) it seems that slight changes are required to make it work with rrdcached in UNIX socket mode (and thresholding functionality is lost - due to no support for updatev in rrdcached), and it does not work at all with rrdcached in TCP socket mode (due primarily to having no support for rrdcreate and rrdinfo in rrdcached). If noone else is doing anything on this (I don't want to step on any toes) I'll try to get a patch submitted for MRTG to make support for UNIX mode smoother, and maybe also a patch for RRDs and rrdcached to allow a 'what functions are available' function call that can be used. This would be expected to return a restricted list of commands if we're using rrdcached in tcp mode. Steve _____ Steve Shipway steve at steveshipway.org Routers2.cgi web frontend for MRTG/RRD; NagEventLog Nagios agent for Windows Event Log monitoring; check_vmware plugin for VMWare monitoring in Nagios and MRTG; and other Open Source projects. Web: http://www.steveshipway.org/software P Please consider the environment before printing this e-mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/mrtg-developers/attachments/20100915/51c33358/attachment.htm From tobi at oetiker.ch Wed Sep 15 06:23:07 2010 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 15 Sep 2010 06:23:07 +0200 (CEST) Subject: [mrtg-developers] [rrd-developers] Making MRTG work with rrdcached In-Reply-To: <000101cb545f$734b1d80$59e15880$@org> References: <000101cb545f$734b1d80$59e15880$@org> Message-ID: Hi Steve, Today Steve Shipway wrote: > Is anyone currently working on making MRTG 2.16.x work correctly with > rrdcached (RRDTool 1.4.x)? > > > > Currently (MRTG 2.16.4) it seems that slight changes are required to make it > work with rrdcached in UNIX socket mode (and thresholding functionality is > lost - due to no support for updatev in rrdcached), and it does not work at > all with rrdcached in TCP socket mode (due primarily to having no support > for rrdcreate and rrdinfo in rrdcached). > > > > If noone else is doing anything on this (I don't want to step on any toes) I don't think anyone is working on this ... > I'll try to get a patch submitted for MRTG to make support for UNIX mode > smoother, and maybe also a patch for RRDs and rrdcached to allow a 'what > functions are available' function call that can be used. This would be > expected to return a restricted list of commands if we're using rrdcached in > tcp mode. sounds interesting ... there are ideas on how to make updatev work in rrdcached mode. It would require more of the functionality of rrdtool to happen in memory befor flushing data to disk. This should be possible but it would require some rather involved heart surgery. :-) cheers tobi > > > Steve > > > > _____ > > Steve Shipway > > steve at steveshipway.org > > Routers2.cgi web frontend for MRTG/RRD; NagEventLog Nagios agent for Windows > Event Log monitoring; check_vmware plugin for VMWare monitoring in Nagios > and MRTG; and other Open Source projects. > > Web: http://www.steveshipway.org/software > > P Please consider the environment before printing this e-mail > > > > > > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From s.shipway at auckland.ac.nz Wed Sep 15 06:58:28 2010 From: s.shipway at auckland.ac.nz (Steve Shipway) Date: Wed, 15 Sep 2010 04:58:28 +0000 Subject: [mrtg-developers] [rrd-developers] Making MRTG work with rrdcached In-Reply-To: References: <000101cb545f$734b1d80$59e15880$@org> Message-ID: <28E447343A85354483BCF7C3E9D5EAA50DC44942@uxcn10-3.UoA.auckland.ac.nz> > Steve said > > Is anyone currently working on making MRTG 2.16.x work correctly with > > rrdcached (RRDTool 1.4.x)? Tobi said > sounds interesting ... there are ideas on how to make updatev work > in rrdcached mode. It would require more of the functionality of > rrdtool to happen in memory before flushing data to disk. This > should be possible but it would require some rather involved heart > surgery. I couldn't wait, and started hacking :) I've submitted a small patch for MRTG that makes it rrdcached-aware, although for now it simply disables threshold checking and uses update rather than updatev. I've been hacking rrd_daemon.c to make it support INFO and LAST (done!) and I'm looking at making it support create. For INFO and LAST, I've used the time on the rrd file itself rather than in the queue, since any calls to GRAPH and FETCH will bypass the cache anyway. This also makes it much easier :). For CREATE, there's a bit more of an issue since we probably want to prevent absolute pathnames; however, noone would be stupid enough to run their rrdcached as root now, would they...? Maybe I should reject absolute paths if UID==0? Once these are done, I need to sort out the main functions to use rrdcached for these three, and finally get MRTG to recognise the features and use them. I've been shying away from the updatev function since, as Tobi says, it requires rather deep work to query the values still in the cache queue. For INFO and LAST, and possibly even GRAPH and FETCH, you could get away with ignoring the cache queue and just reading from the RRD file (call a FLUSH before your graph/fetch if it bothers you) but you can't really do this with updatev. I wonder if the rrdgraph command could be supported by returning the graph image as a huge base64-encoded blob? It would need to force a flush beforehand... (goes off to think) Steve Steve Shipway ITS Unix Services Design Lead University of Auckland, New Zealand Floor 1, 58 Symonds Street, Auckland Phone: +64 (0)9 3737599 ext 86487 DDI: +64 (0)9 924 6487 Mobile: +64 (0)21 753 189 Email: s.shipway at auckland.ac.nz ? Please consider the environment before printing this e-mail From tobi at oetiker.ch Wed Sep 15 09:51:01 2010 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 15 Sep 2010 09:51:01 +0200 (CEST) Subject: [mrtg-developers] [rrd-developers] Making MRTG work with rrdcached In-Reply-To: <28E447343A85354483BCF7C3E9D5EAA50DC44942@uxcn10-3.UoA.auckland.ac.nz> References: <000101cb545f$734b1d80$59e15880$@org> <28E447343A85354483BCF7C3E9D5EAA50DC44942@uxcn10-3.UoA.auckland.ac.nz> Message-ID: Hi Steve, Today Steve Shipway wrote: > > Steve said > > > Is anyone currently working on making MRTG 2.16.x work correctly with > > > rrdcached (RRDTool 1.4.x)? > > Tobi said > > sounds interesting ... there are ideas on how to make updatev work > > in rrdcached mode. It would require more of the functionality of > > rrdtool to happen in memory before flushing data to disk. This > > should be possible but it would require some rather involved heart > > surgery. > > I couldn't wait, and started hacking :) > > I've submitted a small patch for MRTG that makes it > rrdcached-aware, although for now it simply disables threshold > checking and uses update rather than updatev. > > I've been hacking rrd_daemon.c to make it support INFO and LAST > (done!) and I'm looking at making it support create. For INFO > and LAST, I've used the time on the rrd file itself rather than > in the queue, since any calls to GRAPH and FETCH will bypass the > cache anyway. This also makes it much easier :). For CREATE, > there's a bit more of an issue since we probably want to prevent > absolute pathnames; however, noone would be stupid enough to run > their rrdcached as root now, would they...? Maybe I should > reject absolute paths if UID==0? > > Once these are done, I need to sort out the main functions to use > rrdcached for these three, and finally get MRTG to recognise the > features and use them. > > I've been shying away from the updatev function since, as Tobi > says, it requires rather deep work to query the values still in > the cache queue. For INFO and LAST, and possibly even GRAPH and > FETCH, you could get away with ignoring the cache queue and just > reading from the RRD file (call a FLUSH before your graph/fetch > if it bothers you) but you can't really do this with updatev. > > I wonder if the rrdgraph command could be supported by returning > the graph image as a huge base64-encoded blob? It would need to > force a flush beforehand... (goes off to think) steve, note that rrdtool trunk supports remote graph commands (and fetch) there is a special syntax, so that you can include data from different remote locations into the same graph. cheers tobi > > Steve > > Steve Shipway > ITS Unix Services Design Lead > University of Auckland, New Zealand > Floor 1, 58 Symonds Street, Auckland > Phone: +64 (0)9 3737599 ext 86487 > DDI: +64 (0)9 924 6487 > Mobile: +64 (0)21 753 189 > Email: s.shipway at auckland.ac.nz > ? Please consider the environment before printing this e-mail > > > > _______________________________________________ > mrtg-developers mailing list > mrtg-developers at lists.oetiker.ch > https://lists.oetiker.ch/cgi-bin/listinfo/mrtg-developers > -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From steve at steveshipway.org Mon Sep 20 07:33:27 2010 From: steve at steveshipway.org (Steve Shipway) Date: Mon, 20 Sep 2010 17:33:27 +1200 Subject: [mrtg-developers] Question- opinions on MRTG support for rrdcached Message-ID: <001e01cb5885$5dacee20$1906ca60$@org> If MRTG runs via rrdcached (RRDTool 1.4) , then there's a decision to make on the RRD file checks. When it runs locally or via rrdcached with UNIX sockets, then the existence check is quick and simple, and the check for the rrd file having the correct max/type settings is relatively cheap. However when running via rrdcached with TCP sockets, you have the problem that to test for existence and parameters you need to do a remote rrdinfo, which is relatively expensive, particularly since it seems to happen for ever RRD file on every cycle. It could be changed to only attempt creation of the RRD file if the update fails, but this would mean that changes of MaxBytes/type wouldn't be actioned. The test for rrd Maxbytes/type should only be done once - on initial cfg file processing - but I'm not sure at the moment how to manage this. Would people prefer to omit the rrdtune step and do a create attempt only after a failed update (fast), or check the rrd file existence and configuration every cycle (slow but flexible)? Or maybe this should be a global option in the cfg file? As for Threshold checks, these have to be omitted if you're using rrdcached, as rrdcached does not yet support updatev. I've also not yet quite managed to get Routers2 to work via the rrdcached since the remote rrdfetch doesn't support -s, but we're close. Steve _____ Steve Shipway steve at steveshipway.org Routers2.cgi web frontend for MRTG/RRD; NagEventLog Nagios agent for Windows Event Log monitoring; check_vmware plugin for VMWare monitoring in Nagios and MRTG; and other Open Source projects. Web: http://www.steveshipway.org/software P Please consider the environment before printing this e-mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/mrtg-developers/attachments/20100920/64b0b8ff/attachment-0001.htm From tobi at oetiker.ch Mon Sep 20 07:57:39 2010 From: tobi at oetiker.ch (Tobias Oetiker) Date: Mon, 20 Sep 2010 07:57:39 +0200 (CEST) Subject: [mrtg-developers] Question- opinions on MRTG support for rrdcached In-Reply-To: <001e01cb5885$5dacee20$1906ca60$@org> References: <001e01cb5885$5dacee20$1906ca60$@org> Message-ID: Hi Steve, Today Steve Shipway wrote: [...] > However when running via rrdcached with TCP sockets, you have the problem > that to test for existence and parameters you need to do a remote rrdinfo, > which is relatively expensive, particularly since it seems to happen for > ever RRD file on every cycle. it should only happen at mrtg startup ... and since people who value their performance would run mrtg in deamon mode this should not be that much of a problem ... or is there a problem with daemon mode ? if so, that should probably get fixed ... cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From s.shipway at auckland.ac.nz Wed Sep 22 02:15:25 2010 From: s.shipway at auckland.ac.nz (Steve Shipway) Date: Wed, 22 Sep 2010 00:15:25 +0000 Subject: [mrtg-developers] More patches: Include and cfg file changes Message-ID: <28E447343A85354483BCF7C3E9D5EAA50DC7D249@uxcn10-1.UoA.auckland.ac.nz> I'm on a roll this week... :) More patches for MRTG in the pipeline - 1. Add wildcard support to the Include: directive. This is something I've wanted for years and been too lazy to submit the (small) patch required to make it work. Routers2 already supports this :P 2. In daemon mode, check for modifications to the cfg file, and if so, reload the configuration. I'm still testing this one because it is potentially difficult, as MRTG makes a few assumptions that this won't happen. I'm also using Tobi's trick of using -M rather than (time-stat()[9]) on the file age, and then $^T=time after the reload. 3. Identify RRD 1.4.999 or later, and use the new rrdcached functions I added in the RRDTool patch if running in rrdcached/TCP mode. This is the final hurdle to allow MRTG to run on a separate server from the RRDTool database, allowing a true distributed MRTG setup. Some additional code now in place to prevent re-testing of remote RRD files when in rrdcached/TCP mode (as the -M test can no longer be used, of course). Needs a bit more testing, though... I'll be submitting these to Tobi once I'm happy they're stable. In the meantime, I'd appreciate any feedback from the community. Steve ________________________________ Steve Shipway ITS Unix Services Design Lead University of Auckland, New Zealand Floor 1, 58 Symonds Street, Auckland Phone: +64 (0)9 3737599 ext 86487 DDI: +64 (0)9 924 6487 Mobile: +64 (0)21 753 189 Email: s.shipway at auckland.ac.nz P Please consider the environment before printing this e-mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/mrtg-developers/attachments/20100922/a438db38/attachment.htm From tobi at oetiker.ch Wed Sep 22 06:31:33 2010 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 22 Sep 2010 06:31:33 +0200 (CEST) Subject: [mrtg-developers] More patches: Include and cfg file changes In-Reply-To: <28E447343A85354483BCF7C3E9D5EAA50DC7D249@uxcn10-1.UoA.auckland.ac.nz> References: <28E447343A85354483BCF7C3E9D5EAA50DC7D249@uxcn10-1.UoA.auckland.ac.nz> Message-ID: Today Steve Shipway wrote: > I'm on a roll this week... :) > > More patches for MRTG in the pipeline - > > 1. Add wildcard support to the Include: directive. This > is something I've wanted for years and been too lazy to submit > the (small) patch required to make it work. Routers2 already > supports this :P > > 2. In daemon mode, check for modifications to the cfg file, > and if so, reload the configuration. I'm still testing this one > because it is potentially difficult, as MRTG makes a few > assumptions that this won't happen. I'm also using Tobi's trick > of using -M rather than (time-stat()[9]) on the file age, and > then $^T=time after the reload. > > 3. Identify RRD 1.4.999 or later, and use the new rrdcached > functions I added in the RRDTool patch if running in > rrdcached/TCP mode. This is the final hurdle to allow MRTG to > run on a separate server from the RRDTool database, allowing a > true distributed MRTG setup. Some additional code now in place > to prevent re-testing of remote RRD files when in rrdcached/TCP > mode (as the -M test can no longer be used, of course). Needs a > bit more testing, though... > > I'll be submitting these to Tobi once I'm happy they're stable. > In the meantime, I'd appreciate any feedback from the community. go steve go! tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900 From steve at steveshipway.org Thu Sep 23 04:26:06 2010 From: steve at steveshipway.org (Steve Shipway) Date: Thu, 23 Sep 2010 14:26:06 +1200 Subject: [mrtg-developers] Decentralised MRTG prototype working! Message-ID: <000001cb5ac6$b09154d0$11b3fe70$@org> I've successfully managed to set up a fully decentralised MRTG/RRD/Routers2 system, using rrdcached and the patched versions of RRDTool 1.4.999, MRTG 2.16.4 and Routers2 v2.22beta1. I've just done a successful test of the Routers2 frontend to view a remote RRD file which is being updated remotely for a third location. This has the RRD databases, MRTG daemon, and Routers2 web frontend all on separate servers, communicating via the rrdcached TCP protocol. The exciting part of this is that, when/if the MRTG and RRDTool patches make it into the release, it will be possible to expand an MRTG installation horizontally without having to use handover between multiple frontends; applications like Weathermap and SWFGauge will have all the RRD files located together; and there is at last a standard generic interface for remote RRD interaction. I'll be demoing this at LISA10, although to be honest to the user nothing looks different; all the changes are behind the scenes. At the moment, none of these patches are released; I've passed to Tobi a patch for MRTG to support rrdcached via unix-domain sockets, and a patch to rrdtool-trunk for full feature support but it will take time before they make it into the development snapshots and longer until they make it into the release. The changes to routers2 will be released in beta before LISA10 but v2.22 won't come out until there are sufficient changes and testing (maybe after MRG 2.16.5?) Anyone wanting to play with this for themselves please contact me and I'll give you a copy of the patched MRTG and RRDTool sources, plus routers2 v2.22beta1 Steve _____ Steve Shipway steve at steveshipway.org Routers2.cgi web frontend for MRTG/RRD; NagEventLog Nagios agent for Windows Event Log monitoring; check_vmware plugin for VMWare monitoring in Nagios and MRTG; and other Open Source projects. Web: http://www.steveshipway.org/software P Please consider the environment before printing this e-mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/mrtg-developers/attachments/20100923/280b2d83/attachment-0001.htm