From will at facetofacedigital.com Wed Oct 2 08:25:37 2013 From: will at facetofacedigital.com (Will Brocklebank) Date: Wed, 2 Oct 2013 07:25:37 +0100 Subject: [smokeping-users] Bump! Anyone able to give guidance on this? Message-ID: If anyone can help me get over the hump on this I'd be very grateful? If I can just get this finished then I can set out an easy-to-follow list of steps for other new SmokePing users and submit it here and on my blog for everyone's benefit. Thanks again ---------- Forwarded message ---------- From: *Will Brocklebank* Date: Monday, 30 September 2013 Subject: Permissions or something else? To: "smokeping-users at lists.oetiker.ch" Hi all Over the weekend I wanted to build up my entire Smokeping installation again on a fresh SD install of Raspbian because the first time there was much trial and error and I didn't wholly understand the process. So this time I thought I'd do it methodically and keep track of my moves. But it's gone wrong! Now I keep getting: ERROR: opening '/var/lib/smokeping/mysite1/myhost2.rrd': No such file or directory /var/cache/smokeping/images/mysite1/myhost2_last_10800.png I know that some posts have put this down to a permissions error but I can't seem to solve it using the instructions that follow. Could someone give me baby-steps on how to check the permissions of the various directories, processes and files that need to be right? I realise I should use suexec (perhaps it would solve this issue??) but I can't find instructions that seem to work to set this up either... For clarity my steps so far, have been: 1. Format SD card of at least 8GB with SDFormatter 2. Copy to SD card the latest NOOBS software 3. Insert SD card into Pi and power on. Follow GUI to install Raspbian 4. Change main password 5. On Advanced Options page enable SSH 6. SSH to Pi 7. Run sudo apt-get update 8. Then sudo apt-get upgrade 9. sudo reboot 10. Then login again and become root sudo su 11. Install Apache2 and FastCGI by following instructions from here: http://raspberryserver.blogspot.co.uk/ 12. Begin installing SmokePing from http://oss.oetiker.ch/smokeping/doc/smokeping_install.en.html 13. - this will include sudo apt-get install rrdtool etc (follow the list) 14. Install CPAN by using this command: cpan App::cpanminus 15. You may need to run cpanm install CPAN and then cpanm reload CPAN to make sure you have the most up to date version 16. Install the PERL modules using this command: sudo cpanm from the SmokePing list 17. When you have installed all the PERL modules and have got to the installation section on the Smokeping page use apt-get install smokeping to actually put the package in place 18. move to the /etc/smokeping/config.d 19. Edit the Target file using this page of examples to help http://oss.oetiker.ch/smokeping/doc/smokeping_examples.en.html 20. [At this stage I was getting ERROR: /etc/smokeping/config.d/pathnames, line 1: File '/usr/sbin/sendmail' does not exist] so I had to run apt-get install sendmail 21. Install sudo apt-get install apache2-suexec-custom 22??.. how best to configure suexec????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131002/e031408d/attachment.htm From will at facetofacedigital.com Wed Oct 2 19:34:54 2013 From: will at facetofacedigital.com (Will Brocklebank) Date: Wed, 2 Oct 2013 18:34:54 +0100 Subject: [smokeping-users] Bump! Anyone able to give guidance on this? Message-ID: If anyone can help me get over the hump on this I'd be very grateful? If I can just get this finished then I can set out an easy-to-follow list of steps for other new SmokePing users and submit it here and on my blog for everyone's benefit. Thanks again ---------- Forwarded message ---------- From: *Will Brocklebank* Date: Monday, 30 September 2013 Subject: Permissions or something else? To: "smokeping-users at lists.oetiker.ch" Hi all Over the weekend I wanted to build up my entire Smokeping installation again on a fresh SD install of Raspbian because the first time there was much trial and error and I didn't wholly understand the process. So this time I thought I'd do it methodically and keep track of my moves. But it's gone wrong! Now I keep getting: ERROR: opening '/var/lib/smokeping/mysite1/myhost2.rrd': No such file or directory /var/cache/smokeping/images/mysite1/myhost2_last_10800.png I know that some posts have put this down to a permissions error but I can't seem to solve it using the instructions that follow. Could someone give me baby-steps on how to check the permissions of the various directories, processes and files that need to be right? I realise I should use suexec (perhaps it would solve this issue??) but I can't find instructions that seem to work to set this up either... For clarity my steps so far, have been: 1. Format SD card of at least 8GB with SDFormatter 2. Copy to SD card the latest NOOBS software 3. Insert SD card into Pi and power on. Follow GUI to install Raspbian 4. Change main password 5. On Advanced Options page enable SSH 6. SSH to Pi 7. Run sudo apt-get update 8. Then sudo apt-get upgrade 9. sudo reboot 10. Then login again and become root sudo su 11. Install Apache2 and FastCGI by following instructions from here: http://raspberryserver.blogspot.co.uk/ 12. Begin installing SmokePing from http://oss.oetiker.ch/smokeping/doc/smokeping_install.en.html 13. - this will include sudo apt-get install rrdtool etc (follow the list) 14. Install CPAN by using this command: cpan App::cpanminus 15. You may need to run cpanm install CPAN and then cpanm reload CPAN to make sure you have the most up to date version 16. Install the PERL modules using this command: sudo cpanm from the SmokePing list 17. When you have installed all the PERL modules and have got to the installation section on the Smokeping page use apt-get install smokeping to actually put the package in place 18. move to the /etc/smokeping/config.d 19. Edit the Target file using this page of examples to help http://oss.oetiker.ch/smokeping/doc/smokeping_examples.en.html 20. [At this stage I was getting ERROR: /etc/smokeping/config.d/pathnames, line 1: File '/usr/sbin/sendmail' does not exist] so I had to run apt-get install sendmail 21. Install sudo apt-get install apache2-suexec-custom 22??.. how best to configure suexec????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131002/6cdc2b40/attachment.htm From makeconfig at gmail.com Fri Oct 4 15:02:18 2013 From: makeconfig at gmail.com (Andrew Anderson) Date: Fri, 4 Oct 2013 16:02:18 +0300 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host Message-ID: Hello, Does anybody knows how exactly master <-> slave model works ? I have such master host configuration: ... *** Slaves *** secrets=/usr/local/etc/smokeping/secrets.txt + slave_host display_name=slave_host color=00ff00 *** Targets *** probe = FPing + LocalTest menu = LocalTest title = LocalTest host = 1.1.1.1 + RemoteTest slaves = slave_host menu = RemoteTest title = RemoteTest host = 2.2.2.2 ... Why RemoteTest testing runs on master host ? The master host is unable to reach 2.2.2.2 but the slave host is can. The master host is trying to reach 2.2.2.2, what I can see in debug-mode on master host: FPing: Executing /usr/local/sbin/fping -C 20 -q -B1 -r1 -b1000 -i10 2.2.2.2 FPing: Got fping output: '2.2.2.2 : - - - - - - - - - - - - - - - - - - - -' And the slave host is trying too: FPing: Executing /usr/local/sbin/fping -C 20 -q -B1 -r1 -b1000 -i10 2.2.2.2 FPing: Got fping output: '2.2.2.2 : 6.59 4.71 5.77 4.61 4.37 4.04 5.93 6.05 3.59 4.68 6.20 4.38 5.03 4.25 3.73 6.33 5.83 3.87 3.58 4.18' Sent data to Server. Server said OK And it looks like everything is fine, but the graphs on the master host is blank ... Is there any way to debug recieving of data on master host ? From tonyd at commspeed.net Fri Oct 4 15:35:23 2013 From: tonyd at commspeed.net (Tony DeMatteis) Date: Fri, 04 Oct 2013 06:35:23 -0700 Subject: [smokeping-users] Graph but no results In-Reply-To: <524DB860.1010408@commspeed.net> References: <524DB860.1010408@commspeed.net> Message-ID: <524EC41B.8080607@commspeed.net> Hello, Maybe someone could provide me with some assistance. I have a host/Target graph that get's created and populates the web page. However, no results appear on the graph. I am using the TelnetIOSPing probe. I have a number of other hosts/Targets that are using this probe. I have kicked out some debug results from /usr/share/perl5/Smokeping/probes/TelnetIOSPing.pm and the host is reachable and I see ping results, but they don't make it into the graph. In addition, no errors related to said host, are showing in the smokeping.log. Any ideas? Thank you! open(OUTF,">>/tmp/TelnetIOSPing.debug") || die "Can't open OUTF: $!"; print OUTF "target => $dest\nsource => $source\nuser => $login\n"; my $ok = $telnet->open(Host => $source, Port => $port); print OUTF "\n"; print OUTF "===========================\n"; print OUTF "Connection to $source $ok\n"; print OUTF "\n"; #---- Code that does the log in and executes extended ping $telnet->prompt('/[\@\w\-\.]+[>#][ ]*$/'); @output = $telnet->cmd("n"); #$telnet->waitfor('/[\@\w\-\.]+[>#][ ]*$/'); $telnet->print("quit"); $telnet->close; print OUTF "closed Telnet connection\n"; my @times = (); while (@output) { my $outputline = shift @output; chomp($outputline); print OUTF "$outputline\n"; $outputline =~ /^Reply to request \d+ \((\d+) ms\)/ && push(@times,$1); print OUTF "$outputline => $1\n"; } <<< I see data in graph from this Target >>> +++ pvdc_to_mesa_rtr menu = Core to eSedo MESA RTR title = Core Router to eSedo MESA RTR probe = TelnetIOSPing host = source = =========================== Connection to 1 closed Telnet connection Type escape sequence to abort. Type escape sequence to abort. => Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => Reply to request 0 (1 ms) Reply to request 0 (1 ms) => 1 Reply to request 1 (4 ms) Reply to request 1 (4 ms) => 4 Reply to request 2 (1 ms) Reply to request 2 (1 ms) => 1 Reply to request 3 (1 ms) Reply to request 3 (1 ms) => 1 Reply to request 4 (1 ms) Reply to request 4 (1 ms) => 1 Reply to request 5 (1 ms) Reply to request 5 (1 ms) => 1 Reply to request 6 (1 ms) Reply to request 6 (1 ms) => 1 Reply to request 7 (1 ms) Reply to request 7 (1 ms) => 1 Reply to request 8 (4 ms) Reply to request 8 (4 ms) => 4 Reply to request 9 (1 ms) Reply to request 9 (1 ms) => 1 Reply to request 10 (1 ms) Reply to request 10 (1 ms) => 1 Reply to request 11 (1 ms) Reply to request 11 (1 ms) => 1 Reply to request 12 (1 ms) Reply to request 12 (1 ms) => 1 Reply to request 13 (1 ms) Reply to request 13 (1 ms) => 1 Reply to request 14 (1 ms) Reply to request 14 (1 ms) => 1 Reply to request 15 (1 ms) Reply to request 15 (1 ms) => 1 Reply to request 16 (1 ms) Reply to request 16 (1 ms) => 1 Reply to request 17 (1 ms) Reply to request 17 (1 ms) => 1 Reply to request 18 (1 ms) Reply to request 18 (1 ms) => 1 Reply to request 19 (4 ms) Reply to request 19 (4 ms) => 4 Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms => 4 target => source => user => smokeping <<< I DO NOT see data in graph from this Target >>> +++ esedo_to_mesa_rtr menu = esedo Core to eSedo MESA title = eSedo Core Router to eSedo MESA RTR probe = TelnetIOSPing host = source = =========================== Connection to 1 closed Telnet connection Type escape sequence to abort. Type escape sequence to abort. => Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => Reply to request 0 (60 ms) Reply to request 0 (60 ms) => 60 Reply to request 1 (52 ms) Reply to request 1 (52 ms) => 52 Reply to request 2 (24 ms) Reply to request 2 (24 ms) => 24 Reply to request 3 (64 ms) Reply to request 3 (64 ms) => 64 Reply to request 4 (56 ms) Reply to request 4 (56 ms) => 56 Reply to request 5 (40 ms) Reply to request 5 (40 ms) => 40 Reply to request 6 (44 ms) Reply to request 6 (44 ms) => 44 Reply to request 7 (60 ms) Reply to request 7 (60 ms) => 60 Reply to request 8 (40 ms) Reply to request 8 (40 ms) => 40 Reply to request 9 (36 ms) Reply to request 9 (36 ms) => 36 Reply to request 10 (20 ms) Reply to request 10 (20 ms) => 20 Reply to request 11 (20 ms) Reply to request 11 (20 ms) => 20 Reply to request 12 (28 ms) Reply to request 12 (28 ms) => 28 Reply to request 13 (28 ms) Reply to request 13 (28 ms) => 28 Reply to request 14 (36 ms) Reply to request 14 (36 ms) => 36 Reply to request 15 (20 ms) Reply to request 15 (20 ms) => 20 Reply to request 16 (20 ms) Reply to request 16 (20 ms) => 20 Reply to request 17 (8 ms) Reply to request 17 (8 ms) => 8 Reply to request 18 (20 ms) Reply to request 18 (20 ms) => 20 Reply to request 19 (44 ms) Reply to request 19 (44 ms) => 44 Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 ms Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 ms => 44 target => source => user => smokeping From paul.mansfield+smokeping at grapeshot.co.uk Fri Oct 4 15:42:35 2013 From: paul.mansfield+smokeping at grapeshot.co.uk (Paul Mansfield) Date: Fri, 4 Oct 2013 14:42:35 +0100 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: References: Message-ID: the slaves submit date to the master using http. From tonyd at commspeed.net Fri Oct 4 16:12:16 2013 From: tonyd at commspeed.net (Tony DeMatteis) Date: Fri, 04 Oct 2013 07:12:16 -0700 Subject: [smokeping-users] Graph but no results In-Reply-To: <524EC41B.8080607@commspeed.net> References: <524DB860.1010408@commspeed.net> <524EC41B.8080607@commspeed.net> Message-ID: <524ECCC0.6010303@commspeed.net> I meant to include my Probe definition. +TelnetIOSPing forks = 5 offset = 50% packetsize = 56 step = 300 timeout = 10 iospass = iosuser = smokeping pings = 20 > Hello, > > Maybe someone could provide me with some assistance. I have a > host/Target graph that get's created and populates the web page. > However, no results appear on the graph. I am using the TelnetIOSPing > probe. I have a number of other hosts/Targets that are using this > probe. I have kicked out some debug results from > /usr/share/perl5/Smokeping/probes/TelnetIOSPing.pm and the host is > reachable and I see ping results, but they don't make it into the > graph. In addition, no errors related to said host, are showing in the > smokeping.log. Any ideas? > > Thank you! > > > open(OUTF,">>/tmp/TelnetIOSPing.debug") || die "Can't open OUTF: $!"; > print OUTF "target => $dest\nsource => $source\nuser => $login\n"; > > my $ok = $telnet->open(Host => $source, > Port => $port); > > print OUTF "\n"; > print OUTF "===========================\n"; > print OUTF "Connection to $source $ok\n"; > print OUTF "\n"; > > #---- Code that does the log in and executes extended ping > > $telnet->prompt('/[\@\w\-\.]+[>#][ ]*$/'); > @output = $telnet->cmd("n"); > > #$telnet->waitfor('/[\@\w\-\.]+[>#][ ]*$/'); > $telnet->print("quit"); > $telnet->close; > > print OUTF "closed Telnet connection\n"; > > my @times = (); > while (@output) { > my $outputline = shift @output; > chomp($outputline); > print OUTF "$outputline\n"; > $outputline =~ /^Reply to request \d+ \((\d+) ms\)/ && push(@times,$1); > print OUTF "$outputline => $1\n"; > } > > > <<< I see data in graph from this Target >>> > > +++ pvdc_to_mesa_rtr > menu = Core to eSedo MESA RTR > title = Core Router to eSedo MESA RTR > probe = TelnetIOSPing > host = > source = > > > =========================== > Connection to 1 > > closed Telnet connection > Type escape sequence to abort. > Type escape sequence to abort. => > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => > Reply to request 0 (1 ms) > Reply to request 0 (1 ms) => 1 > Reply to request 1 (4 ms) > Reply to request 1 (4 ms) => 4 > Reply to request 2 (1 ms) > Reply to request 2 (1 ms) => 1 > Reply to request 3 (1 ms) > Reply to request 3 (1 ms) => 1 > Reply to request 4 (1 ms) > Reply to request 4 (1 ms) => 1 > Reply to request 5 (1 ms) > Reply to request 5 (1 ms) => 1 > Reply to request 6 (1 ms) > Reply to request 6 (1 ms) => 1 > Reply to request 7 (1 ms) > Reply to request 7 (1 ms) => 1 > Reply to request 8 (4 ms) > Reply to request 8 (4 ms) => 4 > Reply to request 9 (1 ms) > Reply to request 9 (1 ms) => 1 > Reply to request 10 (1 ms) > Reply to request 10 (1 ms) => 1 > Reply to request 11 (1 ms) > Reply to request 11 (1 ms) => 1 > Reply to request 12 (1 ms) > Reply to request 12 (1 ms) => 1 > Reply to request 13 (1 ms) > Reply to request 13 (1 ms) => 1 > Reply to request 14 (1 ms) > Reply to request 14 (1 ms) => 1 > Reply to request 15 (1 ms) > Reply to request 15 (1 ms) => 1 > Reply to request 16 (1 ms) > Reply to request 16 (1 ms) => 1 > Reply to request 17 (1 ms) > Reply to request 17 (1 ms) => 1 > Reply to request 18 (1 ms) > Reply to request 18 (1 ms) => 1 > Reply to request 19 (4 ms) > Reply to request 19 (4 ms) => 4 > Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms > Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms => 4 > target => > source => > user => smokeping > > > > > <<< I DO NOT see data in graph from this Target >>> > > +++ esedo_to_mesa_rtr > menu = esedo Core to eSedo MESA > title = eSedo Core Router to eSedo MESA RTR > probe = TelnetIOSPing > host = > source = > > > =========================== > Connection to 1 > > closed Telnet connection > Type escape sequence to abort. > Type escape sequence to abort. => > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => > Reply to request 0 (60 ms) > Reply to request 0 (60 ms) => 60 > Reply to request 1 (52 ms) > Reply to request 1 (52 ms) => 52 > Reply to request 2 (24 ms) > Reply to request 2 (24 ms) => 24 > Reply to request 3 (64 ms) > Reply to request 3 (64 ms) => 64 > Reply to request 4 (56 ms) > Reply to request 4 (56 ms) => 56 > Reply to request 5 (40 ms) > Reply to request 5 (40 ms) => 40 > Reply to request 6 (44 ms) > Reply to request 6 (44 ms) => 44 > Reply to request 7 (60 ms) > Reply to request 7 (60 ms) => 60 > Reply to request 8 (40 ms) > Reply to request 8 (40 ms) => 40 > Reply to request 9 (36 ms) > Reply to request 9 (36 ms) => 36 > Reply to request 10 (20 ms) > Reply to request 10 (20 ms) => 20 > Reply to request 11 (20 ms) > Reply to request 11 (20 ms) => 20 > Reply to request 12 (28 ms) > Reply to request 12 (28 ms) => 28 > Reply to request 13 (28 ms) > Reply to request 13 (28 ms) => 28 > Reply to request 14 (36 ms) > Reply to request 14 (36 ms) => 36 > Reply to request 15 (20 ms) > Reply to request 15 (20 ms) => 20 > Reply to request 16 (20 ms) > Reply to request 16 (20 ms) => 20 > Reply to request 17 (8 ms) > Reply to request 17 (8 ms) => 8 > Reply to request 18 (20 ms) > Reply to request 18 (20 ms) => 20 > Reply to request 19 (44 ms) > Reply to request 19 (44 ms) => 44 > Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 ms > Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 ms => 44 > target => > source => > user => smokeping > > > > _______________________________________________ > smokeping-users mailing list > smokeping-users at lists.oetiker.ch > https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131004/07b718e7/attachment.htm From makeconfig at gmail.com Fri Oct 4 16:20:31 2013 From: makeconfig at gmail.com (Andrew Anderson) Date: Fri, 4 Oct 2013 17:20:31 +0300 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: References: Message-ID: 2013/10/4, Paul Mansfield : > the slaves submit date to the master using http. > OK, but why the master checks the target which assigned to the slave ? From makeconfig at gmail.com Fri Oct 4 16:21:47 2013 From: makeconfig at gmail.com (Andrew Anderson) Date: Fri, 4 Oct 2013 17:21:47 +0300 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: References: Message-ID: OK, but why the master checks the target which assigned to the slave ? 2013/10/4, Andrew Anderson : > 2013/10/4, Paul Mansfield : >> the slaves submit date to the master using http. >> > > OK, but why the master checks the target which assigned to the slave ? > From jul.collas at gmail.com Fri Oct 4 16:26:38 2013 From: jul.collas at gmail.com (Julien Collas) Date: Fri, 4 Oct 2013 16:26:38 +0200 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: References: Message-ID: + RemoteTest slaves = slave_host menu = RemoteTest title = RemoteTest host = 2.2.2.2*nomasterpoll = yes* Default value: nomasterpoll = no Julien 2013/10/4 Andrew Anderson > OK, but why the master checks the target which assigned to the slave ? > > 2013/10/4, Andrew Anderson : > > 2013/10/4, Paul Mansfield : > >> the slaves submit date to the master using http. > >> > > > > OK, but why the master checks the target which assigned to the slave ? > > > > _______________________________________________ > smokeping-users mailing list > smokeping-users at lists.oetiker.ch > https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131004/2655c01e/attachment-0001.htm From makeconfig at gmail.com Fri Oct 4 16:27:42 2013 From: makeconfig at gmail.com (Andrew Anderson) Date: Fri, 4 Oct 2013 17:27:42 +0300 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: References: Message-ID: Thank you ! 2013/10/4, Julien Collas : > + RemoteTest > slaves = slave_host > menu = RemoteTest > title = RemoteTest > host = 2.2.2.2*nomasterpoll = yes* > > > Default value: nomasterpoll = no > > Julien > > > 2013/10/4 Andrew Anderson > >> OK, but why the master checks the target which assigned to the slave ? >> >> 2013/10/4, Andrew Anderson : >> > 2013/10/4, Paul Mansfield : >> >> the slaves submit date to the master using http. >> >> >> > >> > OK, but why the master checks the target which assigned to the slave ? >> > >> >> _______________________________________________ >> smokeping-users mailing list >> smokeping-users at lists.oetiker.ch >> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users >> > From gregs at sloop.net Fri Oct 4 16:45:41 2013 From: gregs at sloop.net (Gregory Sloop) Date: Fri, 4 Oct 2013 07:45:41 -0700 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: References: Message-ID: <713078033.20131004074541@sloop.net> Read the docs: http://oss.oetiker.ch/smokeping/doc/smokeping_config.en.html Find "nomasterpoll" And anticipating your next question... --- Make sure that the user apache runs as can actually *write* to the RRD files - since that's how the slaves update the RRD's on the master. -Greg AA> OK, but why the master checks the target which assigned to the slave ? AA> 2013/10/4, Andrew Anderson : >> 2013/10/4, Paul Mansfield : >>> the slaves submit date to the master using http. >>> >> >> OK, but why the master checks the target which assigned to the slave ? >> AA> _______________________________________________ AA> smokeping-users mailing list AA> smokeping-users at lists.oetiker.ch AA> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users -- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice: 503.251.0452 x82 EMail: gregs at sloop.net http://www.sloop.net --- From gregs at sloop.net Fri Oct 4 16:48:34 2013 From: gregs at sloop.net (Gregory Sloop) Date: Fri, 4 Oct 2013 07:48:34 -0700 Subject: [smokeping-users] Graph but no results In-Reply-To: <524ECCC0.6010303@commspeed.net> References: <524DB860.1010408@commspeed.net> <524EC41B.8080607@commspeed.net> <524ECCC0.6010303@commspeed.net> Message-ID: <645136836.20131004074834@sloop.net> An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131004/6bdaece8/attachment.htm From makeconfig at gmail.com Fri Oct 4 16:54:54 2013 From: makeconfig at gmail.com (Andrew Anderson) Date: Fri, 4 Oct 2013 17:54:54 +0300 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: References: Message-ID: The master is not checks the target which assigned to the slave. But the graph is still blank, and the slave sends data to the master successfuly: FPing: Executing /usr/local/sbin/fping -C 20 -q -B1 -r1 -b1000 -i10 2.2.2.2 FPing: Got fping output: '2.2.2.2 : 6.94 4.08 4.26 4.13 4.61 4.18 4.26 3.47 5.15 7.07 7.03 3.48 3.90 6.60 4.74 3.42 3.20 6.61 3.72 3.54' Sent data to Server. Server said OK 2013/10/4, Andrew Anderson : > Thank you ! > > 2013/10/4, Julien Collas : >> + RemoteTest >> slaves = slave_host >> menu = RemoteTest >> title = RemoteTest >> host = 2.2.2.2*nomasterpoll = yes* >> >> >> Default value: nomasterpoll = no >> >> Julien >> >> >> 2013/10/4 Andrew Anderson >> >>> OK, but why the master checks the target which assigned to the slave ? >>> >>> 2013/10/4, Andrew Anderson : >>> > 2013/10/4, Paul Mansfield : >>> >> the slaves submit date to the master using http. >>> >> >>> > >>> > OK, but why the master checks the target which assigned to the slave ? >>> > >>> >>> _______________________________________________ >>> smokeping-users mailing list >>> smokeping-users at lists.oetiker.ch >>> https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users >>> >> > From gregs at sloop.net Fri Oct 4 17:03:31 2013 From: gregs at sloop.net (Gregory Sloop) Date: Fri, 4 Oct 2013 08:03:31 -0700 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: References: Message-ID: <1485207546.20131004080331@sloop.net> I've been working on a "usual-screw-ups" FAQ: I think it applies here: --- 3) Master-slave setups: B) Why are my graphs empty for the slaves? As per 1 & 2 above --- Usually when there's an "empty" graph the problem is one of two things: 1) smokeping can't write the data to the RRD. 2) the web-server can't read it. If you've really debugged things and you're sure it's successfully writing to the RRD, then you'd want to watch the web-server logs and see if it's really reading them. --- But master-slave has one additional wrinkle - though the principles are the same. For *slaves*, smokeping IS NOT *writing* the data to the RRD files - they're getting pushed there by the web-server. So, in master-slave mode you need to be sure that the user your web-server is running as [apache perhaps] has *WRITE* permissions to the RRD files. Also, if you simply go mod the permissions and then you add *new* slave targets, those new slave RRD files won't have the right permissions. So you either have to simply handle that, or tweak things so the new RRD's get created with the appropriate level of permissions. --- AA> The master is not checks the target which assigned to the slave. But AA> the graph is still blank, and the slave sends data to the master AA> successfuly: AA> FPing: Executing /usr/local/sbin/fping -C 20 -q -B1 -r1 -b1000 -i10 2.2.2.2 AA> FPing: Got fping output: '2.2.2.2 : 6.94 4.08 4.26 4.13 4.61 4.18 4.26 AA> 3.47 5.15 7.07 7.03 3.48 3.90 6.60 4.74 3.42 3.20 6.61 3.72 3.54' AA> Sent data to Server. Server said OK AA> 2013/10/4, Andrew Anderson : >> Thank you ! >> From makeconfig at gmail.com Fri Oct 4 17:17:24 2013 From: makeconfig at gmail.com (Andrew Anderson) Date: Fri, 4 Oct 2013 18:17:24 +0300 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: <1485207546.20131004080331@sloop.net> References: <1485207546.20131004080331@sloop.net> Message-ID: I get it, thank you again ! 2013/10/4, Gregory Sloop : > I've been working on a "usual-screw-ups" FAQ: > > I think it applies here: > > --- > 3) Master-slave setups: > > B) Why are my graphs empty for the slaves? > As per 1 & 2 above > > --- > Usually when there's an "empty" graph the problem is one of two things: > 1) smokeping can't write the data to the RRD. > 2) the web-server can't read it. > > If you've really debugged things and you're sure it's successfully writing > to the RRD, then you'd want to watch the web-server logs and see if it's > really reading them. > --- > > But master-slave has one additional wrinkle - though the principles are the > same. > > For *slaves*, smokeping IS NOT *writing* the data to the RRD files - they're > getting pushed there by the web-server. > So, in master-slave mode you need to be sure that the user your web-server > is running as [apache perhaps] has *WRITE* permissions to the RRD files. > > Also, if you simply go mod the permissions and then you add *new* slave > targets, those new slave RRD files won't have the right permissions. > So you either have to simply handle that, or tweak things so the new RRD's > get created with the appropriate level of permissions. > > --- > > AA> The master is not checks the target which assigned to the slave. But > AA> the graph is still blank, and the slave sends data to the master > AA> successfuly: > > AA> FPing: Executing /usr/local/sbin/fping -C 20 -q -B1 -r1 -b1000 -i10 > 2.2.2.2 > AA> FPing: Got fping output: '2.2.2.2 : 6.94 4.08 4.26 4.13 4.61 4.18 4.26 > AA> 3.47 5.15 7.07 7.03 3.48 3.90 6.60 4.74 3.42 3.20 6.61 3.72 3.54' > AA> Sent data to Server. Server said OK > > AA> 2013/10/4, Andrew Anderson : >>> Thank you ! >>> > > From tonyd at commspeed.net Fri Oct 4 17:24:23 2013 From: tonyd at commspeed.net (Tony DeMatteis) Date: Fri, 04 Oct 2013 08:24:23 -0700 Subject: [smokeping-users] Graph but no results In-Reply-To: <645136836.20131004074834@sloop.net> References: <524DB860.1010408@commspeed.net> <524EC41B.8080607@commspeed.net> <524ECCC0.6010303@commspeed.net> <645136836.20131004074834@sloop.net> Message-ID: <524EDDA7.7070106@commspeed.net> Hi Greg, It's odd because both targets were added to the conf at the same time and are under the same parent. It would be strange that one rrd file would be writable/readable while to other not. However, looking at the suggestions you offered, I don't see any errors/problems with file permissions or entries in the apache log. # It would appear the rrd files have the proper permissions. Same owner:user for esedo_to_x (which does not display data in graph) as pvdc_to_x (which does display data in graph). The files are also being updated. Is there something here or elsewhere I am missing? Thank you again.... root at smokeping1:/home/tonyd# ll /var/lib/smokeping/Network/core_to_esedo total 23388 drwxr-xr-x 2 smokeping smokeping 4096 Oct 2 22:49 ./ drwxr-xr-x 6 smokeping smokeping 4096 Oct 2 10:53 ../ -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_foothills_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_mesa_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_montezona_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_voc_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 mm_to_foothills_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_esedo_core.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_mesa_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_voc_rtr.rrd # This does not display data tail -f /var/log/apache2/access.log - - [04/Oct/2013:08:07:12 -0700] "GET /cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr HTTP/1.1" 200 2010 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_86400.png HTTP/1.1" 200 21541 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_2592000.png HTTP/1.1" 200 22492 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_31536000.png HTTP/1.1" 200 22418 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_604800.png HTTP/1.1" 200 20330 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_10800.png HTTP/1.1" 200 21382 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_43200.png HTTP/1.1" 200 20971 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:14 -0700] "GET /favicon.ico HTTP/1.1" 404 501 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" # This displays data - - [04/Oct/2013:08:14:14 -0700] "GET /cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr HTTP/1.1" 200 2005 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_2592000.png HTTP/1.1" 200 25540 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_10800.png HTTP/1.1" 200 26251 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_43200.png HTTP/1.1" 200 29813 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_604800.png HTTP/1.1" 200 27440 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_31536000.png HTTP/1.1" 200 22782 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_86400.png HTTP/1.1" 200 34500 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /favicon.ico HTTP/1.1" 404 501 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" On 10/04/2013 07:48 AM, Gregory Sloop wrote: > Re: [smokeping-users] Graph but no results Have you checked the apache > logs to see if it can actually read the RRD files to get the data you > want? > > Usually when there's an "empty" graph the problem is one of two things: > 1) smokeping can't write the data to the RRD. > 2) the web-server can't read it. > > If you've really debugged things and you're sure it's successfully > writing to the RRD, then you'd want to watch the web-server logs and > see if it's really reading them. > > -Greg > > > > I meant to include my Probe definition. > > > +TelnetIOSPing > > forks = 5 > offset = 50% > packetsize = 56 > step = 300 > timeout = 10 > iospass = > iosuser = smokeping > pings = 20 > Hello, > > Maybe someone could provide me with some assistance. I have a > host/Target graph that get's created and populates the web page. > However, no results appear on the graph. I am using the TelnetIOSPing > probe. I have a number of other hosts/Targets that are using this > probe. I have kicked out some debug results from > /usr/share/perl5/Smokeping/probes/TelnetIOSPing.pm and the host is > reachable and I see ping results, but they don't make it into the > graph. In addition, no errors related to said host, are showing in the > smokeping.log. Any ideas? > > Thank you! > > > open(OUTF,">>/tmp/TelnetIOSPing.debug") || die "Can't open OUTF: $!"; > print OUTF "target => $dest\nsource => $source\nuser => $login\n"; > > my $ok = $telnet->open(Host => $source, > Port => $port); > > print OUTF "\n"; > print OUTF "===========================\n"; > print OUTF "Connection to $source $ok\n"; > print OUTF "\n"; > > #---- Code that does the log in and executes extended ping > > $telnet->prompt('/[\@\w\-\.]+[>#][ ]*$/'); > @output = $telnet->cmd("n"); > > #$telnet->waitfor('/[\@\w\-\.]+[>#][ ]*$/'); > $telnet->print("quit"); > $telnet->close; > > print OUTF "closed Telnet connection\n"; > > my @times = (); > while (@output) { > my $outputline = shift @output; > chomp($outputline); > print OUTF "$outputline\n"; > $outputline =~ /^Reply to request \d+ \((\d+) ms\)/ && > push(@times,$1); > print OUTF "$outputline => $1\n"; > } > > > <<< I see data in graph from this Target >>> > > +++ pvdc_to_mesa_rtr > menu = Core to eSedo MESA RTR > title = Core Router to eSedo MESA RTR > probe = TelnetIOSPing > host = > source = > > > =========================== > Connection to 1 > > closed Telnet connection > Type escape sequence to abort. > Type escape sequence to abort. => > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => > Reply to request 0 (1 ms) > Reply to request 0 (1 ms) => 1 > Reply to request 1 (4 ms) > Reply to request 1 (4 ms) => 4 > Reply to request 2 (1 ms) > Reply to request 2 (1 ms) => 1 > Reply to request 3 (1 ms) > Reply to request 3 (1 ms) => 1 > Reply to request 4 (1 ms) > Reply to request 4 (1 ms) => 1 > Reply to request 5 (1 ms) > Reply to request 5 (1 ms) => 1 > Reply to request 6 (1 ms) > Reply to request 6 (1 ms) => 1 > Reply to request 7 (1 ms) > Reply to request 7 (1 ms) => 1 > Reply to request 8 (4 ms) > Reply to request 8 (4 ms) => 4 > Reply to request 9 (1 ms) > Reply to request 9 (1 ms) => 1 > Reply to request 10 (1 ms) > Reply to request 10 (1 ms) => 1 > Reply to request 11 (1 ms) > Reply to request 11 (1 ms) => 1 > Reply to request 12 (1 ms) > Reply to request 12 (1 ms) => 1 > Reply to request 13 (1 ms) > Reply to request 13 (1 ms) => 1 > Reply to request 14 (1 ms) > Reply to request 14 (1 ms) => 1 > Reply to request 15 (1 ms) > Reply to request 15 (1 ms) => 1 > Reply to request 16 (1 ms) > Reply to request 16 (1 ms) => 1 > Reply to request 17 (1 ms) > Reply to request 17 (1 ms) => 1 > Reply to request 18 (1 ms) > Reply to request 18 (1 ms) => 1 > Reply to request 19 (4 ms) > Reply to request 19 (4 ms) => 4 > Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms > Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms > => 4 > target => > source => > user => smokeping > > > > > <<< I DO NOT see data in graph from this Target >>> > > +++ esedo_to_mesa_rtr > menu = esedo Core to eSedo MESA > title = eSedo Core Router to eSedo MESA RTR > probe = TelnetIOSPing > host = > source = > > > =========================== > Connection to 1 > > closed Telnet connection > Type escape sequence to abort. > Type escape sequence to abort. => > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => > Reply to request 0 (60 ms) > Reply to request 0 (60 ms) => 60 > Reply to request 1 (52 ms) > Reply to request 1 (52 ms) => 52 > Reply to request 2 (24 ms) > Reply to request 2 (24 ms) => 24 > Reply to request 3 (64 ms) > Reply to request 3 (64 ms) => 64 > Reply to request 4 (56 ms) > Reply to request 4 (56 ms) => 56 > Reply to request 5 (40 ms) > Reply to request 5 (40 ms) => 40 > Reply to request 6 (44 ms) > Reply to request 6 (44 ms) => 44 > Reply to request 7 (60 ms) > Reply to request 7 (60 ms) => 60 > Reply to request 8 (40 ms) > Reply to request 8 (40 ms) => 40 > Reply to request 9 (36 ms) > Reply to request 9 (36 ms) => 36 > Reply to request 10 (20 ms) > Reply to request 10 (20 ms) => 20 > Reply to request 11 (20 ms) > Reply to request 11 (20 ms) => 20 > Reply to request 12 (28 ms) > Reply to request 12 (28 ms) => 28 > Reply to request 13 (28 ms) > Reply to request 13 (28 ms) => 28 > Reply to request 14 (36 ms) > Reply to request 14 (36 ms) => 36 > Reply to request 15 (20 ms) > Reply to request 15 (20 ms) => 20 > Reply to request 16 (20 ms) > Reply to request 16 (20 ms) => 20 > Reply to request 17 (8 ms) > Reply to request 17 (8 ms) => 8 > Reply to request 18 (20 ms) > Reply to request 18 (20 ms) => 20 > Reply to request 19 (44 ms) > Reply to request 19 (44 ms) => 44 > Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 ms > Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 > ms => 44 > target => > source => > user => smokeping > > > > _______________________________________________ > smokeping-users mailing list > smokeping-users at lists.oetiker.ch > https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users > > > > /-- > Gregory Sloop, Principal: Sloop Network & Computer Consulting > Voice: 503.251.0452 x82 > EMail: /gregs at sloop.net > http://www.sloop.net > /--- / -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131004/f5109306/attachment-0001.htm From gregs at sloop.net Fri Oct 4 17:46:12 2013 From: gregs at sloop.net (Gregory Sloop) Date: Fri, 4 Oct 2013 08:46:12 -0700 Subject: [smokeping-users] Graph but no results In-Reply-To: <524EDDA7.7070106@commspeed.net> References: <524DB860.1010408@commspeed.net> <524EC41B.8080607@commspeed.net> <524ECCC0.6010303@commspeed.net> <645136836.20131004074834@sloop.net> <524EDDA7.7070106@commspeed.net> Message-ID: <1054121104.20131004084612@sloop.net> An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131004/217267bd/attachment.htm From tonyd at commspeed.net Fri Oct 4 19:02:11 2013 From: tonyd at commspeed.net (Tony DeMatteis) Date: Fri, 04 Oct 2013 10:02:11 -0700 Subject: [smokeping-users] Graph but no results In-Reply-To: <1054121104.20131004084612@sloop.net> References: <524DB860.1010408@commspeed.net> <524EC41B.8080607@commspeed.net> <524ECCC0.6010303@commspeed.net> <645136836.20131004074834@sloop.net> <524EDDA7.7070106@commspeed.net> <1054121104.20131004084612@sloop.net> Message-ID: <524EF493.8090906@commspeed.net> The debug was actually directly from the TelnetIOSPing.pm. I simply uncommented a few statements and changed the path/filename and included the $source at the top to clearly delineate the host it was printing output from the Extended Ping results. So I ran smokeping in debug mode. Interesting... Smokeping isn't getting any data to update the rrd with. pattern match timed-out at /usr/share/perl5/Smokeping/probes/TelnetIOSPing.pm line 172 TelnetIOSPing: : got Calling RRDs::update(/var/lib/smokeping/Network/core_to_esedo/esedo_to_mesa_rtr.rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 1380903220:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) It would appear that there is a problem waiting for the prompt after issuing the "Terminal Length 0" command What's odd is that a running log of the ping command output shows results for the connected host as I showed in my original post. I know from everybody else's point of view, your's included, that the obvious question "are you sure your seeing the output from the host you think you are?". Reasonable question. I don't know how I could be seeing otherwise, the debug print statements follow the $telnet-> yada yada statements and result. Ok, so the debug indicates there are no results due to a problem getting to the ping command (line179 - $telnet->waitfor('/[\@\w\-\.]+[>#][ ]*$/');) . So I do the login to the router manually and it works (using the password from the Probe config file for the smokeping user). It doesn't appear to be an authentication issue... BTW - I use tacacs, and every router is auth'ing against the same source root at smokeping1:/etc/smokeping# ssh smokeping at cr1.esedo ************************************************************ | | ||| ||| ||||| ||||| .....:|||||||:.....:|||||||:..... C i s c o S y s t e m s ************************************************************ Company = Site Name = ESEDO Location = Device Name = cr1.esedo FQDN = cr1.esedo..net (ins: cr1.esedo) Contact = ************************************************************ \\|// (o o) -----oOO---(^)------------ *********************************************************** * WARNING: This is a controlled access system... * * * Access to this equipment is restricted to * authorized employees only. Any intrusions or misuse will * be prosecuted to the fullest extent of local, state & * federal law. * * All activities on this network are logged!!! * * * If you are not an authorized user, disconnect now!! *********************************************************** ------------------oOO----- |__| |__| | | | | Password: cr1.esedo>en Password: cr1.esedo#ping Protocol [ip]: Target IP address: Repeat count [5]: 20 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: v Loose, Strict, Record, Timestamp, Verbose[V]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 20, 100-byte ICMP Echos to , timeout is 2 seconds: Reply to request 0 (4 ms) Reply to request 1 (8 ms) Reply to request 2 (4 ms) Reply to request 3 (12 ms) Reply to request 4 (12 ms) Reply to request 5 (8 ms) Reply to request 6 (8 ms) Reply to request 7 (8 ms) Reply to request 8 (4 ms) Reply to request 9 (8 ms) Reply to request 10 (4 ms) Reply to request 11 (8 ms) Reply to request 12 (4 ms) Reply to request 13 (4 ms) Reply to request 14 (4 ms) Reply to request 15 (8 ms) Reply to request 16 (4 ms) Reply to request 17 (8 ms) Reply to request 18 (8 ms) Reply to request 19 (8 ms) Success rate is 100 percent (20/20), round-trip min/avg/max = 4/6/12 ms cr1.esedo# On 10/04/2013 08:46 AM, Gregory Sloop wrote: > Re: [smokeping-users] Graph but no results The "debug" you sent was > from *your* script, not a smokeping --debug, right. > > Have you run smokeping --debug and watched the data/logs it returns? > > Again, usually the problems are: > writing the data to the RRD - and running smokeping in debug mode will > show you what's happening here: [or for a slave - the apache + > apache-error logs] > - or - > reading the data from the RRD for presentation - and the apache [and > the apache error] logs will show you this. > > So, if you're sure there's no read problem, then I think we're back to > making sure that real data is hitting the RRD and a smokeping --debug > would probably be enlightening. > > -Greg > > > Hi Greg, > > It's odd because both targets were added to the conf at the same time > and are under the same parent. It would be strange that one rrd file > would be writable/readable while to other not. However, looking at > the suggestions you offered, I don't see any errors/problems with file > permissions or entries in the apache log. > > > # It would appear the rrd files have the proper permissions. Same > owner:user for esedo_to_x (which does not display data in graph) as > pvdc_to_x (which does display data in graph). The files are also > being updated. Is there something here or elsewhere I am missing? > > Thank you again.... > > > > root at smokeping1:/home/tonyd# ll /var/lib/smokeping/Network/core_to_esedo > total 23388 > drwxr-xr-x 2 smokeping smokeping 4096 Oct 2 22:49 ./ > drwxr-xr-x 6 smokeping smokeping 4096 Oct 2 10:53 ../ > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > esedo_to_foothills_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > esedo_to_mesa_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > esedo_to_montezona_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_voc_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > mm_to_foothills_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > pvdc_to_esedo_core.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_mesa_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_voc_rtr.rrd > > > > # This does not display data > > tail -f /var/log/apache2/access.log > > - - [04/Oct/2013:08:07:12 -0700] "GET > /cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr > HTTP/1.1" 200 2010 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_86400.png > HTTP/1.1" 200 21541 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_2592000.png > HTTP/1.1" 200 22492 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_31536000.png > HTTP/1.1" 200 22418 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_604800.png > HTTP/1.1" 200 20330 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_10800.png > HTTP/1.1" 200 21382 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_43200.png > HTTP/1.1" 200 20971 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:14 -0700] "GET /favicon.ico > HTTP/1.1" 404 501 "-" "Mozilla/5.0 (X11; Linux x86_64) > AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" > > > # This displays data > > - - [04/Oct/2013:08:14:14 -0700] "GET > /cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr > HTTP/1.1" 200 2005 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_2592000.png > HTTP/1.1" 200 25540 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_10800.png HTTP/1.1" > 200 26251 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_43200.png HTTP/1.1" > 200 29813 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_604800.png > HTTP/1.1" 200 27440 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_31536000.png > HTTP/1.1" 200 22782 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_86400.png HTTP/1.1" > 200 34500 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET /favicon.ico > HTTP/1.1" 404 501 "-" "Mozilla/5.0 (X11; Linux x86_64) > AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" > > > > > > > On 10/04/2013 07:48 AM, Gregory Sloop wrote: > Have you checked the apache logs to see if it can actually read the > RRD files to get the data you want? > > Usually when there's an "empty" graph the problem is one of two things: > 1) smokeping can't write the data to the RRD. > 2) the web-server can't read it. > > If you've really debugged things and you're sure it's successfully > writing to the RRD, then you'd want to watch the web-server logs and > see if it's really reading them. > > -Greg > > > > I meant to include my Probe definition. > > > +TelnetIOSPing > > forks = 5 > offset = 50% > packetsize = 56 > step = 300 > timeout = 10 > iospass = > iosuser = smokeping > pings = 20 > Hello, > > Maybe someone could provide me with some assistance. I have a > host/Target graph that get's created and populates the web page. > However, no results appear on the graph. I am using the TelnetIOSPing > probe. I have a number of other hosts/Targets that are using this > probe. I have kicked out some debug results from > /usr/share/perl5/Smokeping/probes/TelnetIOSPing.pm and the host is > reachable and I see ping results, but they don't make it into the > graph. In addition, no errors related to said host, are showing in the > smokeping.log. Any ideas? > > Thank you! > > > open(OUTF,">>/tmp/TelnetIOSPing.debug") || die "Can't open OUTF: $!"; > print OUTF "target => $dest\nsource => $source\nuser => $login\n"; > > my $ok = $telnet->open(Host => $source, > Port => $port); > > print OUTF "\n"; > print OUTF "===========================\n"; > print OUTF "Connection to $source $ok\n"; > print OUTF "\n"; > > #---- Code that does the log in and executes extended ping > > $telnet->prompt('/[\@\w\-\.]+[>#][ ]*$/'); > @output = $telnet->cmd("n"); > > #$telnet->waitfor('/[\@\w\-\.]+[>#][ ]*$/'); > $telnet->print("quit"); > $telnet->close; > > print OUTF "closed Telnet connection\n"; > > my @times = (); > while (@output) { > my $outputline = shift @output; > chomp($outputline); > print OUTF "$outputline\n"; > $outputline =~ /^Reply to request \d+ \((\d+) ms\)/ && > push(@times,$1); > print OUTF "$outputline => $1\n"; > } > > > <<< I see data in graph from this Target >>> > > +++ pvdc_to_mesa_rtr > menu = Core to eSedo MESA RTR > title = Core Router to eSedo MESA RTR > probe = TelnetIOSPing > host = > source = > > > =========================== > Connection to 1 > > closed Telnet connection > Type escape sequence to abort. > Type escape sequence to abort. => > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => > Reply to request 0 (1 ms) > Reply to request 0 (1 ms) => 1 > Reply to request 1 (4 ms) > Reply to request 1 (4 ms) => 4 > Reply to request 2 (1 ms) > Reply to request 2 (1 ms) => 1 > Reply to request 3 (1 ms) > Reply to request 3 (1 ms) => 1 > Reply to request 4 (1 ms) > Reply to request 4 (1 ms) => 1 > Reply to request 5 (1 ms) > Reply to request 5 (1 ms) => 1 > Reply to request 6 (1 ms) > Reply to request 6 (1 ms) => 1 > Reply to request 7 (1 ms) > Reply to request 7 (1 ms) => 1 > Reply to request 8 (4 ms) > Reply to request 8 (4 ms) => 4 > Reply to request 9 (1 ms) > Reply to request 9 (1 ms) => 1 > Reply to request 10 (1 ms) > Reply to request 10 (1 ms) => 1 > Reply to request 11 (1 ms) > Reply to request 11 (1 ms) => 1 > Reply to request 12 (1 ms) > Reply to request 12 (1 ms) => 1 > Reply to request 13 (1 ms) > Reply to request 13 (1 ms) => 1 > Reply to request 14 (1 ms) > Reply to request 14 (1 ms) => 1 > Reply to request 15 (1 ms) > Reply to request 15 (1 ms) => 1 > Reply to request 16 (1 ms) > Reply to request 16 (1 ms) => 1 > Reply to request 17 (1 ms) > Reply to request 17 (1 ms) => 1 > Reply to request 18 (1 ms) > Reply to request 18 (1 ms) => 1 > Reply to request 19 (4 ms) > Reply to request 19 (4 ms) => 4 > Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms > Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms > => 4 > target => > source => > user => smokeping > > > > > <<< I DO NOT see data in graph from this Target >>> > > +++ esedo_to_mesa_rtr > menu = esedo Core to eSedo MESA > title = eSedo Core Router to eSedo MESA RTR > probe = TelnetIOSPing > host = > source = > > > =========================== > Connection to 1 > > closed Telnet connection > Type escape sequence to abort. > Type escape sequence to abort. => > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => > Reply to request 0 (60 ms) > Reply to request 0 (60 ms) => 60 > Reply to request 1 (52 ms) > Reply to request 1 (52 ms) => 52 > Reply to request 2 (24 ms) > Reply to request 2 (24 ms) => 24 > Reply to request 3 (64 ms) > Reply to request 3 (64 ms) => 64 > Reply to request 4 (56 ms) > Reply to request 4 (56 ms) => 56 > Reply to request 5 (40 ms) > Reply to request 5 (40 ms) => 40 > Reply to request 6 (44 ms) > Reply to request 6 (44 ms) => 44 > Reply to request 7 (60 ms) > Reply to request 7 (60 ms) => 60 > Reply to request 8 (40 ms) > Reply to request 8 (40 ms) => 40 > Reply to request 9 (36 ms) > Reply to request 9 (36 ms) => 36 > Reply to request 10 (20 ms) > Reply to request 10 (20 ms) => 20 > Reply to request 11 (20 ms) > Reply to request 11 (20 ms) => 20 > Reply to request 12 (28 ms) > Reply to request 12 (28 ms) => 28 > Reply to request 13 (28 ms) > Reply to request 13 (28 ms) => 28 > Reply to request 14 (36 ms) > Reply to request 14 (36 ms) => 36 > Reply to request 15 (20 ms) > Reply to request 15 (20 ms) => 20 > Reply to request 16 (20 ms) > Reply to request 16 (20 ms) => 20 > Reply to request 17 (8 ms) > Reply to request 17 (8 ms) => 8 > Reply to request 18 (20 ms) > Reply to request 18 (20 ms) => 20 > Reply to request 19 (44 ms) > Reply to request 19 (44 ms) => 44 > Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 ms > Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 > ms => 44 > target => > source => > user => smokeping > > > > _______________________________________________ > smokeping-users mailing list > smokeping-users at lists.oetiker.ch > https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users > > > > > /-- > Gregory Sloop, Principal: Sloop Network & Computer Consulting > Voice: 503.251.0452 x82 > EMail: /gregs at sloop.net > http://www.sloop.net > /--- > > -- > Gregory Sloop, Principal: Sloop Network & Computer Consulting > Voice: 503.251.0452 x82 > EMail: /gregs at sloop.net > http://www.sloop.net > /--- / -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131004/bea5049b/attachment-0001.htm From gregs at sloop.net Fri Oct 4 19:23:12 2013 From: gregs at sloop.net (Gregory Sloop) Date: Fri, 4 Oct 2013 10:23:12 -0700 Subject: [smokeping-users] Graph but no results In-Reply-To: <524EF493.8090906@commspeed.net> References: <524DB860.1010408@commspeed.net> <524EC41B.8080607@commspeed.net> <524ECCC0.6010303@commspeed.net> <645136836.20131004074834@sloop.net> <524EDDA7.7070106@commspeed.net> <1054121104.20131004084612@sloop.net> <524EF493.8090906@commspeed.net> Message-ID: <19310716485.20131004102312@sloop.net> An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131004/66e9b3f6/attachment-0001.htm From tonyd at commspeed.net Fri Oct 4 19:28:36 2013 From: tonyd at commspeed.net (Tony DeMatteis) Date: Fri, 04 Oct 2013 10:28:36 -0700 Subject: [smokeping-users] Graph but no results In-Reply-To: <19310716485.20131004102312@sloop.net> References: <524DB860.1010408@commspeed.net> <524EC41B.8080607@commspeed.net> <524ECCC0.6010303@commspeed.net> <645136836.20131004074834@sloop.net> <524EDDA7.7070106@commspeed.net> <1054121104.20131004084612@sloop.net> <524EF493.8090906@commspeed.net> <19310716485.20131004102312@sloop.net> Message-ID: <524EFAC4.8020009@commspeed.net> The problem is indeed the ping command (see bottom of output), but a permissions issue with privilege level. I'll have to dig more. Thanks again Greg!! < 0x00000: 0d 0a 0d 0a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a ....************ < 0x00010: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00020: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00030: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00040: 0d 0a 20 20 20 20 20 20 20 20 20 20 20 20 20 20 .. < 0x00050: 20 20 20 20 20 20 20 20 7c 20 20 20 20 20 20 20 | < 0x00060: 20 20 20 20 20 20 7c 0d 0a 20 20 20 20 20 20 20 |.. < 0x00070: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 7c 7c || < 0x00080: 7c 20 20 20 20 20 20 20 20 20 20 20 7c 7c 7c 0d | |||. < 0x00090: 0a 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 . < 0x000a0: 20 20 20 20 20 7c 7c 7c 7c 7c 20 20 20 20 20 20 ||||| < 0x000b0: 20 20 20 7c 7c 7c 7c 7c 0d 0a 20 20 20 20 20 20 |||||.. < 0x000c0: 20 20 20 20 20 20 20 2e 2e 2e 2e 2e 3a 7c 7c 7c .....:||| < 0x000d0: 7c 7c 7c 7c 3a 2e 2e 2e 2e 2e 3a 7c 7c 7c 7c 7c ||||:.....:||||| < 0x000e0: 7c 7c 3a 2e 2e 2e 2e 2e 0d 0a 20 20 20 20 20 20 ||:....... < 0x000f0: 20 20 20 20 20 20 20 20 20 20 20 20 43 20 69 20 C i < 0x00100: 73 20 63 20 6f 20 53 20 79 20 73 20 74 20 65 20 s c o S y s t e < 0x00110: 6d 20 73 0d 0a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a m s..*********** < 0x00120: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00130: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00140: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00150: 2a 0d 0a 43 6f 6d 70 61 6e 79 20 20 20 20 20 20 *..Company < 0x00160: 20 20 20 3d 20 20 65 53 65 64 6f 6e 61 0d 0a 53 = ..S < 0x00170: 69 74 65 20 4e 61 6d 65 20 20 20 20 20 20 20 3d ite Name = < 0x00180: 20 20 45 53 45 53 4f 0d 0a 4c 6f 63 61 74 69 6f ESESO..Locatio < 0x00190: 6e 20 20 20 20 20 20 20 20 3d 20 20 53 65 64 6f n = Sedo < 0x001a0: 6e 61 2c 20 41 5a 0d 0a 44 65 76 69 63 65 20 4e na. AZ..Device N < 0x001b0: 61 6d 65 20 20 20 20 20 3d 20 20 63 72 31 2e 65 ame = cr1.e < 0x001c0: 73 65 64 6f 0d 0a 46 51 44 4e 20 20 20 20 20 20 sedo..FQDN < 0x001d0: 20 20 20 20 20 20 3d 20 20 63 72 31 2e 65 73 65 = cr1.ese < 0x001e0: 64 6f 2e 65 73 65 64 6f 6e 61 2e 6e 65 74 20 28 do..net ( < 0x001f0: 69 6e 73 3a 20 63 72 31 2e 65 73 65 64 6f 29 0d ins: cr1.esedo). < 0x00200: 0a 43 6f 6e 74 61 63 74 20 20 20 20 20 20 20 20 .Contact < 0x00210: 20 3d 20 20 4e 4f 43 3a = NOC: < 0x00000: 28 38 36 36 29 33 31 36 2d 34 36 36 32 20 7c 20 < 0x00010: 6e 6f 63 40 63 6f 6d 6d 73 70 65 65 64 2e 6e 65 < 0x00020: 74 0d 0a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a ...************* < 0x00030: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00040: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00050: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 0d ***************. < 0x00060: 0a 0d 0a 20 20 20 20 20 20 20 20 20 20 20 20 20 ... < 0x00070: 20 20 20 20 20 20 20 20 20 20 20 5c 5c 7c 2f 2f \\|// < 0x00080: 0d 0a 20 20 20 20 20 20 20 20 20 20 20 20 20 20 .. < 0x00090: 20 20 20 20 20 20 20 20 20 20 28 6f 20 6f 29 0d (o o). < 0x000a0: 0a 20 20 20 20 20 20 20 20 20 20 20 20 20 20 2d . - < 0x000b0: 2d 2d 2d 2d 6f 4f 4f 2d 2d 2d 28 5e 29 2d 2d 2d ----oOO---(^)--- < 0x000c0: 2d 2d 2d 2d 2d 2d 2d 2d 2d 0d 0a 20 2a 2a 2a 2a ---------.. **** < 0x000d0: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x000e0: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x000f0: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00100: 2a 2a 2a 2a 2a 2a 2a 0d 0a 20 2a 20 57 41 52 4e *******.. * WARN < 0x00110: 49 4e 47 3a 20 54 68 69 73 20 69 73 20 61 20 63 ING: This is a c < 0x00120: 6f 6e 74 72 6f 6c 6c 65 64 20 61 63 63 65 73 73 ontrolled access < 0x00130: 20 73 79 73 74 65 6d 2e 2e 2e 0d 0a 20 2a 0d 0a system..... *.. < 0x00140: 20 2a 0d 0a 20 2a 20 41 63 63 65 73 73 20 74 6f *.. * Access to < 0x00150: 20 74 68 69 73 20 65 71 75 69 70 6d 65 6e 74 20 this equipment < 0x00160: 69 73 20 72 65 73 74 72 69 63 74 65 64 20 74 6f is restricted to < 0x00170: 20 65 53 65 64 6f 6e 61 0d 0a 20 2a 20 61 75 74 eSedona.. * aut < 0x00180: 68 6f 72 69 7a 65 64 20 65 6d 70 6c 6f 79 65 65 horized employee < 0x00190: 73 20 6f 6e 6c 79 2e 20 20 41 6e 79 20 69 6e 74 s only. Any int < 0x001a0: 72 75 73 69 6f 6e 73 20 6f 72 20 6d 69 73 75 73 rusions or misus < 0x001b0: 65 20 77 69 6c 6c 0d 0a 20 2a 20 62 65 20 70 72 e will.. * be pr < 0x001c0: 6f 73 65 63 75 74 65 64 20 74 6f 20 74 68 65 20 osecuted to the < 0x001d0: 66 75 6c 6c 65 73 74 20 65 78 74 65 6e 74 20 6f fullest extent o < 0x001e0: 66 20 6c 6f 63 61 6c 2c 20 73 74 61 74 65 20 26 f local. state & < 0x001f0: 0d 0a 20 2a 20 66 65 64 65 72 61 6c 20 6c 61 77 .. * federal law < 0x00200: 2e 0d 0a 20 2a 0d 0a 20 2a 20 41 6c 6c 20 61 63 ... *.. * All ac < 0x00210: 74 69 76 69 74 69 65 73 20 6f 6e 20 74 68 69 73 tivities on this < 0x00220: 20 6e 65 74 77 6f 72 6b 20 61 72 65 20 6c 6f 67 network are log < 0x00230: 67 65 64 21 21 21 0d 0a 20 2a 0d 0a 20 2a 0d 0a ged!!!.. *.. *.. < 0x00240: 20 2a 20 20 20 49 66 20 79 6f 75 20 61 72 65 20 * If you are < 0x00250: 6e 6f 74 20 61 6e 20 61 75 74 68 6f 72 69 7a 65 not an authorize < 0x00260: 64 20 75 73 65 72 2c 20 64 69 73 63 6f 6e 6e 65 d user. disconne < 0x00270: 63 74 20 6e 6f 77 21 21 0d 0a 20 2a 2a 2a 2a 2a ct now!!.. ***** < 0x00280: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x00290: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x002a0: 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a **************** < 0x002b0: 2a 2a 2a 2a 2a 2a 0d 0a 20 20 20 20 20 20 20 20 ******.. < 0x002c0: 20 20 20 20 20 20 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d ---------- < 0x002d0: 2d 2d 2d 2d 2d 2d 2d 2d 6f 4f 4f 2d 2d 2d 2d 2d --------oOO----- < 0x002e0: 0d 0a 20 20 20 20 20 20 20 20 20 20 20 20 20 20 .. < 0x002f0: 20 20 20 20 20 20 20 7c 5f 5f 7c 20 20 20 7c 5f |__| |_ < 0x00300: 5f 7c 0d 0a 20 20 20 20 20 20 20 20 20 20 20 20 _|.. < 0x00310: 20 20 20 20 20 20 20 20 20 20 7c 20 7c 20 20 20 | | < 0x00320: 7c 20 7c 0d 0a 0d 0a 0d 0a 0d 0a 55 73 65 72 20 | |........User < 0x00330: 41 63 63 65 73 73 20 56 65 72 69 66 69 63 61 74 Access Verificat < 0x00340: 69 6f 6e 0d 0a 0d 0a 55 73 65 72 6e 61 6d 65 3a ion....Username: < 0x00350: 20 > 0x00000: 73 6d 6f 6b 65 70 69 6e 67 0d 0a smokeping.. < 0x00000: ff fe 18 ff fe 1f ??.??. < 0x00000: 73 6d sm < 0x00000: 6f 6b 65 70 69 6e 67 okeping < 0x00000: 0d 0a 50 61 73 73 77 6f 72 64 3a 20 ..Password: > 0x00000: 73 6d 30 6b 33 70 31 6e 47 41 63 37 34 31 31 34 > 0x00010: 34 39 32 0d 0a .. < 0x00000: 0d 0a 0d 0a 63 72 31 2e 65 73 65 64 6f 23 ....cr1.esedo# > 0x00000: 74 65 72 6d 69 6e 61 6c 20 6c 65 6e 67 74 68 20 terminal length > 0x00010: 30 0d 0a 0.. < 0x00000: 74 65 72 6d 69 6e 61 6c 20 terminal < 0x00000: 6c 65 6e 67 74 68 20 30 0d 0a length 0.. < 0x00000: 63 72 31 2e 65 73 65 64 6f 23 cr1.esedo# > 0x00000: 70 69 6e 67 0d 0a ping.. < 0x00000: 70 69 6e 67 0d 0a ping.. < 0x00000: 25 20 49 6e 63 6f 6d 70 6c 65 74 65 20 63 6f 6d % Incomplete com < 0x00010: 6d 61 6e 64 2e 0d 0a 0d 0a 63 72 31 2e 65 73 65 mand.....cr1.ese < 0x00020: 64 6f 23 do# On 10/04/2013 10:23 AM, Gregory Sloop wrote: > Re: [smokeping-users] Graph but no results If I were to guess, I'd > guess there's some syntax issue with the def of the target. > > Recheck the configs. > > Some possibilities: > -The TelnetIOSPing isn't where you think it is or has permission > issues, and smokeping can't run it. > -The way the credentials are passed to SP cause an issue. [Again, > syntactical] > > I don't have any other great ideas - and I know nothing about > TelnetIOSPing - but I'd guess starting at scratch again and taking a > break and re-reviewing the configs will probably get you there. > > -Greg > > > > The debug was actually directly from the TelnetIOSPing.pm. I simply > uncommented a few statements and changed the path/filename and > included the $source at the top to clearly delineate the host it was > printing output from the Extended Ping results. > > So I ran smokeping in debug mode. Interesting... Smokeping isn't > getting any data to update the rrd with. > > pattern match timed-out at > /usr/share/perl5/Smokeping/probes/TelnetIOSPing.pm line 172 > TelnetIOSPing: : got > > Calling > RRDs::update(/var/lib/smokeping/Network/core_to_esedo/esedo_to_mesa_rtr.rrd > --template > uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9:ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:ping20 > 1380903220:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) > > > It would appear that there is a problem waiting for the prompt after > issuing the "Terminal Length 0" command What's odd is that a running > log of the ping command output shows results for the connected host as > I showed in my original post. I know from everybody else's point of > view, your's included, that the obvious question "are you sure your > seeing the output from the host you think you are?". Reasonable > question. I don't know how I could be seeing otherwise, the debug > print statements follow the $telnet-> yada yada statements and result. > > Ok, so the debug indicates there are no results due to a problem > getting to the ping command (line179 - > $telnet->waitfor('/[\@\w\-\.]+[>#][ ]*$/');) . So I do the login to > the router manually and it works (using the password from the Probe > config file for the smokeping user). It doesn't appear to be an > authentication issue... > > BTW - I use tacacs, and every router is auth'ing against the same source > > > root at smokeping1:/etc/smokeping# ssh smokeping at cr1.esedo > > > > ************************************************************ > | | > ||| ||| > ||||| ||||| > .....:|||||||:.....:|||||||:..... > C i s c o S y s t e m s > ************************************************************ > Company = > Site Name = ESEDO > Location = > Device Name = cr1.esedo > FQDN = cr1.esedo..net (ins: cr1.esedo) > Contact = > ************************************************************ > > \\|// > (o o) > -----oOO---(^)------------ > *********************************************************** > * WARNING: This is a controlled access system... > * > * > * Access to this equipment is restricted to > * authorized employees only. Any intrusions or misuse will > * be prosecuted to the fullest extent of local, state & > * federal law. > * > * All activities on this network are logged!!! > * > * > * If you are not an authorized user, disconnect now!! > *********************************************************** > ------------------oOO----- > |__| |__| > | | | | > > Password: > > cr1.esedo>en > Password: > cr1.esedo#ping > Protocol [ip]: > Target IP address: > Repeat count [5]: 20 > Datagram size [100]: > Timeout in seconds [2]: > Extended commands [n]: y > Source address or interface: > Type of service [0]: > Set DF bit in IP header? [no]: > Validate reply data? [no]: > Data pattern [0xABCD]: > Loose, Strict, Record, Timestamp, Verbose[none]: v > Loose, Strict, Record, Timestamp, Verbose[V]: > Sweep range of sizes [n]: > Type escape sequence to abort. > Sending 20, 100-byte ICMP Echos to , timeout is 2 seconds: > Reply to request 0 (4 ms) > Reply to request 1 (8 ms) > Reply to request 2 (4 ms) > Reply to request 3 (12 ms) > Reply to request 4 (12 ms) > Reply to request 5 (8 ms) > Reply to request 6 (8 ms) > Reply to request 7 (8 ms) > Reply to request 8 (4 ms) > Reply to request 9 (8 ms) > Reply to request 10 (4 ms) > Reply to request 11 (8 ms) > Reply to request 12 (4 ms) > Reply to request 13 (4 ms) > Reply to request 14 (4 ms) > Reply to request 15 (8 ms) > Reply to request 16 (4 ms) > Reply to request 17 (8 ms) > Reply to request 18 (8 ms) > Reply to request 19 (8 ms) > Success rate is 100 percent (20/20), round-trip min/avg/max = 4/6/12 ms > cr1.esedo# > > > > On 10/04/2013 08:46 AM, Gregory Sloop wrote: > > The "debug" you sent was from *your* script, not a smokeping --debug, > right. > > Have you run smokeping --debug and watched the data/logs it returns? > > Again, usually the problems are: > writing the data to the RRD - and running smokeping in debug mode will > show you what's happening here: [or for a slave - the apache + > apache-error logs] > - or - > reading the data from the RRD for presentation - and the apache [and > the apache error] logs will show you this. > > So, if you're sure there's no read problem, then I think we're back to > making sure that real data is hitting the RRD and a smokeping --debug > would probably be enlightening. > > -Greg > > > Hi Greg, > > It's odd because both targets were added to the conf at the same time > and are under the same parent. It would be strange that one rrd file > would be writable/readable while to other not. However, looking at > the suggestions you offered, I don't see any errors/problems with file > permissions or entries in the apache log. > > > # It would appear the rrd files have the proper permissions. Same > owner:user for esedo_to_x (which does not display data in graph) as > pvdc_to_x (which does display data in graph). The files are also > being updated. Is there something here or elsewhere I am missing? > > Thank you again.... > > > > root at smokeping1:/home/tonyd# ll /var/lib/smokeping/Network/core_to_esedo > total 23388 > drwxr-xr-x 2 smokeping smokeping 4096 Oct 2 22:49 ./ > drwxr-xr-x 6 smokeping smokeping 4096 Oct 2 10:53 ../ > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > esedo_to_foothills_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > esedo_to_mesa_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > esedo_to_montezona_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_voc_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > mm_to_foothills_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 > pvdc_to_esedo_core.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_mesa_rtr.rrd > -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_voc_rtr.rrd > > > > # This does not display data > > tail -f /var/log/apache2/access.log > > - - [04/Oct/2013:08:07:12 -0700] "GET > /cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr > HTTP/1.1" 200 2010 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_86400.png > HTTP/1.1" 200 21541 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_2592000.png > HTTP/1.1" 200 22492 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_31536000.png > HTTP/1.1" 200 22418 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_604800.png > HTTP/1.1" 200 20330 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_10800.png > HTTP/1.1" 200 21382 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:13 -0700] "GET > /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_43200.png > HTTP/1.1" 200 20971 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:07:14 -0700] "GET /favicon.ico > HTTP/1.1" 404 501 "-" "Mozilla/5.0 (X11; Linux x86_64) > AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" > > > # This displays data > > - - [04/Oct/2013:08:14:14 -0700] "GET > /cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr > HTTP/1.1" 200 2005 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_2592000.png > HTTP/1.1" 200 25540 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_10800.png HTTP/1.1" > 200 26251 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_43200.png HTTP/1.1" > 200 29813 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_604800.png > HTTP/1.1" 200 27440 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_31536000.png > HTTP/1.1" 200 22782 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET > /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_86400.png HTTP/1.1" > 200 34500 > "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr" > "Mozilla/5.0 > (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) > Chrome/23.0.1271.97 Safari/537.11" > - - [04/Oct/2013:08:14:16 -0700] "GET /favicon.ico > HTTP/1.1" 404 501 "-" "Mozilla/5.0 (X11; Linux x86_64) > AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" > > > > > > > On 10/04/2013 07:48 AM, Gregory Sloop wrote: > Have you checked the apache logs to see if it can actually read the > RRD files to get the data you want? > > Usually when there's an "empty" graph the problem is one of two things: > 1) smokeping can't write the data to the RRD. > 2) the web-server can't read it. > > If you've really debugged things and you're sure it's successfully > writing to the RRD, then you'd want to watch the web-server logs and > see if it's really reading them. > > -Greg > > > > I meant to include my Probe definition. > > > +TelnetIOSPing > > forks = 5 > offset = 50% > packetsize = 56 > step = 300 > timeout = 10 > iospass = > iosuser = smokeping > pings = 20 > Hello, > > Maybe someone could provide me with some assistance. I have a > host/Target graph that get's created and populates the web page. > However, no results appear on the graph. I am using the TelnetIOSPing > probe. I have a number of other hosts/Targets that are using this > probe. I have kicked out some debug results from > /usr/share/perl5/Smokeping/probes/TelnetIOSPing.pm and the host is > reachable and I see ping results, but they don't make it into the > graph. In addition, no errors related to said host, are showing in the > smokeping.log. Any ideas? > > Thank you! > > > open(OUTF,">>/tmp/TelnetIOSPing.debug") || die "Can't open OUTF: $!"; > print OUTF "target => $dest\nsource => $source\nuser => $login\n"; > > my $ok = $telnet->open(Host => $source, > Port => $port); > > print OUTF "\n"; > print OUTF "===========================\n"; > print OUTF "Connection to $source $ok\n"; > print OUTF "\n"; > > #---- Code that does the log in and executes extended ping > > $telnet->prompt('/[\@\w\-\.]+[>#][ ]*$/'); > @output = $telnet->cmd("n"); > > #$telnet->waitfor('/[\@\w\-\.]+[>#][ ]*$/'); > $telnet->print("quit"); > $telnet->close; > > print OUTF "closed Telnet connection\n"; > > my @times = (); > while (@output) { > my $outputline = shift @output; > chomp($outputline); > print OUTF "$outputline\n"; > $outputline =~ /^Reply to request \d+ \((\d+) ms\)/ && > push(@times,$1); > print OUTF "$outputline => $1\n"; > } > > > <<< I see data in graph from this Target >>> > > +++ pvdc_to_mesa_rtr > menu = Core to eSedo MESA RTR > title = Core Router to eSedo MESA RTR > probe = TelnetIOSPing > host = > source = > > > =========================== > Connection to 1 > > closed Telnet connection > Type escape sequence to abort. > Type escape sequence to abort. => > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => > Reply to request 0 (1 ms) > Reply to request 0 (1 ms) => 1 > Reply to request 1 (4 ms) > Reply to request 1 (4 ms) => 4 > Reply to request 2 (1 ms) > Reply to request 2 (1 ms) => 1 > Reply to request 3 (1 ms) > Reply to request 3 (1 ms) => 1 > Reply to request 4 (1 ms) > Reply to request 4 (1 ms) => 1 > Reply to request 5 (1 ms) > Reply to request 5 (1 ms) => 1 > Reply to request 6 (1 ms) > Reply to request 6 (1 ms) => 1 > Reply to request 7 (1 ms) > Reply to request 7 (1 ms) => 1 > Reply to request 8 (4 ms) > Reply to request 8 (4 ms) => 4 > Reply to request 9 (1 ms) > Reply to request 9 (1 ms) => 1 > Reply to request 10 (1 ms) > Reply to request 10 (1 ms) => 1 > Reply to request 11 (1 ms) > Reply to request 11 (1 ms) => 1 > Reply to request 12 (1 ms) > Reply to request 12 (1 ms) => 1 > Reply to request 13 (1 ms) > Reply to request 13 (1 ms) => 1 > Reply to request 14 (1 ms) > Reply to request 14 (1 ms) => 1 > Reply to request 15 (1 ms) > Reply to request 15 (1 ms) => 1 > Reply to request 16 (1 ms) > Reply to request 16 (1 ms) => 1 > Reply to request 17 (1 ms) > Reply to request 17 (1 ms) => 1 > Reply to request 18 (1 ms) > Reply to request 18 (1 ms) => 1 > Reply to request 19 (4 ms) > Reply to request 19 (4 ms) => 4 > Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms > Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms > => 4 > target => > source => > user => smokeping > > > > > <<< I DO NOT see data in graph from this Target >>> > > +++ esedo_to_mesa_rtr > menu = esedo Core to eSedo MESA > title = eSedo Core Router to eSedo MESA RTR > probe = TelnetIOSPing > host = > source = > > > =========================== > Connection to 1 > > closed Telnet connection > Type escape sequence to abort. > Type escape sequence to abort. => > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: > Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => > Reply to request 0 (60 ms) > Reply to request 0 (60 ms) => 60 > Reply to request 1 (52 ms) > Reply to request 1 (52 ms) => 52 > Reply to request 2 (24 ms) > Reply to request 2 (24 ms) => 24 > Reply to request 3 (64 ms) > Reply to request 3 (64 ms) => 64 > Reply to request 4 (56 ms) > Reply to request 4 (56 ms) => 56 > Reply to request 5 (40 ms) > Reply to request 5 (40 ms) => 40 > Reply to request 6 (44 ms) > Reply to request 6 (44 ms) => 44 > Reply to request 7 (60 ms) > Reply to request 7 (60 ms) => 60 > Reply to request 8 (40 ms) > Reply to request 8 (40 ms) => 40 > Reply to request 9 (36 ms) > Reply to request 9 (36 ms) => 36 > Reply to request 10 (20 ms) > Reply to request 10 (20 ms) => 20 > Reply to request 11 (20 ms) > Reply to request 11 (20 ms) => 20 > Reply to request 12 (28 ms) > Reply to request 12 (28 ms) => 28 > Reply to request 13 (28 ms) > Reply to request 13 (28 ms) => 28 > Reply to request 14 (36 ms) > Reply to request 14 (36 ms) => 36 > Reply to request 15 (20 ms) > Reply to request 15 (20 ms) => 20 > Reply to request 16 (20 ms) > Reply to request 16 (20 ms) => 20 > Reply to request 17 (8 ms) > Reply to request 17 (8 ms) => 8 > Reply to request 18 (20 ms) > Reply to request 18 (20 ms) => 20 > Reply to request 19 (44 ms) > Reply to request 19 (44 ms) => 44 > Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 ms > Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 > ms => 44 > target => > source => > user => smokeping > > > > _______________________________________________ > smokeping-users mailing list > smokeping-users at lists.oetiker.ch > https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users > > > > > > /-- > Gregory Sloop, Principal: Sloop Network & Computer Consulting > Voice: 503.251.0452 x82 > EMail: /gregs at sloop.net > http://www.sloop.net > /--- > > -- > Gregory Sloop, Principal: Sloop Network & Computer Consulting > Voice: 503.251.0452 x82 > EMail: /gregs at sloop.net > http://www.sloop.net > /--- > > -- > Gregory Sloop, Principal: Sloop Network & Computer Consulting > Voice: 503.251.0452 x82 > EMail: /gregs at sloop.net > http://www.sloop.net > /--- / -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131004/a2f1b6c9/attachment-0001.htm From darren at victoriajd.com Fri Oct 4 21:14:42 2013 From: darren at victoriajd.com (Darren Murphy) Date: Sat, 5 Oct 2013 03:14:42 +0800 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: <1485207546.20131004080331@sloop.net> References: <1485207546.20131004080331@sloop.net> Message-ID: On 4 October 2013 23:03, Gregory Sloop wrote: > I've been working on a "usual-screw-ups" FAQ: > https://github.com/oetiker/SmokePing/issues/11 I opened the above issue quite a while ago, with all the best intentions.... oh well :( You may want to add your FAQ to that. cheers, Darren From gregs at sloop.net Fri Oct 4 23:29:09 2013 From: gregs at sloop.net (Gregory Sloop) Date: Fri, 4 Oct 2013 14:29:09 -0700 Subject: [smokeping-users] Smokeping, master-slave, slave targets on master host In-Reply-To: <1828694120.20131004132402@sloop.net> References: <1485207546.20131004080331@sloop.net> <1828694120.20131004132402@sloop.net> Message-ID: <310414172.20131004142909@sloop.net> Never mind - I didn't realize I already had a github account - so I did a quick mark-up and posted it. Common smokeping problems! See: https://github.com/oetiker/SmokePing/issues/11 Tobi - if that looks reasonable - lets link it from the site. Thanks, Greg GS> Here's what I have so far - these seem, by far, to be the most common GS> problems. If you'd post them up at Git - that would be great! GS> --- GS> Smokeping usual faults: GS> --- GS> Graphs are empty! GS> These have two root causes: GS> 1) Data not reaching the RRD [round robin databases] GS> Run smokeping in debug mode and watch what it says - you'll probably GS> find some good reasons stuff isn't working and be able to fix it GS> yourself. Like this: smokeping --debug GS> 2) Data *is* hitting the RRD's as confirmed by --debug. However, you GS> still get an empty graph from the browser. GS> You see: the user smokeping is running as, is writing the data - GS> that's often root or smokeping. However, the thing that's creating the GS> graphs has to *read* the data - and that's whatever process your GS> web-server is running as. That's often apache or www, httpd or GS> www-data. GS> [It depends on the apache [or how your distro sets it] configuration - GS> or whatever other web-server you're using.] GS> So, make sure that both the user smokeping is running as, as well as GS> the user the web-server is running as, both have rights to the RRD's. GS> [If you aren't sure what apache is running at, have a look at the GS> apache config files. For example Ubuntu 12.04 has the user in GS> /etc/apache2/envvars - and the user is www-data.] GS> So, to spoon-feed you - you'll need to chown the files to something GS> like smokeping:www-data GS> --- GS> 3) Master-slave setups: GS> 3A) Why is the master polling a target I only want the slave to poll? GS> [Because you told it to? Or rather, because you didn't tell it not to! GS> See: nomasterpoll in the docs, here: GS> http://oss.oetiker.ch/smokeping/doc/smokeping_config.en.html ] GS> 3B) Why are my graphs empty for the slaves? GS> See 1 & 2 above GS> But master-slave has one additional wrinkle - though the principles GS> are the same. GS> For slaves, smokeping IS NOT writing the data to the RRD files - GS> they're getting pushed there by the web-server. GS> So, in master-slave mode you need to be sure that the user your GS> web-server is running as [apache perhaps] has *WRITE* permissions to GS> the RRD files. GS> Also, if you simply go mod the permissions and then you add *new* GS> slave targets, those new slave RRD files won't have the right GS> permissions. GS> So you either have to simply handle that, or tweak things so the new GS> RRD's get created with the appropriate level of permissions. GS> Now, you will need to check what the master is writing with --debug. GS> The slaves will log problems writing in the web-server logs. GS> And the *output* of graphs will likely show the problem, also in the GS> web-server logs. GS> [Though if you fix the writing problem you're probably not going to GS> have a problem reading them. A clear sign of a slave write problem is GS> if the master plots graph fine, but the slaves don't.] GS> --- GS> HTH GS> -Greg DM>> On 4 October 2013 23:03, Gregory Sloop wrote: >>> I've been working on a "usual-screw-ups" FAQ: >>> DM>> https://github.com/oetiker/SmokePing/issues/11 DM>> I opened the above issue quite a while ago, with all the best DM>> intentions.... oh well :( DM>> You may want to add your FAQ to that. DM>> cheers, DM>> Darren -- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice: 503.251.0452 x82 EMail: gregs at sloop.net http://www.sloop.net --- From paul.mansfield+smokeping at grapeshot.co.uk Mon Oct 7 12:09:44 2013 From: paul.mansfield+smokeping at grapeshot.co.uk (Paul Mansfield) Date: Mon, 7 Oct 2013 11:09:44 +0100 Subject: [smokeping-users] Graph but no results In-Reply-To: <524EF493.8090906@commspeed.net> References: <524DB860.1010408@commspeed.net> <524EC41B.8080607@commspeed.net> <524ECCC0.6010303@commspeed.net> <645136836.20131004074834@sloop.net> <524EDDA7.7070106@commspeed.net> <1054121104.20131004084612@sloop.net> <524EF493.8090906@commspeed.net> Message-ID: On 4 October 2013 18:02, Tony DeMatteis wrote: > So I ran smokeping in debug mode. Interesting... Smokeping isn't > getting any data to update the rrd with. > > I have found that if you run the slaves in debug mode and restart the master (e.g. due to config change) then the slaves seem to get stuck and cease sending updates. Getting to that discovery cost me some grey hairs! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131007/12b43abe/attachment.htm From charlesghopkins at gmail.com Wed Oct 9 18:18:02 2013 From: charlesghopkins at gmail.com (Hopkins, Charles G.) Date: Wed, 9 Oct 2013 12:18:02 -0400 Subject: [smokeping-users] Smokeping - Why 20 pings? Message-ID: I'm sure this has probably been asked before, but why was the number 20 chosen as the number of pings to use for SmokePing? I am trying to justify not changing this setting as our network admins are complaining about the number of outbound ICMP packets generated by the product we are using (OpenNMS) which uses this functionality. Thanks in advance. In the meantime I will keep on Googling for an answer. Sincerely, *Chaz* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131009/0e22cfc7/attachment.htm From mailinglists at rednarb.com Wed Oct 9 18:28:41 2013 From: mailinglists at rednarb.com (Eric Brander) Date: Wed, 9 Oct 2013 10:28:41 -0600 Subject: [smokeping-users] Smokeping - Why 20 pings? In-Reply-To: References: Message-ID: On Wed, Oct 9, 2013 at 10:18 AM, Hopkins, Charles G. < charlesghopkins at gmail.com> wrote: > I'm sure this has probably been asked before, but why was the number 20 > chosen as the number of pings to use for SmokePing? > > Sincerely, > > *Chaz* > > The more data you have, the more the smoke is more relevant. Since the smoke is essentially measuring jitter, or at least the variance between multiple ping response times, the more that are tested and recorded the more useful the data can be. Plus you can set the size of the pings to something smaller if it helps but really, if your network can't handle that many pings then there is something else to be concerned about. If pings are making the top of any utilization graph then I would guess that network path isn't very highly utilized at all and there really shouldn't be anything to worry about. Sure, oodles and oodles of pings can look daunting, especially to a nubile network admin who just got a hold of wireshark or netflow for the first time... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131009/7d5f145f/attachment.htm From gregs at sloop.net Wed Oct 9 18:36:16 2013 From: gregs at sloop.net (Gregory Sloop) Date: Wed, 9 Oct 2013 09:36:16 -0700 Subject: [smokeping-users] Smokeping - Why 20 pings? In-Reply-To: References: Message-ID: <985330648.20131009093616@sloop.net> An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131009/746e2b64/attachment-0001.htm From paul.mansfield+smokeping at grapeshot.co.uk Wed Oct 9 18:37:40 2013 From: paul.mansfield+smokeping at grapeshot.co.uk (Paul Mansfield) Date: Wed, 9 Oct 2013 17:37:40 +0100 Subject: [smokeping-users] Smokeping - Why 20 pings? In-Reply-To: References: Message-ID: using icmp echo request, ping, tests round trip time, but it can also test whether the device being pinged is very busy since many devices give the lowest priority to responding to echo requests. On 9 October 2013 17:28, Eric Brander wrote: > especially to a nubile network admin who you are very lucky having nubile network admins. or maybe you misunderstand what nubile means. A Google image search for nubile is not safe for work!!!! From gert at space.net Wed Oct 9 18:56:43 2013 From: gert at space.net (Gert Doering) Date: Wed, 9 Oct 2013 18:56:43 +0200 Subject: [smokeping-users] Smokeping - Why 20 pings? In-Reply-To: References: Message-ID: <20131009165643.GX65295@Space.Net> Hi, On Wed, Oct 09, 2013 at 12:18:02PM -0400, Hopkins, Charles G. wrote: > I am trying to justify not changing this setting as our network admins are > complaining about the number of outbound ICMP packets generated by the > product we are using (OpenNMS) which uses this functionality. Just as another data point: we are considering changing our measurements to send 1 ping *per second* *per device* - for some 100-odd devices, this might sound like a lot on "raw packet statistics", but it's still well below 100kbit/s - and we're talking gbit and 10gbit infrastructure, so hardly visible unless you look. (No, we're not doing this with smokeping, as anything that needs to fork off external jobs to do this won't get this done the way we hope it'll turn out - we'll write something ourselfs with one "send packets at regular intervals" process and one "look what's coming back, and make real-time statistics from it" process) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From ITheodoridis at bankofgreece.gr Thu Oct 10 12:08:35 2013 From: ITheodoridis at bankofgreece.gr (ITheodoridis at bankofgreece.gr) Date: Thu, 10 Oct 2013 13:08:35 +0300 Subject: [smokeping-users] Graph but no results Message-ID: <5B6967F6EA05614489E63202C9F6C18004E2FECD@mkexc01.bankofgreece.gr> When I was messing with the telnetiosping module, I used perl scripts to simulate the telnetios commands when I needed troubleshooting (the module itself is a perl script). It led me to make some changes to the module to suit my network configurations (the cisco configs). If you can get a proper output (the numbers that result from the ping output) you should be able to put them in a graph. The module parses the output and creates an array. That array is used to feed the graph. I'm taking a guess it's your cisco config that is not compatible with the module. But it can be fixed. I have also been using the rttmon module that uses SNMP to produce the same effect. It's a more standard interface, less prone to errors and it will not create telnet traps when it measures. However you do need to enable SNMP write access to your devices. It's quite a common way to measure a path's latency originating from a cisco device, used by a lot of tools. From: Tony DeMatteis [mailto:tonyd at commspeed.net] Sent: Friday, October 04, 2013 8:02 PM To: Greg Sloop Cc: smokeping-users at lists.oetiker.ch Subject: Re: [smokeping-users] Graph but no results The debug was actually directly from the TelnetIOSPing.pm. I simply uncommented a few statements and changed the path/filename and included the $source at the top to clearly delineate the host it was printing output from the Extended Ping results. So I ran smokeping in debug mode. Interesting... Smokeping isn't getting any data to update the rrd with. pattern match timed-out at /usr/share/perl5/Smokeping/probes/TelnetIOSPing.pm line 172 TelnetIOSPing: : got Calling RRDs::update(/var/lib/smokeping/Network/core_to_esedo/esedo_to_mesa_rtr. rrd --template uptime:loss:median:ping1:ping2:ping3:ping4:ping5:ping6:ping7:ping8:ping9 :ping10:ping11:ping12:ping13:ping14:ping15:ping16:ping17:ping18:ping19:p ing20 1380903220:U:20:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U:U) It would appear that there is a problem waiting for the prompt after issuing the "Terminal Length 0" command What's odd is that a running log of the ping command output shows results for the connected host as I showed in my original post. I know from everybody else's point of view, your's included, that the obvious question "are you sure your seeing the output from the host you think you are?". Reasonable question. I don't know how I could be seeing otherwise, the debug print statements follow the $telnet-> yada yada statements and result. Ok, so the debug indicates there are no results due to a problem getting to the ping command (line179 - $telnet->waitfor('/[\@\w\-\.]+[>#][ ]*$/');) . So I do the login to the router manually and it works (using the password from the Probe config file for the smokeping user). It doesn't appear to be an authentication issue... BTW - I use tacacs, and every router is auth'ing against the same source root at smokeping1:/etc/smokeping# ssh smokeping at cr1.esedo ************************************************************ | | ||| ||| ||||| ||||| .....:|||||||:.....:|||||||:..... C i s c o S y s t e m s ************************************************************ Company = Site Name = ESEDO Location = Device Name = cr1.esedo FQDN = cr1.esedo..net (ins: cr1.esedo) Contact = ************************************************************ \\|// (o o) -----oOO---(^)------------ *********************************************************** * WARNING: This is a controlled access system... * * * Access to this equipment is restricted to * authorized employees only. Any intrusions or misuse will * be prosecuted to the fullest extent of local, state & * federal law. * * All activities on this network are logged!!! * * * If you are not an authorized user, disconnect now!! *********************************************************** ------------------oOO----- |__| |__| | | | | Password: cr1.esedo>en Password: cr1.esedo#ping Protocol [ip]: Target IP address: Repeat count [5]: 20 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: v Loose, Strict, Record, Timestamp, Verbose[V]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 20, 100-byte ICMP Echos to , timeout is 2 seconds: Reply to request 0 (4 ms) Reply to request 1 (8 ms) Reply to request 2 (4 ms) Reply to request 3 (12 ms) Reply to request 4 (12 ms) Reply to request 5 (8 ms) Reply to request 6 (8 ms) Reply to request 7 (8 ms) Reply to request 8 (4 ms) Reply to request 9 (8 ms) Reply to request 10 (4 ms) Reply to request 11 (8 ms) Reply to request 12 (4 ms) Reply to request 13 (4 ms) Reply to request 14 (4 ms) Reply to request 15 (8 ms) Reply to request 16 (4 ms) Reply to request 17 (8 ms) Reply to request 18 (8 ms) Reply to request 19 (8 ms) Success rate is 100 percent (20/20), round-trip min/avg/max = 4/6/12 ms cr1.esedo# On 10/04/2013 08:46 AM, Gregory Sloop wrote: The "debug" you sent was from *your* script, not a smokeping --debug, right. Have you run smokeping --debug and watched the data/logs it returns? Again, usually the problems are: writing the data to the RRD - and running smokeping in debug mode will show you what's happening here: [or for a slave - the apache + apache-error logs] - or - reading the data from the RRD for presentation - and the apache [and the apache error] logs will show you this. So, if you're sure there's no read problem, then I think we're back to making sure that real data is hitting the RRD and a smokeping --debug would probably be enlightening. -Greg Hi Greg, It's odd because both targets were added to the conf at the same time and are under the same parent. It would be strange that one rrd file would be writable/readable while to other not. However, looking at the suggestions you offered, I don't see any errors/problems with file permissions or entries in the apache log. # It would appear the rrd files have the proper permissions. Same owner:user for esedo_to_x (which does not display data in graph) as pvdc_to_x (which does display data in graph). The files are also being updated. Is there something here or elsewhere I am missing? Thank you again.... root at smokeping1:/home/tonyd# ll /var/lib/smokeping/Network/core_to_esedo total 23388 drwxr-xr-x 2 smokeping smokeping 4096 Oct 2 22:49 ./ drwxr-xr-x 6 smokeping smokeping 4096 Oct 2 10:53 ../ -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_foothills_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_mesa_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_montezona_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 esedo_to_voc_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 mm_to_foothills_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_esedo_core.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_mesa_rtr.rrd -rw-r--r-- 1 smokeping smokeping 2986808 Oct 4 08:13 pvdc_to_voc_rtr.rrd # This does not display data tail -f /var/log/apache2/access.log - - [04/Oct/2013:08:07:12 -0700] "GET /cgi-bin/smokeping.cgi?target=Network.core_to_esedo.esedo_to_mesa_rtr HTTP/1.1" 200 2010 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo " "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_86400.png HTTP/1.1" 200 21541 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_2592000.p ng HTTP/1.1" 200 22492 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_31536000. png HTTP/1.1" 200 22418 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_604800.pn g HTTP/1.1" 200 20330 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_10800.png HTTP/1.1" 200 21382 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:13 -0700] "GET /smokeping/images/Network/core_to_esedo/esedo_to_mesa_rtr_last_43200.png HTTP/1.1" 200 20971 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .esedo_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:07:14 -0700] "GET /favicon.ico HTTP/1.1" 404 501 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" # This displays data - - [04/Oct/2013:08:14:14 -0700] "GET /cgi-bin/smokeping.cgi?target=Network.core_to_esedo.pvdc_to_mesa_rtr HTTP/1.1" 200 2005 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo " "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_2592000.pn g HTTP/1.1" 200 25540 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_10800.png HTTP/1.1" 200 26251 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_43200.png HTTP/1.1" 200 29813 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_604800.png HTTP/1.1" 200 27440 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_31536000.p ng HTTP/1.1" 200 22782 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /smokeping/images/Network/core_to_esedo/pvdc_to_mesa_rtr_last_86400.png HTTP/1.1" 200 34500 "http://216.19.19.135/cgi-bin/smokeping.cgi?target=Network.core_to_esedo .pvdc_to_mesa_rtr" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [04/Oct/2013:08:14:16 -0700] "GET /favicon.ico HTTP/1.1" 404 501 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" On 10/04/2013 07:48 AM, Gregory Sloop wrote: Have you checked the apache logs to see if it can actually read the RRD files to get the data you want? Usually when there's an "empty" graph the problem is one of two things: 1) smokeping can't write the data to the RRD. 2) the web-server can't read it. If you've really debugged things and you're sure it's successfully writing to the RRD, then you'd want to watch the web-server logs and see if it's really reading them. -Greg I meant to include my Probe definition. +TelnetIOSPing forks = 5 offset = 50% packetsize = 56 step = 300 timeout = 10 iospass = iosuser = smokeping pings = 20 Hello, Maybe someone could provide me with some assistance. I have a host/Target graph that get's created and populates the web page. However, no results appear on the graph. I am using the TelnetIOSPing probe. I have a number of other hosts/Targets that are using this probe. I have kicked out some debug results from /usr/share/perl5/Smokeping/probes/TelnetIOSPing.pm and the host is reachable and I see ping results, but they don't make it into the graph. In addition, no errors related to said host, are showing in the smokeping.log. Any ideas? Thank you! open(OUTF,">>/tmp/TelnetIOSPing.debug") || die "Can't open OUTF: $!"; print OUTF "target => $dest\nsource => $source\nuser => $login\n"; my $ok = $telnet->open(Host => $source, Port => $port); print OUTF "\n"; print OUTF "===========================\n"; print OUTF "Connection to $source $ok\n"; print OUTF "\n"; #---- Code that does the log in and executes extended ping $telnet->prompt('/[\@\w\-\.]+[>#][ ]*$/'); @output = $telnet->cmd("n"); #$telnet->waitfor('/[\@\w\-\.]+[>#][ ]*$/'); $telnet->print("quit"); $telnet->close; print OUTF "closed Telnet connection\n"; my @times = (); while (@output) { my $outputline = shift @output; chomp($outputline); print OUTF "$outputline\n"; $outputline =~ /^Reply to request \d+ \((\d+) ms\)/ && push(@times,$1); print OUTF "$outputline => $1\n"; } <<< I see data in graph from this Target >>> +++ pvdc_to_mesa_rtr menu = Core to eSedo MESA RTR title = Core Router to eSedo MESA RTR probe = TelnetIOSPing host = source = =========================== Connection to 1 closed Telnet connection Type escape sequence to abort. Type escape sequence to abort. => Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => Reply to request 0 (1 ms) Reply to request 0 (1 ms) => 1 Reply to request 1 (4 ms) Reply to request 1 (4 ms) => 4 Reply to request 2 (1 ms) Reply to request 2 (1 ms) => 1 Reply to request 3 (1 ms) Reply to request 3 (1 ms) => 1 Reply to request 4 (1 ms) Reply to request 4 (1 ms) => 1 Reply to request 5 (1 ms) Reply to request 5 (1 ms) => 1 Reply to request 6 (1 ms) Reply to request 6 (1 ms) => 1 Reply to request 7 (1 ms) Reply to request 7 (1 ms) => 1 Reply to request 8 (4 ms) Reply to request 8 (4 ms) => 4 Reply to request 9 (1 ms) Reply to request 9 (1 ms) => 1 Reply to request 10 (1 ms) Reply to request 10 (1 ms) => 1 Reply to request 11 (1 ms) Reply to request 11 (1 ms) => 1 Reply to request 12 (1 ms) Reply to request 12 (1 ms) => 1 Reply to request 13 (1 ms) Reply to request 13 (1 ms) => 1 Reply to request 14 (1 ms) Reply to request 14 (1 ms) => 1 Reply to request 15 (1 ms) Reply to request 15 (1 ms) => 1 Reply to request 16 (1 ms) Reply to request 16 (1 ms) => 1 Reply to request 17 (1 ms) Reply to request 17 (1 ms) => 1 Reply to request 18 (1 ms) Reply to request 18 (1 ms) => 1 Reply to request 19 (4 ms) Reply to request 19 (4 ms) => 4 Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms Success rate is 100 percent (20/20), round-trip min/avg/max = 1/1/4 ms => 4 target => source => user => smokeping <<< I DO NOT see data in graph from this Target >>> +++ esedo_to_mesa_rtr menu = esedo Core to eSedo MESA title = eSedo Core Router to eSedo MESA RTR probe = TelnetIOSPing host = source = =========================== Connection to 1 closed Telnet connection Type escape sequence to abort. Type escape sequence to abort. => Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: Sending 20, 56-byte ICMP Echos to , timeout is 2 seconds: => Reply to request 0 (60 ms) Reply to request 0 (60 ms) => 60 Reply to request 1 (52 ms) Reply to request 1 (52 ms) => 52 Reply to request 2 (24 ms) Reply to request 2 (24 ms) => 24 Reply to request 3 (64 ms) Reply to request 3 (64 ms) => 64 Reply to request 4 (56 ms) Reply to request 4 (56 ms) => 56 Reply to request 5 (40 ms) Reply to request 5 (40 ms) => 40 Reply to request 6 (44 ms) Reply to request 6 (44 ms) => 44 Reply to request 7 (60 ms) Reply to request 7 (60 ms) => 60 Reply to request 8 (40 ms) Reply to request 8 (40 ms) => 40 Reply to request 9 (36 ms) Reply to request 9 (36 ms) => 36 Reply to request 10 (20 ms) Reply to request 10 (20 ms) => 20 Reply to request 11 (20 ms) Reply to request 11 (20 ms) => 20 Reply to request 12 (28 ms) Reply to request 12 (28 ms) => 28 Reply to request 13 (28 ms) Reply to request 13 (28 ms) => 28 Reply to request 14 (36 ms) Reply to request 14 (36 ms) => 36 Reply to request 15 (20 ms) Reply to request 15 (20 ms) => 20 Reply to request 16 (20 ms) Reply to request 16 (20 ms) => 20 Reply to request 17 (8 ms) Reply to request 17 (8 ms) => 8 Reply to request 18 (20 ms) Reply to request 18 (20 ms) => 20 Reply to request 19 (44 ms) Reply to request 19 (44 ms) => 44 Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 ms Success rate is 100 percent (20/20), round-trip min/avg/max = 8/36/64 ms => 44 target => source => user => smokeping _______________________________________________ smokeping-users mailing list smokeping-users at lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users -- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice: 503.251.0452 x82 EMail: gregs at sloop.net http://www.sloop.net --- -- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice: 503.251.0452 x82 EMail: gregs at sloop.net http://www.sloop.net --- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131010/218b02bc/attachment-0001.htm -------------- next part -------------- ============================================================================================================== ?? ??? ????????? ?????? ??????? ??????????? ???. ???? ?????? ???????????? ???????????? ??? ??? ??????? ??? ??????? (???) ???????????? ????????? ???? ??? ?? ???????? ???? ??????????? ?? ?? ?????????? ? ???????? ????????? ? ???? ???????? ??? ???. ?? ?????? ???????????? ???????????? ??????????? ???? ???????????? ????? ??? ????????, ??? ?????? ? ????????? ??????????? ???? ??????????? ??? ?????????. ? ?????????? ??? ? ??? ??? ???????????? ?????? ?????? ??? ???????????, ????????? ??? ????????????, ??????? ? ????????????? ????????? ??? ?????????, ??? ???????, ??????? ? ?????????? ??? ????????? ? ??? ????????? ????? ??? ??? ???? ?? ????? ??? ????? ??????? ? ????? ?????? ??? ??? ??? ????? ???????????? ??????. ??? ?????? ???? ????? ?? ????? ?????? ???????????? ????????????, ??????????? ?? ???????????? ?????? ???? ???????????? ???????????? ??? ????????? ??? ?? ?????????? ?? ??????. ??????????? ??????????, ??????? ? ????? ?????? ? ????????? ??? ????????? ????? ????? ???????????? ??????? ??? ?????? ?? ???????? ??????? ??? ?????? ??????. Any e-mail message from the Bank of Greece (BoG) is sent in good faith but shall neither be binding nor construed as constituting or affecting a contractual arrangement or other commitment by the BoG. The e-mail is intended for the exclusive use of the person whose e-mail address appears in caption as recipient. The sender and the BoG decline liability for inaccuracy, breach of integrity, loss or delayed delivery of the message, for any failure in, interruption to or degradation of either the service or the message, as well as for any loss or damage sustained thereof to the fullest extent provided by law. If this e-mail was not intended for you, please notify the sender immediately via e-mail and delete it at once. Any unauthorized disclosure, dissemination or use, either in whole or in part is strictly prohibited and may give rise to both criminal and civil liability. All rights reserved. ============================================================================================================== From ITheodoridis at bankofgreece.gr Thu Oct 10 12:13:07 2013 From: ITheodoridis at bankofgreece.gr (ITheodoridis at bankofgreece.gr) Date: Thu, 10 Oct 2013 13:13:07 +0300 Subject: [smokeping-users] Smokeping - Why 20 pings? Message-ID: <5B6967F6EA05614489E63202C9F6C18004E2FED4@mkexc01.bankofgreece.gr> I would be expecting security people to worry if it's a compromised host scanning the network (that has happened to me) but not the network admins.. I totally agree with Eric. From: Eric Brander [mailto:mailinglists at rednarb.com] Sent: Wednesday, October 09, 2013 7:29 PM To: Hopkins, Charles G. Cc: smokeping-users at lists.oetiker.ch Subject: Re: [smokeping-users] Smokeping - Why 20 pings? On Wed, Oct 9, 2013 at 10:18 AM, Hopkins, Charles G. wrote: I'm sure this has probably been asked before, but why was the number 20 chosen as the number of pings to use for SmokePing? Sincerely, Chaz The more data you have, the more the smoke is more relevant. Since the smoke is essentially measuring jitter, or at least the variance between multiple ping response times, the more that are tested and recorded the more useful the data can be. Plus you can set the size of the pings to something smaller if it helps but really, if your network can't handle that many pings then there is something else to be concerned about. If pings are making the top of any utilization graph then I would guess that network path isn't very highly utilized at all and there really shouldn't be anything to worry about. Sure, oodles and oodles of pings can look daunting, especially to a nubile network admin who just got a hold of wireshark or netflow for the first time... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131010/9e305c90/attachment.htm -------------- next part -------------- ============================================================================================================== ?? ??? ????????? ?????? ??????? ??????????? ???. ???? ?????? ???????????? ???????????? ??? ??? ??????? ??? ??????? (???) ???????????? ????????? ???? ??? ?? ???????? ???? ??????????? ?? ?? ?????????? ? ???????? ????????? ? ???? ???????? ??? ???. ?? ?????? ???????????? ???????????? ??????????? ???? ???????????? ????? ??? ????????, ??? ?????? ? ????????? ??????????? ???? ??????????? ??? ?????????. ? ?????????? ??? ? ??? ??? ???????????? ?????? ?????? ??? ???????????, ????????? ??? ????????????, ??????? ? ????????????? ????????? ??? ?????????, ??? ???????, ??????? ? ?????????? ??? ????????? ? ??? ????????? ????? ??? ??? ???? ?? ????? ??? ????? ??????? ? ????? ?????? ??? ??? ??? ????? ???????????? ??????. ??? ?????? ???? ????? ?? ????? ?????? ???????????? ????????????, ??????????? ?? ???????????? ?????? ???? ???????????? ???????????? ??? ????????? ??? ?? ?????????? ?? ??????. ??????????? ??????????, ??????? ? ????? ?????? ? ????????? ??? ????????? ????? ????? ???????????? ??????? ??? ?????? ?? ???????? ??????? ??? ?????? ??????. Any e-mail message from the Bank of Greece (BoG) is sent in good faith but shall neither be binding nor construed as constituting or affecting a contractual arrangement or other commitment by the BoG. The e-mail is intended for the exclusive use of the person whose e-mail address appears in caption as recipient. The sender and the BoG decline liability for inaccuracy, breach of integrity, loss or delayed delivery of the message, for any failure in, interruption to or degradation of either the service or the message, as well as for any loss or damage sustained thereof to the fullest extent provided by law. If this e-mail was not intended for you, please notify the sender immediately via e-mail and delete it at once. Any unauthorized disclosure, dissemination or use, either in whole or in part is strictly prohibited and may give rise to both criminal and civil liability. All rights reserved. ============================================================================================================== From mailinglists at rednarb.com Thu Oct 10 15:15:30 2013 From: mailinglists at rednarb.com (Eric Brander) Date: Thu, 10 Oct 2013 07:15:30 -0600 Subject: [smokeping-users] Smokeping - Why 20 pings? In-Reply-To: References: Message-ID: On Wed, Oct 9, 2013 at 10:37 AM, Paul Mansfield < paul.mansfield+smokeping at grapeshot.co.uk> wrote: > > On 9 October 2013 17:28, Eric Brander wrote: > > especially to a nubile network admin who > > > you are very lucky having nubile network admins. > > or maybe you misunderstand what nubile means. A Google image search > for nubile is not safe for work!!!! > > Wow, now that's funny! In my head I was writing newbie, not sure how the heck nubile came out but I'm blaming spell-check!!! On the topic of pings though - I also ran a 5-ping 1500-byte ping test every 5 minutes on some sites as I've had problems where small packets work just fine but larger ones get squashed. I think it was buggy code on a 4506 Sup II but my memory is foggy on that. Too many nubiles cluttering my thoughts. :D -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131010/1199538d/attachment.htm From mellonr at hobart.k12.in.us Thu Oct 17 22:19:55 2013 From: mellonr at hobart.k12.in.us (Russell Mellon) Date: Thu, 17 Oct 2013 15:19:55 -0500 Subject: [smokeping-users] prevent "### parsing dig output ..." Message-ID: When using the DNS probe, smoke ping spits out the line ### parsing big output...OK It's from line 61 of the DNS.pm module. Glancing at the code it looks like there's no way prevent it from printing that line. Is this a left-over debug output? Russell Mellon Director of I.T. Services School City of Hobart mellonr at hobart.k12.in.us 219-712-0525 [cid:image001.jpg at 01CECB4C.55931A60] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/0dc32841/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 14841 bytes Desc: image001.jpg Url : http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/0dc32841/attachment-0001.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: Mr Russell Mellon.vcf Type: text/x-vcard Size: 18105 bytes Desc: Mr Russell Mellon.vcf Url : http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/0dc32841/attachment-0001.vcf From JBracey at csuchico.edu Thu Oct 17 23:59:34 2013 From: JBracey at csuchico.edu (Bracey, John) Date: Thu, 17 Oct 2013 14:59:34 -0700 Subject: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 Message-ID: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096D@EXMAIL.csuchico.edu> Hello all: After upgrading my Ubuntu server this morning to 13.10, all of my smokeping graphs are showing up as broken links. The web log on the server show 404 errors: 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_portal_mini.png HTTP/1.1" 404 532 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_mesh_bridge_mini.png HTTP/1.1" 404 537 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_point_mini.png HTTP/1.1" 404 531 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/smokeping.png HTTP/1.1" 404 514 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/rrdtool.png HTTP/1.1" 404 513 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" Is there somewhere I need to adjust a path? It seems like the files are there in /usr/share/smokeping/www/images/ I looked in the pathnames file and those paths seem to check out as well: root at s42090:/usr/share/smokeping/www/images/LIDAR_APs# cat /etc/smokeping/config.d/pathnames sendmail = /usr/sbin/sendmail imgcache = /var/cache/smokeping/images imgurl = ../smokeping/images datadir = /var/lib/smokeping piddir = /var/run/smokeping smokemail = /etc/smokeping/smokemail tmail = /etc/smokeping/tmail Thanks in advance. ********************************************************* John K. Bracey, Sr. Network Analyst Communications Services / Network Operations California State University, Chico 530-898-5400 ********************************************************* P Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/95099ec7/attachment.htm From gregs at sloop.net Fri Oct 18 00:39:39 2013 From: gregs at sloop.net (Gregory Sloop) Date: Thu, 17 Oct 2013 15:39:39 -0700 Subject: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 In-Reply-To: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096D@EXMAIL.csuchico.edu> References: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096D@EXMAIL.csuchico.edu> Message-ID: <1408025194.20131017153939@sloop.net> An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/f1d67d49/attachment.htm From gregs at sloop.net Fri Oct 18 00:45:47 2013 From: gregs at sloop.net (Gregory Sloop) Date: Thu, 17 Oct 2013 15:45:47 -0700 Subject: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 In-Reply-To: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096D@EXMAIL.csuchico.edu> References: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096D@EXMAIL.csuchico.edu> Message-ID: <1875671079.20131017154547@sloop.net> An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/4658372a/attachment-0001.htm From JBracey at csuchico.edu Fri Oct 18 00:45:37 2013 From: JBracey at csuchico.edu (Bracey, John) Date: Thu, 17 Oct 2013 15:45:37 -0700 Subject: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 In-Reply-To: <1875671079.20131017154547@sloop.net> References: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096D@EXMAIL.csuchico.edu> <1875671079.20131017154547@sloop.net> Message-ID: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096F@EXMAIL.csuchico.edu> Thanks Greg. I will check out these options. -John From: Gregory Sloop [mailto:gregs at sloop.net] Sent: Thursday, October 17, 2013 3:46 PM To: Bracey, John Cc: 'smokeping-users at lists.oetiker.ch' Subject: Re: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 Oh, and on a related note: It might be a selinux problem - if in question, simply disable SELinux and see what happens. If that solves it, then either leave SEL in permissive mode, disable it completely, or write a rule to allow what needs allowing. -Greg Hello all: After upgrading my Ubuntu server this morning to 13.10, all of my smokeping graphs are showing up as broken links. The web log on the server show 404 errors: 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_portal_mini.png HTTP/1.1" 404 532 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_mesh_bridge_mini.png HTTP/1.1" 404 537 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_point_mini.png HTTP/1.1" 404 531 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/smokeping.png HTTP/1.1" 404 514 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/rrdtool.png HTTP/1.1" 404 513 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" Is there somewhere I need to adjust a path? It seems like the files are there in /usr/share/smokeping/www/images/ I looked in the pathnames file and those paths seem to check out as well: root at s42090:/usr/share/smokeping/www/images/LIDAR_APs# cat /etc/smokeping/config.d/pathnames sendmail = /usr/sbin/sendmail imgcache = /var/cache/smokeping/images imgurl = ../smokeping/images datadir = /var/lib/smokeping piddir = /var/run/smokeping smokemail = /etc/smokeping/smokemail tmail = /etc/smokeping/tmail Thanks in advance. ********************************************************* John K. Bracey, Sr. Network Analyst Communications Services / Network Operations California State University, Chico 530-898-5400 ********************************************************* PPlease consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/0544eb79/attachment.htm From errr.errr at gmail.com Fri Oct 18 00:58:52 2013 From: errr.errr at gmail.com (Michael Rice) Date: Thu, 17 Oct 2013 17:58:52 -0500 Subject: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 In-Reply-To: <1875671079.20131017154547@sloop.net> References: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096D@EXMAIL.csuchico.edu> <1875671079.20131017154547@sloop.net> Message-ID: <8679936434757703151@unknownmsgid> Isn't it called AppArmor or something like that on Ubuntu? Thanks Mike On Oct 17, 2013, at 17:42, Gregory Sloop wrote: Re: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 Oh, and on a related note: It might be a selinux problem - if in question, simply disable SELinux and see what happens. If that solves it, then either leave SEL in permissive mode, disable it completely, or write a rule to allow what needs allowing. -Greg Hello all: After upgrading my Ubuntu server this morning to 13.10, all of my smokeping graphs are showing up as broken links. The web log on the server show 404 errors: 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_portal_mini.png HTTP/1.1" 404 532 " http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_mesh_bridge_mini.png HTTP/1.1" 404 537 " http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_point_mini.png HTTP/1.1" 404 531 " http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/smokeping.png HTTP/1.1" 404 514 " http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/rrdtool.png HTTP/1.1" 404 513 " http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" Is there somewhere I need to adjust a path? It seems like the files are there in /usr/share/smokeping/www/images/ I looked in the pathnames file and those paths seem to check out as well: root at s42090:/usr/share/smokeping/www/images/LIDAR_APs# cat /etc/smokeping/config.d/pathnames sendmail = /usr/sbin/sendmail imgcache = /var/cache/smokeping/images imgurl = ../smokeping/images datadir = /var/lib/smokeping piddir = /var/run/smokeping smokemail = /etc/smokeping/smokemail tmail = /etc/smokeping/tmail Thanks in advance. ********************************************************* John K. Bracey, Sr. Network Analyst Communications Services / Network Operations California State University, Chico 530-898-5400 ********************************************************* *PPlease consider the environment before printing this email. * _______________________________________________ smokeping-users mailing list smokeping-users at lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/17eb3866/attachment.htm From simonjai at gmail.com Fri Oct 18 01:03:46 2013 From: simonjai at gmail.com (Simon Liang) Date: Fri, 18 Oct 2013 10:03:46 +1100 Subject: [smokeping-users] Smokeping FastCGI Woes Message-ID: Hi there, I've been running an early 2.6 version of Smokeping and recently decided to upgrade to the latest 2.6.9. The polling side of Smokeping is rock solid, however it's quite the opposite with the change to FastCGI. I thought this would be a good place to start and hope someone can help me. Just some background of my current setup. I have separated the Polling (forked with FPing) and web service side of Smokeping into two VMs (to reduce the load the server). The config files are rsynced from the poller to the web and the RRD files are shared via NFS. Poller VM - 8 vCPU, 16GB RAM Web VM - 4 vCPU, 16GB RAM I understand when the web side of Smokeping starts (after a config change), it does a lot of things under the hood. To address this issue, on restarts I create an IP table rule on the web server so only the poller can access it via port 80, I then use curl to trigger the first (and only) session. Once it's completed I remove the IP table rule so it becomes accessible. This works quite work and everything works fine. But after a random period of time, the load on the web server spikes up quite high, memory starts swapping and the server becomes almost unresponsive. This is a screenshot of the web server under load (before I upgraded to 16GB RAM) https://dl.dropboxusercontent.com/u/11792766/Work/smokeping_load.JPG The spikes in the graph are when the load on the server just randomly spikes up and I'm forced to restart Smokeping manually. https://dl.dropboxusercontent.com/u/11792766/Work/smokeping_stats.JPG I can assure you there are no cron jobs running which may be loading up the server. On peak hour traffic I have maybe 100 requests per minute. Here is my Apache (fcgid) config: http://pastebin.com/QU6XRcFg If you need any more information please let me know. Cheers, Simon From gregs at sloop.net Fri Oct 18 01:11:18 2013 From: gregs at sloop.net (Gregory Sloop) Date: Thu, 17 Oct 2013 16:11:18 -0700 Subject: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 In-Reply-To: <8679936434757703151@unknownmsgid> References: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096D@EXMAIL.csuchico.edu> <1875671079.20131017154547@sloop.net> <8679936434757703151@unknownmsgid> Message-ID: <1546183550.20131017161118@sloop.net> An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/019d65eb/attachment.htm From JBracey at csuchico.edu Fri Oct 18 01:15:22 2013 From: JBracey at csuchico.edu (Bracey, John) Date: Thu, 17 Oct 2013 16:15:22 -0700 Subject: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 In-Reply-To: <1546183550.20131017161118@sloop.net> References: <755A73D3547BAE429728E2EC2AEDC605F4D4BC096D@EXMAIL.csuchico.edu> <1875671079.20131017154547@sloop.net> <8679936434757703151@unknownmsgid> <1546183550.20131017161118@sloop.net> Message-ID: <755A73D3547BAE429728E2EC2AEDC605F4D4BC0975@EXMAIL.csuchico.edu> I did try the apparmor thing and that wasn't it. still need to run it in debug mode though and see what that tells me. Thanks again for the suggestions! :) -John From: Gregory Sloop [mailto:gregs at sloop.net] Sent: Thursday, October 17, 2013 4:11 PM To: Michael Rice Cc: Bracey, John; smokeping-users at lists.oetiker.ch Subject: Re: [smokeping-users] graphs missing after upgrade to Ubuntu Server 13.10 Yeah, I think that's right - I can't keep everything RHEL vs Deb/Ubu straight. :) I do both, but I've been hating on RHEL for a while and moving stuff to Ubuntu... [Though I'm not too fond of Shuttleworth either... sigh, what's a sysadmin to do?!] Thanks for the catch though. -Greg Isn't it called AppArmor or something like that on Ubuntu? Thanks Mike On Oct 17, 2013, at 17:42, Gregory Sloop > wrote: Oh, and on a related note: It might be a selinux problem - if in question, simply disable SELinux and see what happens. If that solves it, then either leave SEL in permissive mode, disable it completely, or write a rule to allow what needs allowing. -Greg Hello all: After upgrading my Ubuntu server this morning to 13.10, all of my smokeping graphs are showing up as broken links. The web log on the server show 404 errors: 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_portal_mini.png HTTP/1.1" 404 532 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_mesh_bridge_mini.png HTTP/1.1" 404 537 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/LIDAR_APs/lidar_point_mini.png HTTP/1.1" 404 531 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/smokeping.png HTTP/1.1" 404 514 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" 132.241.183.10 - - [17/Oct/2013:14:51:05 -0700] "GET /smokeping/images/rrdtool.png HTTP/1.1" 404 513 "http://s42090/cgi-bin/smokeping.cgi?target=LIDAR_APs" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36" Is there somewhere I need to adjust a path? It seems like the files are there in /usr/share/smokeping/www/images/ I looked in the pathnames file and those paths seem to check out as well: root at s42090:/usr/share/smokeping/www/images/LIDAR_APs# cat /etc/smokeping/config.d/pathnames sendmail = /usr/sbin/sendmail imgcache = /var/cache/smokeping/images imgurl = ../smokeping/images datadir = /var/lib/smokeping piddir = /var/run/smokeping smokemail = /etc/smokeping/smokemail tmail = /etc/smokeping/tmail Thanks in advance. ********************************************************* John K. Bracey, Sr. Network Analyst Communications Services / Network Operations California State University, Chico 530-898-5400 ********************************************************* PPlease consider the environment before printing this email. _______________________________________________ smokeping-users mailing list smokeping-users at lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/smokeping-users -- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice: 503.251.0452 x82 EMail: gregs at sloop.net http://www.sloop.net --- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131017/b6a9a322/attachment.htm From ITheodoridis at bankofgreece.gr Fri Oct 18 15:55:58 2013 From: ITheodoridis at bankofgreece.gr (ITheodoridis at bankofgreece.gr) Date: Fri, 18 Oct 2013 16:55:58 +0300 Subject: [smokeping-users] Smokeping FastCGI Woes Message-ID: <5B6967F6EA05614489E63202C9F6C18004EA6171@mkexc01.bankofgreece.gr> Is there anything else running on the same physical server? I mean except those two VMs you are talking about. Could it be there is a resource issue there? Have you tried giving it another core and see how it goes with performance? I have had similar problems with VMs running classic MRTG (without RRD) and things got a lot better when I added another core on those VMs. I 'm definitely interested to see what answer you will get on the subject in the end. -----Original Message----- From: Simon Liang [mailto:simonjai at gmail.com] Sent: Friday, October 18, 2013 2:04 AM To: smokeping-users at lists.oetiker.ch Subject: [smokeping-users] Smokeping FastCGI Woes Hi there, I've been running an early 2.6 version of Smokeping and recently decided to upgrade to the latest 2.6.9. The polling side of Smokeping is rock solid, however it's quite the opposite with the change to FastCGI. I thought this would be a good place to start and hope someone can help me. Just some background of my current setup. I have separated the Polling (forked with FPing) and web service side of Smokeping into two VMs (to reduce the load the server). The config files are rsynced from the poller to the web and the RRD files are shared via NFS. Poller VM - 8 vCPU, 16GB RAM Web VM - 4 vCPU, 16GB RAM I understand when the web side of Smokeping starts (after a config change), it does a lot of things under the hood. To address this issue, on restarts I create an IP table rule on the web server so only the poller can access it via port 80, I then use curl to trigger the first (and only) session. Once it's completed I remove the IP table rule so it becomes accessible. This works quite work and everything works fine. But after a random period of time, the load on the web server spikes up quite high, memory starts swapping and the server becomes almost unresponsive. This is a screenshot of the web server under load (before I upgraded to 16GB RAM) https://dl.dropboxusercontent.com/u/11792766/Work/smokeping_load.JPG The spikes in the graph are when the load on the server just randomly spikes up and I'm forced to restart Smokeping manually. https://dl.dropboxusercontent.com/u/11792766/Work/smokeping_stats.JPG I can assure you there are no cron jobs running which may be loading up the server. On peak hour traffic I have maybe 100 requests per minute. Here is my Apache (fcgid) config: http://pastebin.com/QU6XRcFg If you need any more information please let me know. Cheers, Simon -------------- next part -------------- ============================================================================================================== ?? ??? ????????? ?????? ??????? ??????????? ???. ???? ?????? ???????????? ???????????? ??? ??? ??????? ??? ??????? (???) ???????????? ????????? ???? ??? ?? ???????? ???? ??????????? ?? ?? ?????????? ? ???????? ????????? ? ???? ???????? ??? ???. ?? ?????? ???????????? ???????????? ??????????? ???? ???????????? ????? ??? ????????, ??? ?????? ? ????????? ??????????? ???? ??????????? ??? ?????????. ? ?????????? ??? ? ??? ??? ???????????? ?????? ?????? ??? ???????????, ????????? ??? ????????????, ??????? ? ????????????? ????????? ??? ?????????, ??? ???????, ??????? ? ?????????? ??? ????????? ? ??? ????????? ????? ??? ??? ???? ?? ????? ??? ????? ??????? ? ????? ?????? ??? ??? ??? ????? ???????????? ??????. ??? ?????? ???? ????? ?? ????? ?????? ???????????? ????????????, ??????????? ?? ???????????? ?????? ???? ???????????? ???????????? ??? ????????? ??? ?? ?????????? ?? ??????. ??????????? ??????????, ??????? ? ????? ?????? ? ????????? ??? ????????? ????? ????? ???????????? ??????? ??? ?????? ?? ???????? ??????? ??? ?????? ??????. Any e-mail message from the Bank of Greece (BoG) is sent in good faith but shall neither be binding nor construed as constituting or affecting a contractual arrangement or other commitment by the BoG. The e-mail is intended for the exclusive use of the person whose e-mail address appears in caption as recipient. The sender and the BoG decline liability for inaccuracy, breach of integrity, loss or delayed delivery of the message, for any failure in, interruption to or degradation of either the service or the message, as well as for any loss or damage sustained thereof to the fullest extent provided by law. If this e-mail was not intended for you, please notify the sender immediately via e-mail and delete it at once. Any unauthorized disclosure, dissemination or use, either in whole or in part is strictly prohibited and may give rise to both criminal and civil liability. All rights reserved. ============================================================================================================== From mellonr at hobart.k12.in.us Fri Oct 18 21:05:32 2013 From: mellonr at hobart.k12.in.us (Russell Mellon) Date: Fri, 18 Oct 2013 14:05:32 -0500 Subject: [smokeping-users] how can med_min, med_max and loss_max be nan Message-ID: I've been pulling info smokeinfo and I've come across times when med_min, med_max and loss_max are "nan" ./smokeinfo ../etc/smokeping.conf -filter "/Network/HS-MDF" -start now-20s -end now # node_path;med_avg;med_min;med_max;med_now;loss_avg;loss_max;loss_now /Network/HS-MDF;9.455000e-04;nan;nan;9.220000e-04;0.000000e+00;nan;0.000000e+00 What I can't figure out is how there can be a med_avg if it doesn't know the med_max and med_min. Maybe I don't understand what each of the values really mean? Russell Mellon Director of I.T. Services School City of Hobart mellonr at hobart.k12.in.us 219-712-0525 [cid:image001.jpg at 01CECC0B.1743D0F0] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131018/1b05fae8/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 14841 bytes Desc: image001.jpg Url : http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131018/1b05fae8/attachment-0001.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: Mr Russell Mellon.vcf Type: text/x-vcard Size: 18105 bytes Desc: Mr Russell Mellon.vcf Url : http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131018/1b05fae8/attachment-0001.vcf From simonjai at gmail.com Mon Oct 21 07:01:38 2013 From: simonjai at gmail.com (Simon Liang) Date: Mon, 21 Oct 2013 16:01:38 +1100 Subject: [smokeping-users] Smokeping FastCGI Woes In-Reply-To: <5B6967F6EA05614489E63202C9F6C18004EA6171@mkexc01.bankofgreece.gr> References: <5B6967F6EA05614489E63202C9F6C18004EA6171@mkexc01.bankofgreece.gr> Message-ID: Hey, They're actually on two separate blade servers. Smokeping poller is on a server by itself, and the web is also on a server by itself. There is absolutely nothing on them except Smokeping. Could it be that over a period of time, smokeping_cgi is run in which it's try to rebuild everything again? I used to run everything all on one server, so when the config gets changed I see the server lag a bit (assuming it's preparing everything again) and then will come back. However this is shouldn't be the case, as the config is only rsync'd to the web server when a restart on the poller is executed. Cheers, Simon On Sat, Oct 19, 2013 at 12:55 AM, wrote: > Is there anything else running on the same physical server? I mean > except those two VMs you are talking about. Could it be there is a > resource issue there? Have you tried giving it another core and see how > it goes with performance? I have had similar problems with VMs running > classic MRTG (without RRD) and things got a lot better when I added > another core on those VMs. > I 'm definitely interested to see what answer you will get on the > subject in the end. > > -----Original Message----- > From: Simon Liang [mailto:simonjai at gmail.com] > Sent: Friday, October 18, 2013 2:04 AM > To: smokeping-users at lists.oetiker.ch > Subject: [smokeping-users] Smokeping FastCGI Woes > > Hi there, > > I've been running an early 2.6 version of Smokeping and recently decided > to upgrade to the latest 2.6.9. The polling side of Smokeping is rock > solid, however it's quite the opposite with the change to FastCGI. I > thought this would be a good place to start and hope someone can help > me. > > Just some background of my current setup. I have separated the Polling > (forked with FPing) and web service side of Smokeping into two VMs (to > reduce the load the server). The config files are rsynced from the > poller to the web and the RRD files are shared via NFS. > > Poller VM - 8 vCPU, 16GB RAM > Web VM - 4 vCPU, 16GB RAM > > I understand when the web side of Smokeping starts (after a config > change), it does a lot of things under the hood. To address this issue, > on restarts I create an IP table rule on the web server so only the > poller can access it via port 80, I then use curl to trigger the first > (and only) session. Once it's completed I remove the IP table rule so it > becomes accessible. This works quite work and everything works fine. > > But after a random period of time, the load on the web server spikes up > quite high, memory starts swapping and the server becomes almost > unresponsive. > > This is a screenshot of the web server under load (before I upgraded to > 16GB RAM) > https://dl.dropboxusercontent.com/u/11792766/Work/smokeping_load.JPG > > The spikes in the graph are when the load on the server just randomly > spikes up and I'm forced to restart Smokeping manually. > https://dl.dropboxusercontent.com/u/11792766/Work/smokeping_stats.JPG > > I can assure you there are no cron jobs running which may be loading up > the server. On peak hour traffic I have maybe 100 requests per minute. > > Here is my Apache (fcgid) config: http://pastebin.com/QU6XRcFg > > If you need any more information please let me know. > > Cheers, > Simon > > > > ============================================================================================================== > ?? ??? ????????? ?????? ??????? ??????????? ???. ???? ?????? ???????????? > ???????????? ??? ??? ??????? ??? ??????? (???) ???????????? ????????? ???? > ??? ?? ???????? ???? ??????????? ?? ?? ?????????? ? ???????? ????????? ? > ???? ???????? ??? ???. > > ?? ?????? ???????????? ???????????? ??????????? ???? ???????????? ????? > ??? ????????, ??? ?????? ? ????????? ??????????? ???? ??????????? ??? > ?????????. ? ?????????? ??? ? ??? ??? ???????????? ?????? ?????? ??? > ???????????, ????????? ??? ????????????, ??????? ? ????????????? ????????? > ??? ?????????, ??? ???????, ??????? ? ?????????? ??? ????????? ? ??? > ????????? ????? ??? ??? ???? ?? ????? ??? ????? ??????? ? ????? ?????? ??? > ??? ??? ????? ???????????? ??????. > > ??? ?????? ???? ????? ?? ????? ?????? ???????????? ????????????, > ??????????? ?? ???????????? ?????? ???? ???????????? ???????????? ??? > ????????? ??? ?? ?????????? ?? ??????. ??????????? ??????????, ??????? ? > ????? ?????? ? ????????? ??? ????????? ????? ????? ???????????? ??????? ??? > ?????? ?? ???????? ??????? ??? ?????? ??????. > > > Any e-mail message from the Bank of Greece (BoG) is sent in good faith but > shall neither be binding nor construed as constituting or affecting a > contractual arrangement or other commitment by the BoG. > > The e-mail is intended for the exclusive use of the person whose e-mail > address appears in caption as recipient. The sender and the BoG decline > liability for inaccuracy, breach of integrity, loss or delayed delivery of > the message, for any failure in, interruption to or degradation of either > the service or the message, as well as for any loss or damage sustained > thereof to the fullest extent provided by law. > > If this e-mail was not intended for you, please notify the sender > immediately via e-mail and delete it at once. Any unauthorized disclosure, > dissemination or use, either in whole or in part is strictly prohibited and > may give rise to both criminal and civil liability. All rights reserved. > > ============================================================================================================== > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131021/88ae8f3e/attachment.htm From acasado at ual.es Tue Oct 22 11:25:22 2013 From: acasado at ual.es (Antonio Casado Rodriguez) Date: Tue, 22 Oct 2013 11:25:22 +0200 Subject: [smokeping-users] smokealert error in Date header of other language Message-ID: <52664482.1030007@ual.es> Hi all, Server: RHEL 6.4 (spanish) Smokeping: 2.6.9 When I receive a message of smokealert, the Date header is set in spanish, the correct is set in english. Trace: From: smokealert at ual.es Date: mar, 22 oct 2013 10:00:12 +0200 Subject: [SmokeAlert] someloss is active on network.interna.switch But, "mar" is "martes" (in spanish). The correct will be: Date: Tue, 22 Oct 2013 10:00:12 +0200 Then, my thunderbird (mail client) don't sort correctly the message. It's put in March. If I run: echo hello | mail foo at ual.es, it's work ok. Is it a bug? Thanks you. -- Antonio Casado Rodr?guez Administrador de Servicios de Red y Seguridad TIC ?rea de Comunicaciones STIC (Servicio de las Tecnolog?as de la Informaci?n y las Comunicaciones) UNIVERSIDAD DE ALMER?A Este mensaje y los ficheros que puedan ser adjuntados son confidenciales. Los mismos contienen informaci?n reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenv?o a su direcci?n electr?nica; no deber? copiar el mensaje ni divulgar su contenido a ninguna persona. Su direcci?n de correo electr?nico junto a sus datos personales constan en un fichero titularidad de La UNIVERSIDAD DE ALMER?A cuya finalidad es la de mantener el contacto con usted. Si quiere saber de qu? informaci?n disponemos de usted, modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompa?ado de una fotocopia de su D.N.I. a la siguiente direcci?n: UNIVERSIDAD DE ALMER?A ?. Secretar?a General de La Universidad de Almer?a. Edificio Central, Planta baja. Ctra. Sacramento s/n, La Ca?ada de San Urbano. CP 04120 Almer?a -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2257 bytes Desc: Firma criptogr??fica S/MIME Url : http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20131022/b80801d9/attachment.bin From acasado at ual.es Wed Oct 23 13:15:31 2013 From: acasado at ual.es (Antonio Casado Rodriguez) Date: Wed, 23 Oct 2013 13:15:31 +0200 Subject: [smokeping-users] smokealert error in Date header of other language In-Reply-To: <52664482.1030007@ual.es> References: <52664482.1030007@ual.es> Message-ID: <5267AFD3.8000309@ual.es> Hi, The problem is in "smokeping/lib/Smokeping.pm" line 1946: my $rfc2822stamp = POSIX::strftime("%a, %e %b %Y %H:%M:%S %z", @stamp); I've got 3 patch for this: a) my $rfc2822stamp = `date --rfc-2822`; b) my @weekday = ("Sun","Mon","Tue","Wed","Thu","Fri","Sat"); my $rfc2822stamp = $weekday[$stamp[6]]; $rfc2822stamp .= POSIX::strftime(", %e %b %Y %H:%M:%S %z", @stamp); c) use DateTime; use DateTime::Format::Mail; my $rfc2822stamp = DateTime::Format::Mail->format_datetime( DateTime->now() ); A similar error is comment here: http://comments.gmane.org/gmane.comp.version-control.git/23337 El 22/10/2013 11:25, Antonio Casado Rodriguez escribi?: > Hi all, > > Server: RHEL 6.4 (spanish) > Smokeping: 2.6.9 > > When I receive a message of smokealert, the Date header is set in > spanish, the correct is set in english. Trace: > > From: smokealert at ual.es > Date: mar, 22 oct 2013 10:00:12 +0200 > Subject: [SmokeAlert] someloss is active on network.interna.switch > > > But, "mar" is "martes" (in spanish). The correct will be: > > Date: Tue, 22 Oct 2013 10:00:12 +0200 > > > Then, my thunderbird (mail client) don't sort correctly the message. > It's put in March. > If I run: echo hello | mail foo at ual.es, it's work ok. > > Is it a bug? > > Thanks you. -- Antonio Casado Rodr?guez Administrador de Servicios de Red y Seguridad TIC ?rea de Comunicaciones STIC (Servicio de las Tecnolog?as de la Informaci?n y las Comunicaciones) UNIVERSIDAD DE ALMER?A Este mensaje y los ficheros que puedan ser adjuntados son confidenciales. Los mismos contienen informaci?n reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenv?o a su direcci?n electr?nica; no deber? copiar el mensaje ni divulgar su contenido a ninguna persona. Su direcci?n de correo electr?nico junto a sus datos personales constan en un fichero titularidad de La UNIVERSIDAD DE ALMER?A cuya finalidad es la de mantener el contacto con usted. Si quiere saber de qu? informaci?n disponemos de usted, modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompa?ado de una fotocopia de su D.N.I. a la siguiente direcci?n: UNIVERSIDAD DE ALMER?A ?. Secretar?a General de La Universidad de Almer?a. Edificio Central, Planta baja. Ctra. Sacramento s/n, La Ca?ada de San Urbano. CP 04120 Almer?a From tobi at oetiker.ch Wed Oct 23 15:31:29 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 23 Oct 2013 15:31:29 +0200 (CEST) Subject: [smokeping-users] smokealert error in Date header of other language In-Reply-To: <5267AFD3.8000309@ual.es> References: <52664482.1030007@ual.es> <5267AFD3.8000309@ual.es> Message-ID: Antonio, how about just adding code to switch the locale back to 'C' prior to calling strftime ? cheers tobi Today Antonio Casado Rodriguez wrote: > Hi, > > The problem is in "smokeping/lib/Smokeping.pm" line 1946: > my $rfc2822stamp = POSIX::strftime("%a, %e %b %Y %H:%M:%S %z", @stamp); > > I've got 3 patch for this: > > a) my $rfc2822stamp = `date --rfc-2822`; > > b) my @weekday = ("Sun","Mon","Tue","Wed","Thu","Fri","Sat"); > my $rfc2822stamp = $weekday[$stamp[6]]; > $rfc2822stamp .= POSIX::strftime(", %e %b %Y %H:%M:%S %z", @stamp); > > c) use DateTime; > use DateTime::Format::Mail; > my $rfc2822stamp = DateTime::Format::Mail->format_datetime( > DateTime->now() ); > > A similar error is comment here: > http://comments.gmane.org/gmane.comp.version-control.git/23337 > > El 22/10/2013 11:25, Antonio Casado Rodriguez escribi?: > > Hi all, > > > > Server: RHEL 6.4 (spanish) > > Smokeping: 2.6.9 > > > > When I receive a message of smokealert, the Date header is set in > > spanish, the correct is set in english. Trace: > > > > From: smokealert at ual.es > > Date: mar, 22 oct 2013 10:00:12 +0200 > > Subject: [SmokeAlert] someloss is active on network.interna.switch > > > > > > But, "mar" is "martes" (in spanish). The correct will be: > > > > Date: Tue, 22 Oct 2013 10:00:12 +0200 > > > > > > Then, my thunderbird (mail client) don't sort correctly the message. > > It's put in March. > > If I run: echo hello | mail foo at ual.es, it's work ok. > > > > Is it a bug? > > > > Thanks you. > > -- 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 simonjai at gmail.com Thu Oct 24 10:55:59 2013 From: simonjai at gmail.com (Simon Liang) Date: Thu, 24 Oct 2013 19:55:59 +1100 Subject: [smokeping-users] Smokeping FastCGI Woes In-Reply-To: References: <5B6967F6EA05614489E63202C9F6C18004EA6171@mkexc01.bankofgreece.gr> Message-ID: Hey, I have discovered that during this high load period, the web server is actually doing all the rebuild and preparation that it does when Smokeping is first started. The poller was not started, so what actually causes this? Does Smokeping do some kind of auto refresh? Cheers, Simon On Mon, Oct 21, 2013 at 4:01 PM, Simon Liang wrote: > Hey, > > They're actually on two separate blade servers. Smokeping poller is on a > server by itself, and the web is also on a server by itself. There is > absolutely nothing on them except Smokeping. > > Could it be that over a period of time, smokeping_cgi is run in which it's > try to rebuild everything again? > > I used to run everything all on one server, so when the config gets changed > I see the server lag a bit (assuming it's preparing everything again) and > then will come back. However this is shouldn't be the case, as the config is > only rsync'd to the web server when a restart on the poller is executed. > > Cheers, > Simon > > > On Sat, Oct 19, 2013 at 12:55 AM, wrote: >> >> Is there anything else running on the same physical server? I mean >> except those two VMs you are talking about. Could it be there is a >> resource issue there? Have you tried giving it another core and see how >> it goes with performance? I have had similar problems with VMs running >> classic MRTG (without RRD) and things got a lot better when I added >> another core on those VMs. >> I 'm definitely interested to see what answer you will get on the >> subject in the end. >> >> -----Original Message----- >> From: Simon Liang [mailto:simonjai at gmail.com] >> Sent: Friday, October 18, 2013 2:04 AM >> To: smokeping-users at lists.oetiker.ch >> Subject: [smokeping-users] Smokeping FastCGI Woes >> >> Hi there, >> >> I've been running an early 2.6 version of Smokeping and recently decided >> to upgrade to the latest 2.6.9. The polling side of Smokeping is rock >> solid, however it's quite the opposite with the change to FastCGI. I >> thought this would be a good place to start and hope someone can help >> me. >> >> Just some background of my current setup. I have separated the Polling >> (forked with FPing) and web service side of Smokeping into two VMs (to >> reduce the load the server). The config files are rsynced from the >> poller to the web and the RRD files are shared via NFS. >> >> Poller VM - 8 vCPU, 16GB RAM >> Web VM - 4 vCPU, 16GB RAM >> >> I understand when the web side of Smokeping starts (after a config >> change), it does a lot of things under the hood. To address this issue, >> on restarts I create an IP table rule on the web server so only the >> poller can access it via port 80, I then use curl to trigger the first >> (and only) session. Once it's completed I remove the IP table rule so it >> becomes accessible. This works quite work and everything works fine. >> >> But after a random period of time, the load on the web server spikes up >> quite high, memory starts swapping and the server becomes almost >> unresponsive. >> >> This is a screenshot of the web server under load (before I upgraded to >> 16GB RAM) >> https://dl.dropboxusercontent.com/u/11792766/Work/smokeping_load.JPG >> >> The spikes in the graph are when the load on the server just randomly >> spikes up and I'm forced to restart Smokeping manually. >> https://dl.dropboxusercontent.com/u/11792766/Work/smokeping_stats.JPG >> >> I can assure you there are no cron jobs running which may be loading up >> the server. On peak hour traffic I have maybe 100 requests per minute. >> >> Here is my Apache (fcgid) config: http://pastebin.com/QU6XRcFg >> >> If you need any more information please let me know. >> >> Cheers, >> Simon >> >> >> >> ============================================================================================================== >> ?? ??? ????????? ?????? ??????? ??????????? ???. ???? ?????? ???????????? >> ???????????? ??? ??? ??????? ??? ??????? (???) ???????????? ????????? ???? >> ??? ?? ???????? ???? ??????????? ?? ?? ?????????? ? ???????? ????????? ? >> ???? ???????? ??? ???. >> >> ?? ?????? ???????????? ???????????? ??????????? ???? ???????????? ????? >> ??? ????????, ??? ?????? ? ????????? ??????????? ???? ??????????? ??? >> ?????????. ? ?????????? ??? ? ??? ??? ???????????? ?????? ?????? ??? >> ???????????, ????????? ??? ????????????, ??????? ? ????????????? ????????? >> ??? ?????????, ??? ???????, ??????? ? ?????????? ??? ????????? ? ??? >> ????????? ????? ??? ??? ???? ?? ????? ??? ????? ??????? ? ????? ?????? ??? >> ??? ??? ????? ???????????? ??????. >> >> ??? ?????? ???? ????? ?? ????? ?????? ???????????? ????????????, >> ??????????? ?? ???????????? ?????? ???? ???????????? ???????????? ??? >> ????????? ??? ?? ?????????? ?? ??????. ??????????? ??????????, ??????? ? >> ????? ?????? ? ????????? ??? ????????? ????? ????? ???????????? ??????? ??? >> ?????? ?? ???????? ??????? ??? ?????? ??????. >> >> >> Any e-mail message from the Bank of Greece (BoG) is sent in good faith but >> shall neither be binding nor construed as constituting or affecting a >> contractual arrangement or other commitment by the BoG. >> >> The e-mail is intended for the exclusive use of the person whose e-mail >> address appears in caption as recipient. The sender and the BoG decline >> liability for inaccuracy, breach of integrity, loss or delayed delivery of >> the message, for any failure in, interruption to or degradation of either >> the service or the message, as well as for any loss or damage sustained >> thereof to the fullest extent provided by law. >> >> If this e-mail was not intended for you, please notify the sender >> immediately via e-mail and delete it at once. Any unauthorized disclosure, >> dissemination or use, either in whole or in part is strictly prohibited and >> may give rise to both criminal and civil liability. All rights reserved. >> >> ============================================================================================================== >> >> >> > From paul.mansfield+smokeping at grapeshot.co.uk Fri Oct 25 13:26:33 2013 From: paul.mansfield+smokeping at grapeshot.co.uk (Paul Mansfield) Date: Fri, 25 Oct 2013 12:26:33 +0100 Subject: [smokeping-users] Smokeping FastCGI Woes In-Reply-To: References: <5B6967F6EA05614489E63202C9F6C18004EA6171@mkexc01.bankofgreece.gr> Message-ID: won't the web server naturally allow slaves fcgi processes to die off after a certain number of http requests are processed? From tobi at oetiker.ch Wed Oct 30 22:34:03 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Wed, 30 Oct 2013 22:34:03 +0100 (CET) Subject: [smokeping-users] status update smokeping-3.x Message-ID: Hi SmokePing Users, Over the last days I have been working on the re-designing the code for running smokeping probes. My idea is go with an event based design for version 3, this means that smokeping will be able to run more probes, more efficiently while using less resources. SmokePing probes usually spend most of their time waiting for some latency measurment task to complete. From a performance point of view this is rather bad, especially if multiple probes are doing this waiting one after the other. Often, the probe starts some external command which in turn performs some measurement and then retuns with the result. Or some perl code does some request over the network and waits for it to complete. In either case, the probe has to wait for the result. Current SmokePing aproaches this performance probelm by forking probes into multiple instances which then run in parallel. In the new event based design, this idea is taken much further. With the help of the AnyEvent perl module it is possible to launch an external program or even some perl code and attach a sub routine to this task which gets called once the external program completes or the forked perl code returns. So the main smokeping probe loop can lanuch many external probing tasks in parallel while automatically processing their return data once it becomes available. The task of writing the probe measurments out to rrd files will also slow the main probing loop, to solve this an external rrd writer process will do the actual updateing of rrd files, leaving the main loop free to lanuch probes. If too many updates are hitting the rrd writer, successive updates to the same rrd file will be automatically combined, this improving the write performance. stay tuned, soon there will be some initial code for this probe runner loop. 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 paul.mansfield+smokeping at grapeshot.co.uk Thu Oct 31 12:01:22 2013 From: paul.mansfield+smokeping at grapeshot.co.uk (Paul Mansfield) Date: Thu, 31 Oct 2013 11:01:22 +0000 Subject: [smokeping-users] status update smokeping-3.x In-Reply-To: References: Message-ID: Hi Tobi Will the smokeping master be entirely split from the slave? It is a nuisance at the moment that the slave script won't start unless there are all sorts of bits of perl libraries available which aren't needed to perform the function of a slave, so you end up installing lots of perl which clutters up servers. thanks Paul From tobi at oetiker.ch Thu Oct 31 14:59:06 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Thu, 31 Oct 2013 14:59:06 +0100 (CET) Subject: [smokeping-users] status update smokeping-3.x In-Reply-To: References: Message-ID: Hi Paul, Today Paul Mansfield wrote: > Hi Tobi > > Will the smokeping master be entirely split from the slave? > > It is a nuisance at the moment that the slave script won't start > unless there are all sorts of bits of perl libraries available which > aren't needed to perform the function of a slave, so you end up > installing lots of perl which clutters up servers. You mean dependencies for running probes you are not using ? That is a possibility. Although, if you look at the 3.x github repo, you will see that there is now a script supplied that builds all the dependencies, so handling is much simpler ... will look into this ... cheers tobi > thanks > Paul > > -- 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 tobi at oetiker.ch Thu Oct 31 15:25:47 2013 From: tobi at oetiker.ch (Tobias Oetiker) Date: Thu, 31 Oct 2013 15:25:47 +0100 (CET) Subject: [smokeping-users] status update smokeping-3.x In-Reply-To: References: Message-ID: Today Paul Mansfield wrote: > from memory, the slave script requires rrd libraries otherwise it > won't run, as one example. ah, that will not be required 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