|; @@ -3843,11 +3843,12 @@ POD } -sub cgi ($) { +sub cgi ($$) { $cgimode = 'yes'; umask 022; load_cfg shift; - my $q=new CGI; + my $q = shift; initialize_cgilog(); if ($q->param(-name=>'slave')) { # a slave is calling in Smokeping::Master::answer_slave($cfg,$q); 2. Because of the number of nodes, fping poller does not finish in 300 seconds. I have blazemode enabled. Is there a way to run multiple fping probes or increase parallelization? Any help would be greatly appreciated. 3. If smokeping cant practically scale to this size, Does anyone have an open sourced suggestion. I am also running cacti and it has scaled rather well. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110802/e25bdb43/attachment.htm From alter3d at alter3d.ca Wed Aug 3 05:04:08 2011 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 02 Aug 2011 23:04:08 -0400 Subject: [smokeping-users] Large deployment problems In-Reply-To: References: Message-ID: <4E38BAA8.9080904@alter3d.ca> 1) I assume that you've checked for a speedycgi package in your distro's repositories first? Speedy is pretty common (though obviously outdated) and most distros should have a pre-patched, pre-compiled binary available. If not, search through the archives for this list -- someone JUST submitted a patchset to use FastCGI instead of Speedy (seriously, I think it was the post before yours on the list!). 2) Absolutely, you can run multiple probes in parallel. The documentation available at smokeping.org covers this, and there have been many threads on this list about that topic. Consider also changing your 'step' and 'pings' values to meet your requirements -- you're essentially balancing granularity vs performance. It can take a bit of guesswork and futzing with numbers to get something that works for you. 3) I don't see a problem scaling to 5600+ nodes with Smokeping if it's configured properly (there's the rub, of course). I honestly don't know of any other F/OSS software that does the same thing that Smokeping does, unfortunately (though IIRC, someone did write a "Smokeping-like" module for Cacti a few years ago.... maybe check cactiusers.org (again IIRC) if you're interested in this option). On 02/08/2011 8:15 PM, Josh Wisman wrote: > I have a need to do a 5600+ node deployment of Smokeping. Meaning that > I have 5600 devices to ping. Some 10% -20% have high latency 1000ms+. > Currently I have about 1200 nodes in smokeping. This is a new build. I > am building this on a OpenSuse 11.4 x86_64 platform. I am running into > problems. > > 1. SpeedyCGI does not compile on this version of Suse even after my > best effort. I have attempted to make use of fastCGI, but I dont know > that I am doing it right. The menu(smokeping.cgi) is large. Its by > State then City in my config. It maxes out my cpu (1 of 4) when you > open smokeping, because of this, page load times are pretty slow and > it will only get worse as I add more nodes. (snip build output - PK) > 2. Because of the number of nodes, fping poller does not finish in 300 > seconds. I have blazemode enabled. Is there a way to run multiple > fping probes or increase parallelization? Any help would be greatly > appreciated. > > 3. If smokeping cant practically scale to this size, Does anyone have > an open sourced suggestion. I am also running cacti and it has scaled > rather well. > > > _______________________________________________ > 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/20110802/1d9b6f39/attachment-0001.htm From ntyni+smokeping-users at mappi.helsinki.fi Wed Aug 3 07:57:09 2011 From: ntyni+smokeping-users at mappi.helsinki.fi (Niko Tyni) Date: Wed, 3 Aug 2011 08:57:09 +0300 Subject: [smokeping-users] Large deployment problems In-Reply-To: References: Message-ID: <20110803055709.GA2789@madeleine.local.invalid> On Tue, Aug 02, 2011 at 05:15:56PM -0700, Josh Wisman wrote: > 1. SpeedyCGI does not compile on this version of Suse even after my best > effort. You might want to check if any of the patches at http://patch-tracker.debian.org/package/speedy-cgi-perl help. Alternatively, I think fastCGI should work with the changes you included in your mail. You'll need a fastCGI enabled web server of course. > 2. Because of the number of nodes, fping poller does not finish in 300 > seconds. I have blazemode enabled. Is there a way to run multiple fping > probes or increase parallelization? Any help would be greatly appreciated. Multiple probe instances are supported, see the smokeping_examples document. HTH, -- Niko From darren at victoriajd.com Wed Aug 3 14:56:15 2011 From: darren at victoriajd.com (Darren Murphy) Date: Wed, 3 Aug 2011 20:56:15 +0800 Subject: [smokeping-users] Large deployment problems In-Reply-To: References: Message-ID: On 3 August 2011 08:15, Josh Wisman wrote: > 2. Because of the number of nodes, fping poller does not finish in 300 > seconds. ?I have blazemode enabled. Is there a way to run multiple fping > probes or increase parallelization? Any help would be greatly appreciated. As others have mentioned, the answer is yes, and documented. I run 20 FPing probes on each of 3 slaves, with each slave polling ~1000 hosts (50 hosts per probe). One problem I have found with running multiple FPing probes is that individual probes on my slaves tend to die from time to time. I haven't been able to figure out why they die, but I have found that monit (http://mmonit.com/monit/) is particularly effective in keeping the required number of probes running. My monit config for smokeping is quite simple and looks like so: check process smokeping with pidfile /var/smokeping/smokeping.pid start program = "/etc/init.d/smokeping start" stop program = "/etc/init.d/smokeping stop" if children < 20 then restart if 3 restarts within 5 cycles then alert The above will restart smokeping at any time than less than the required number (20) of probes are found, and alert me via email if 3 restarts occur within 5 checks. Hope this helps, Darren From laylanahar at gmail.com Mon Aug 8 20:32:28 2011 From: laylanahar at gmail.com (Layla Nahar) Date: Mon, 8 Aug 2011 15:32:28 -0300 Subject: [smokeping-users] purpose of user 'www' (vs 'apache)? Message-ID: Hello, I've seen reference in some mails on this list to the user www. I have user 'apache' in my system and Smokeping is running without user www. I tried checked on the internet to try and find our if there are any conventions or requirements vis a vis 'www' but found very little. I suspect this is a very elementary question, but would someone mind clarifying how it is used in connection with smokeping? I'm guessing it is just the convention among some admins to have this user start and run apache server, but I'd like to be sure. thanks LN From josh at imaginenetworksllc.com Mon Aug 8 20:39:04 2011 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Mon, 8 Aug 2011 14:39:04 -0400 Subject: [smokeping-users] purpose of user 'www' (vs 'apache)? In-Reply-To: References: Message-ID: RHEL vs Debian vs BSD vs another distro. Some install httpd as www, some as nobody, some as apache, etc. Smokeping is run under Apache and hence the user Apache uses. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Mon, Aug 8, 2011 at 2:32 PM, Layla Nahar wrote: > Hello, > > I've seen reference in some mails on this list to the user www. > I have user 'apache' in my system and Smokeping is running without user > www. > I tried checked on the internet to try and find our if there are any > conventions or requirements vis a vis 'www' but found very little. > > I suspect this is a very elementary question, but would someone mind > clarifying how it is used in connection with smokeping? I'm guessing > it is just the convention among some admins to have this user start > and run apache server, but I'd like to be sure. > > thanks > LN > > _______________________________________________ > 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/20110808/0cb526b8/attachment.htm From laylanahar at gmail.com Mon Aug 8 20:50:29 2011 From: laylanahar at gmail.com (Layla Nahar) Date: Mon, 8 Aug 2011 15:50:29 -0300 Subject: [smokeping-users] purpose of user 'www' (vs 'apache)? In-Reply-To: References: Message-ID: Hello Josh, Deny IP - thank you very much for the clarification. I feel much more at ease being sure rather than just guessing and hoping! thanks again LN On Mon, Aug 8, 2011 at 3:40 PM, Deny IP Any Any wrote: > back in the old days, the Apache daemon ran as the user 'root'. This > caused lots of security issues (think if someone wrote a web page that > tries to write to /etc/password; since Apache ran as root, so their > their script). > > In current systems, Apache runs as a non-root user; this user is often > called www, or apache, or www-data, etc. The actual name makes no > difference, as long as it isn't ran as root. On Mon, Aug 8, 2011 at 3:32 PM, Layla Nahar wrote: > Hello, > > I've seen reference in some mails on this list to the user www. > I have user 'apache' in my system and Smokeping is running without user www. > I tried checked on the internet to try and find our if there are any > conventions or requirements vis a vis 'www' but found very little. > > I suspect this is a very elementary question, but would someone mind > clarifying how it is used in connection with smokeping? I'm guessing > it is just the convention among some admins to have this user start > and run apache server, but I'd like to be sure. > > thanks > LN > From glenn.andersson at axis.com Tue Aug 23 15:11:51 2011 From: glenn.andersson at axis.com (Glenn Andersson) Date: Tue, 23 Aug 2011 15:11:51 +0200 Subject: [smokeping-users] Steps and new graph Message-ID: <8EE95B77C6826E4094CB81DF9FAF5EFE5F6563D367@xmail2.se.axis.com> Hi there again. I have changes some settings in my smokeping config to be able to see more in-depth information in my graphs. So I have set the 'step' part in 'Database' section to 5 (I should maybe change this to 1 in the future). Changing that would end up in me having history for about 360 days? If I wanted to maintain the step = 5 and increase the history date, what value would I change? And another thing, I want a new graph separated from the other ones with less sampling rate but stretch over 10 years. How and where could I do that? Best regards, Glenn Andersson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110823/0a8ab0ab/attachment.html From glenn.andersson at axis.com Tue Aug 30 11:31:20 2011 From: glenn.andersson at axis.com (Glenn Andersson) Date: Tue, 30 Aug 2011 11:31:20 +0200 Subject: [smokeping-users] Packet loss graph? Message-ID: <8EE95B77C6826E4094CB81DF9FAF5EFE5F656CB069@xmail2.se.axis.com> Hi there all again. Is there a way to implement a packet loss graph in an existing graph (or a separate one) fairly easily? Can't really find any documentation on this topic anywhere, except the information to read packet loss bellow the regular graph. Would be great to have the packet loss graphically also. Best regards, Glenn Andersson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110830/ea0807df/attachment-0001.htm From alter3d at alter3d.ca Tue Aug 30 14:51:23 2011 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Tue, 30 Aug 2011 08:51:23 -0400 Subject: [smokeping-users] Packet loss graph? In-Reply-To: <8EE95B77C6826E4094CB81DF9FAF5EFE5F656CB069@xmail2.se.axis.com> References: <8EE95B77C6826E4094CB81DF9FAF5EFE5F656CB069@xmail2.se.axis.com> Message-ID: <4E5CDCCB.2060301@alter3d.ca> Smokeping already gives you this information graphically. The color of the median bars indicates range of packet loss. - Peter On 8/30/2011 5:31 AM, Glenn Andersson wrote: > > Hi there all again. > > Is there a way to implement a packet loss graph in an existing graph > (or a separate one) fairly easily? > > Can't really find any documentation on this topic anywhere, except the > information to read packet loss bellow the regular graph. > > Would be great to have the packet loss graphically also. > > Best regards, > > Glenn Andersson > > > > _______________________________________________ > 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/20110830/afae9cc8/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4418 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.oetiker.ch/pipermail/smokeping-users/attachments/20110830/afae9cc8/attachment.bin From victor at owlbydesign.com Wed Aug 31 17:28:41 2011 From: victor at owlbydesign.com (Victor Carpetto) Date: Wed, 31 Aug 2011 08:28:41 -0700 Subject: [smokeping-users] Placing graphs side by side Message-ID: <756E11E4-B643-4B14-BC84-F4902DE2599D@owlbydesign.com> Hello, I am trying to figure out a way to display the RRD graphs side by side. We are using smoke ping for showing a large number of sites, and it would be beneficial to utilize the full web page, which right now is mostly whitespace. Thanks Victor From throck at gmail.com Wed Aug 3 07:34:28 2011 From: throck at gmail.com (Tom Throckmorton) Date: Wed, 03 Aug 2011 05:34:28 -0000 Subject: [smokeping-users] Large deployment problems In-Reply-To: References: Message-ID: <4E38DC3B.7090505@gmail.com> On 8/2/11 8:15 PM, Josh Wisman wrote: > I have a need to do a 5600+ node deployment of Smokeping. Meaning that I > have 5600 devices to ping. Some 10% -20% have high latency 1000ms+. > Currently I have about 1200 nodes in smokeping. This is a new build. I am > building this on a OpenSuse 11.4 x86_64 platform. I am running into > problems. > > 1. SpeedyCGI does not compile on this version of Suse even after my best > effort. I have attempted to make use of fastCGI, but I dont know that I am > doing it right. The menu(smokeping.cgi) is large. Its by State then City in > my config. It maxes out my cpu (1 of 4) when you open smokeping, because of > this, page load times are pretty slow and it will only get worse as I add > more nodes. > > Aside from tackling this with SpeedyCGI/fastCGI, you could also consider pre-generating the index pages using the --static option; note that you trade some of the dynamic graph interaction for the speed of static content by doing this. If you make your config modular using @includes, you should be able to do this using mostly the same underlying configs pretty easily. > 2. Because of the number of nodes, fping poller does not finish in 300 > seconds. I have blazemode enabled. Blazemode only adds one extra 'sacrificial' ping for every probed target, so that is probably not having a significant negative impact on the polling time (it's not making it faster, if that's what you were thinking). > Is there a way to run multiple fping > probes or increase parallelization? Any help would be greatly appreciated. Setting up multiple probe groups with offsets would probably do most of what you want to increase concurrency. You could also break the work up among several slave machines, with a non-polling master catching all of the results; added bonus of this approach is that you get to break the CGI frontend out from the probe executors. > 3. If smokeping cant practically scale to this size, Does anyone have > an open sourced suggestion. I am also running cacti and it has scaled rather > well. I can't answer to whether it will scale to that many nodes, however, I believe it's certainly possible. Cacti's threaded poller does scale pretty well (I've run it with several thousand data sources), but finding the collected data in that interface might be more challenging, especially for end-users. -tt