headers
John L Hoo | 1 Nov 2005 21:30
Picon

Strange Alert Behaviour


I am getting gaps in my smokeping data when I have alerts configured for
targets. I see the same gaps for each target, whether an alert is configured
for that target or not. It is almost as if the server lost connectivity to
the network. But it did not.

If I remove the alerts for the configuration of the targets - no more gaps
in the data.

Here is my Database Configuration

*** Database ***

step     = 60 
pings    = 5

# consfn mrhb steps total

AVERAGE  0.5   1  1008
AVERAGE  0.5  12  10800 
    MIN  0.5  12  10800
    MAX  0.5  12  10800
AVERAGE  0.5 144  24000
    MAX  0.5 144  24000
    MIN  0.5 144  24000

Here are my alerts.... 

+lossdetect-3m
type = loss
(Continue reading)

Permalink | Reply | 1 comment |
headers
Niko Tyni | 2 Nov 2005 13:36
Picon
Picon

Re: Strange Alert Behaviour

On Tue, Nov 01, 2005 at 03:30:01PM -0500, John L Hoo wrote:

> I am getting gaps in my smokeping data when I have alerts configured for
> targets. I see the same gaps for each target, whether an alert is configured
> for that target or not. It is almost as if the server lost connectivity to
> the network. But it did not.
> 
> If I remove the alerts for the configuration of the targets - no more gaps
> in the data.

> +++Bell
> menu = Bell
> title = Bell
> probe = FPing
> host = <<ip address deleted>>
> alerts = lossdetect-3m,latency-3m,latency-change

> Oct 31 16:04:25 adelx02 smokeping[6615]: FPing: WARNING: smokeping took 127
> seconds to complete 1 round of polling. It should complete polling in 60
> seconds. You may have unresponsive devices in your setup. 

Hi,

it looks like the alerts take a long time to run for some reason. Obviously,
this shouldn't happen. Could you try it with the '--debug' option, that should
give some more information. (If you can't reproduce the problem with '--debug',
try '--debug-daemon' and look at the syslog.)

Have you tried running with just one of the alerts enabled at a time? That would
tell us if it's just one of the alerts or any of them that causes the problem.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael McCarn | 5 Nov 2005 17:01
Picon

curl: (35) Unknown SSL protocol error in connection

I could not figure out how to make my Linksys WRT54G respond to "ping",
so I'm using Curl to monitor it using https.  

The router has a self-signed certificate, requiring "insecure_ssl = 1"

When using 'ssl2' I get an SSL protocol error trying to connect

Changing "ssl2 = 1" to "ssl2 = 0" does not remove '-2' from the Curl
invocation, but adding "-3" to "extraargs" lets my probe work.

 
extract from *** Probes *** in etc/config:
============================
+Curl
binary = /usr/bin/curl
forks = 5
offset = 50%
step = 300
# The following variables can be overridden in each target section
agent = User-Agent: Lynx/2.8.4rel.1 libwww-FM/2.14 SSL-MM/1.4.1
OpenSSL/0.9.6c
extraargs = --head --user user:password
extrare = / /
insecure_ssl = 1
interface = ppp0
pings = 5
ssl2 = 0
timeout = 20
urlformat = http://%host%/ # mandatory
(Continue reading)

Permalink | Reply | 1 comment |
headers
Niko Tyni | 6 Nov 2005 10:56
Picon
Picon

Re: curl: (35) Unknown SSL protocol error in connection

On Sat, Nov 05, 2005 at 11:01:54AM -0500, Michael McCarn wrote:
> I could not figure out how to make my Linksys WRT54G respond to "ping",
> so I'm using Curl to monitor it using https.  
>  
> The router has a self-signed certificate, requiring "insecure_ssl = 1"
>  
> When using 'ssl2' I get an SSL protocol error trying to connect
>  
> Changing "ssl2 = 1" to "ssl2 = 0" does not remove '-2' from the Curl
> invocation, but adding "-3" to "extraargs" lets my probe work.

Hi,

the Curl probe was indeed taking '0' for 'true', with both the 'ssl2'
and the 'insecure_ssl' option. This will be fixed in the next release.

Anyway, curl seems to use SSL version 3 by default, so I think you
should be fine if don't specify either 'ssl2' or '-3'. Or maybe it's a
curl version-specific thing...

Thanks for reporting this,
--

-- 
Niko
Permalink | Reply | 0 comments |
headers
Srinivas Makam | 8 Nov 2005 21:49
Picon
Favicon

rrd_merger tool issue

I am trying to merge old RRD  files with the new RRD files (different time range) using the rrd_merger tool.
I am getting an error after the new rrd file is dumped into xml format.
Any clues on what may be missing in my library?

------------
[root <at> pinghost XYZ]# perl $rrdm --oldrrd=1210.rrd
--newrrd=/etc/smokeping/rrd-data/C/ABC/XYZ/1210.rrd mergedrrd=t1.rrd

Dumping 1210.rrd to XML: /tmp/1210.rrd_old_6858.xml

