Re: [mrtg] An awfully quiet list for the last 2 months ...

2016-09-28 Thread Tobias Oetiker
Hi Greg,

cool to see some work being done on mrtg ... I have recently moved
the source to github, so maybe you want to create a pull request
with your changes ...

  https://github.com/oetiker/mrtg

cheers
tobi

Montag Volk,Gregory B wrote:

>
> I have been working on modifying MRTG to send a copy of the time series data 
> it collects to
> Graphite (https://github.com/graphite-project) in addition to storing it in 
> RRD files. I am
> interested in doing this because I have a large, customized MRTG installation 
> that collects
> many metrics from many devices and it would be nice to work with that time 
> series data via
> one of the many Graphite front-ends such as Grafana 
> (https://github.com/grafana/grafana)
> without having to implement a whole new SNMP data collection system. With 
> this in mind I
> have modified mrtg 2.17.4 to use the Net::Graphite perl module
> (http://search.cpan.org/~slanning/Net-Graphite-0.14/) to open a TCP socket to 
> my Graphite
> server on startup and send a copy of each collected metric and the associated 
> timestamp to
> Graphite after the calls to RRDs::update.
>
> So far it works pretty well. The most difficult task was converting the 
> relevant MRTG
> config file directives (things like $$rcfg{'legendi'}{$router} and
> $$rcfg{'legendo'}{$router}) into meaningful graphite name space values. This 
> took some
> experimentation because periods are graphite namespace delimiters, and spaces 
> along with
> other special characters are not allowed in the graphite namespace at all. In 
> some cases I
> had to go back and modify my custom MRTG cfg builder scripts and MRTG 
> template files to not
> use periods and special characters.
>
> If anyone else is interested in trying it out you can download it from here:
> http://mrtg.gvolk.com/mrtg-graphite.zip.
> The zipfile contains these three files
> mrtg-2.17.4-graphitemrtg 2.17.4 with send-to-graphite modifications
> mrtg-diff.txt diff against stock mrtg 2.17.4
> README.txt  this readme file
>
>
> If you decide to try it out keep these things in mind...
> -I strongly suggest using a graphite docker image unless you already have a
> functioning graphite instance.
> -The same can be said for Grafana - use the docker image if you are looking 
> for a
> fancier Graphite front end.
> -You will need to modify line 92 of mrtg-2.17.4-graphite with your graphite 
> server
> name/ip unless you're running it on the same host as your mrtg poller.
> -Ideally the graphite variable assignments in lines 90 - 101 should be cfg 
> file
> parms but so far this is just experimentation and I haven't had time to work 
> on it
> beyond the proof of concept phase.
> -This only works in daemon mode so if your config files don't have 
> RunAsDaemon:Yes in
> them you're out of luck. Sorry.
> -Note that line 19 of mrtg-2.17.4-graphite has DEBUG=qw(log) specified. This 
> is
> useful for troubleshooting graphite TCP socket open problems and the
> MRTG-config-file-var-to-graphite-namespace conversions. This debug statement 
> will
> cause your MRTG log files to get big so I would recommend setting it to 
> DEBUG=qw()
> after things are working correctly.
> -So far I have only run this on linux. I don't know if it will work on 
> Windows or
> anything else.
> -You will need to install Net::Graphite from CPAN, so from your linux 
> prompt...
> perl -MCPAN -e shell
> install Net::Graphite
> -If the TCP socket from the MRTG server to the Graphite server goes away for 
> some
> reason (connectivity problems, graphite shutdown, etc) the MRTG daemon will 
> die.
> This is clearly a bad implementation on my part but I haven't had time to 
> look at
> it. Ideally MRTG will continue to run and update the RRD files if the Graphite
> socket goes away and gracefully reconnect when the Graphite server is 
> reachable
> again.
>
>
>
>
> If you are not the intended recipient of this message (including attachments) 
> or if you have received this message in error, immediately notify us and 
> delete it and any attachments.
>
> If you do not wish to receive any email messages from Edward Jones, excluding 
> administrative communications, please email this request to 
> opt-...@edwardjones.com from the email address you wish to unsubscribe.
>
> For important additional information related to this email, visit  
> http://www.edwardjones.com/disclosures/email.html. Edward D. Jones & Co., 
> L.P. d/b/a Edward Jones, 12555 Manchester Road, St. Louis, MO 63131 © Edward 
> Jones. All rights reserved.
>
>
> ___
> mrtg mailing list
> mrtg@lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch t...@oetiker.ch +41 62 775 9902
___
mrtg mailing list
mrtg@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg


Re: [mrtg] An awfully quiet list for the last 2 months ...

2016-09-26 Thread Volk,Gregory B

I have been working on modifying MRTG to send a copy of the time series data it 
collects to
Graphite (https://github.com/graphite-project) in addition to storing it in RRD 
files. I am
interested in doing this because I have a large, customized MRTG installation 
that collects
many metrics from many devices and it would be nice to work with that time 
series data via
one of the many Graphite front-ends such as Grafana 
(https://github.com/grafana/grafana)
without having to implement a whole new SNMP data collection system. With this 
in mind I
have modified mrtg 2.17.4 to use the Net::Graphite perl module
(http://search.cpan.org/~slanning/Net-Graphite-0.14/) to open a TCP socket to 
my Graphite
server on startup and send a copy of each collected metric and the associated 
timestamp to
Graphite after the calls to RRDs::update.

So far it works pretty well. The most difficult task was converting the 
relevant MRTG
config file directives (things like $$rcfg{'legendi'}{$router} and
$$rcfg{'legendo'}{$router}) into meaningful graphite name space values. This 
took some
experimentation because periods are graphite namespace delimiters, and spaces 
along with
other special characters are not allowed in the graphite namespace at all. In 
some cases I
had to go back and modify my custom MRTG cfg builder scripts and MRTG template 
files to not
use periods and special characters.

If anyone else is interested in trying it out you can download it from here:
http://mrtg.gvolk.com/mrtg-graphite.zip.
The zipfile contains these three files
mrtg-2.17.4-graphitemrtg 2.17.4 with send-to-graphite modifications
mrtg-diff.txt diff against stock mrtg 2.17.4
README.txt  this readme file


If you decide to try it out keep these things in mind...
-I strongly suggest using a graphite docker image unless you already have a
functioning graphite instance.
-The same can be said for Grafana - use the docker image if you are looking for 
a
fancier Graphite front end.
-You will need to modify line 92 of mrtg-2.17.4-graphite with your graphite 
server
name/ip unless you're running it on the same host as your mrtg poller.
-Ideally the graphite variable assignments in lines 90 - 101 should be cfg file
parms but so far this is just experimentation and I haven't had time to work on 
it
beyond the proof of concept phase.
-This only works in daemon mode so if your config files don't have 
RunAsDaemon:Yes in
them you're out of luck. Sorry.
-Note that line 19 of mrtg-2.17.4-graphite has DEBUG=qw(log) specified. This is
useful for troubleshooting graphite TCP socket open problems and the
MRTG-config-file-var-to-graphite-namespace conversions. This debug statement 
will
cause your MRTG log files to get big so I would recommend setting it to 
DEBUG=qw()
after things are working correctly.
-So far I have only run this on linux. I don't know if it will work on Windows 
or
anything else.
-You will need to install Net::Graphite from CPAN, so from your linux prompt...
perl -MCPAN -e shell
install Net::Graphite
-If the TCP socket from the MRTG server to the Graphite server goes away for 
some
reason (connectivity problems, graphite shutdown, etc) the MRTG daemon will die.
This is clearly a bad implementation on my part but I haven't had time to look 
at
it. Ideally MRTG will continue to run and update the RRD files if the Graphite
socket goes away and gracefully reconnect when the Graphite server is reachable
again.




If you are not the intended recipient of this message (including attachments) 
or if you have received this message in error, immediately notify us and delete 
it and any attachments.

If you do not wish to receive any email messages from Edward Jones, excluding 
administrative communications, please email this request to 
opt-...@edwardjones.com from the email address you wish to unsubscribe.

For important additional information related to this email, visit  
http://www.edwardjones.com/disclosures/email.html. Edward D. Jones & Co., L.P. 
d/b/a Edward Jones, 12555 Manchester Road, St. Louis, MO 63131 © Edward Jones. 
All rights reserved.


___
mrtg mailing list
mrtg@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg


[mrtg] An awfully quiet list for the last 2 months ...

2016-09-17 Thread James W. Laferriere

Hello All ,  Been An awfully quiet list for the last 2 months .
Went to the archive & yup no action showing there either .
	Was just getting worried that my several smtp failures may have caused 
my subscription to be paused .

Well back to my lurking again .
Twyl ,  JimL

--
+--+
| James   W.   Laferriere | SystemTechniques | Give me VMS |
| Network Engineer | 3237 Holden Road |  Give me Linux  |
| bab...@baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+--+

___
mrtg mailing list
mrtg@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/mrtg