Dumping /etc/smokeping/rrd-data/C/ABC/XYZ/1210.rrd to XML: /tmp/1210.rrd_new_6858.xml

Parsing 1210.rrd XML......parsing completed

Parsing /etc/smokeping/rrd-data/C/ABC/XYZ/1210.rrd XML...

Last Update:  1131476403 

Start processing Round Robin DB

Can't call method "text" on an undefined value at /usr/local/rrdtool-1.2.11/bin/rrd_merger.pl line 61.

[root <at> pinghost XYZ]# 

----------------

thanks

Srinivas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Moseman | 9 Nov 2005 21:22
Picon

fping timeout and backoff

I was going to check to see if the timeout for the pings was
adjustable.  When checking the documetation I see there's a timeout
that I can adjust, that's good, but there's a backoff factor.  The
defaults are 500ms and 1.5 respectively.  I assume this means, should
there not be any ping response, it waits 500ms for the 1st ping, 750
ms for the 2nd ping, etc.  Is that right?  Assuming that's the way it
works, is there any way to change this behavior in Smokeping?  Maybe
it's a required component for Smokeping to function and it should
stay?

The overall point is that the devices we're monitoring do not have
much use when the latency goes beyond 1000 ms.  There's a chance that
we might prefer to just drop responses over 1000 or 1500 ms and report
it as packetloss instead.  I'm curious if this is possible.

Thanks,
Scott
Permalink | Reply | 1 comment |
headers
Niko Tyni | 11 Nov 2005 13:17
Picon
Picon

Re: fping timeout and backoff

On Wed, Nov 09, 2005 at 02:22:08PM -0600, Scott Moseman wrote:
> I was going to check to see if the timeout for the pings was
> adjustable.  When checking the documetation I see there's a timeout
> that I can adjust, that's good, but there's a backoff factor.  The
> defaults are 500ms and 1.5 respectively.  I assume this means, should
> there not be any ping response, it waits 500ms for the 1st ping, 750
> ms for the 2nd ping, etc.  Is that right?  Assuming that's the way it
> works, is there any way to change this behavior in Smokeping?  Maybe
> it's a required component for Smokeping to function and it should
> stay?

Hi,

it looks like the fping backoff factor ('-B') is only effective in the
fping 'default mode'. Smokeping uses the 'automated statistics mode',
parameter '-C'. OTOH, there's '-p', which seems to do what you want.
You can tune this by specifying 'hostinterval' in the config file.

The 'timeout' variable, '-t', seems to be a bug in Smokeping. Just like
'-B', it's only effective in the 'default mode', and so it doesn't
really affect anything here. I guess I'll remove it (probably with a
warning) for the next release.
--

-- 
Niko
Permalink | Reply | 0 comments |
headers
Tobias Geiger | 22 Nov 2005 12:21
Favicon

curl false positive...

Hello List,

i have a problem with curl Probes:

it works too good :) : 
	i have e.g.:

	probe = Curl
	host = www.blabla.info
	urlformat = http://%host%/shop_content.php

it works perfect. (shop_content.php i a valid url)

but when i change the "urlformat" to an invalid url, eg.: 

http://%host%/shop_content.ph (note the missing p at the end)
smokeping draws the graph as if this were a valid url.

What am i doing wrong?

Thanks for your help

Tobias
Permalink | Reply | 3 comments |
headers
Lars Thegler | 22 Nov 2005 13:12
Picon
Gravatar

Re: curl false positive...

Tobias Geiger wrote:
> 	urlformat = http://%host%/shop_content.php
> 
> it works perfect. (shop_content.php i a valid url)
> 
> but when i change the "urlformat" to an invalid url, eg.: 
> 
> http://%host%/shop_content.ph (note the missing p at the end)
> smokeping draws the graph as if this were a valid url.
> 
> What am i doing wrong?

You are not doing anything wrong. You are just still timing the response 
from the server, now probably a '404 File not found' reposnse instead of 
a '200 OK' response. You might want to investigate the curl '--fail' 
option if this is not to your liking.

/Lars
Permalink | Reply | 2 comments |
headers
Tobias Geiger | 22 Nov 2005 13:33
Favicon

Re: curl false positive...

Thanks Lars!

extraargs = --fail

did the trick :)

Greetings
Tobias

Am Dienstag, 22. November 2005 13:12 schrieb Lars Thegler:
> Tobias Geiger wrote:
> > 	urlformat = http://%host%/shop_content.php
> >
> > it works perfect. (shop_content.php i a valid url)
> >
> > but when i change the "urlformat" to an invalid url, eg.:
> >
> > http://%host%/shop_content.ph (note the missing p at the end)
> > smokeping draws the graph as if this were a valid url.
> >
> > What am i doing wrong?
>
> You are not doing anything wrong. You are just still timing the response
> from the server, now probably a '404 File not found' reposnse instead of
> a '200 OK' response. You might want to investigate the curl '--fail'
> option if this is not to your liking.
>
> /Lars
>
> --
(Continue reading)

Permalink | Reply | 0 comments |

Gmane