headers
Shaun | 1 May 2006 22:59
Favicon

Re: Apache Plugin Requests Accuracy

Here is what my graphs look like. Do they support what you are saying?
Also, it is labeled minutes and not seconds on the graph.

Shaun

> Hi Shaun,
>
> On Fri, Apr 28, 2006 at 09:20:21PM -0400, Shaun wrote:
>> However, collectd only reports 0.1 requests per minute. Am I missing
>> something?
>
> yes, the values in the RRD files are hits per second..
>
>> My logs are tracking about 60,000 hits per day, which would be about
>> 41 a minute.
>
> With 60k hits per day you should see an average value of roughly 0.70
> hits per second. I mostly get 0.10 as the minimum value (no hits but the
> request by collectd)..
>
> Please check again if you were using the average RRA and multiply it's
> value by 86400. This should be reasonably close to the actual value. If
> not please let me know.
>
> Regards,
> -octo
> --
> Florian octo Forster
> Hacker in training
> GnuPG: 0x91523C3D
(Continue reading)

Permalink | Reply | 1 comment |
headers
Florian Forster | 2 May 2006 00:01
Favicon

Re: Apache Plugin Requests Accuracy

Hi Shaun,

On Mon, May 01, 2006 at 04:59:38PM -0400, Shaun wrote:
> Here is what my graphs look like. Do they support what you are saying?

kind of ;)

The line in the graph reads:
``Requetsts/s  0.09 Min,  1.28 Avg,  18.22 Max,  0.79 Last''

If you multiply the average value 1.28 (Requests per second) by 86400
seconds (= one day) you get 110592 requests. That almost twice as many
requests as you said in your previous mail the server was serving, so
the numbers in the graph are certainly not too low. ;)

> Also, it is labeled minutes and not seconds on the graph.

Did you maybe confuse `Min' (as in minimum) with `Minutes'? The vertical
label and the label on the bottom both say `Requests/s' as in `Requests
per second'..

In conclusion I don't think the numbers are too low. If anything they're
too high, but since they match up perfectly on my server I'd have to
suspect that you'd need some unusual setup to confuse collectd. Could
you double-check the number of hits you had in the time period of the
graph? I'd be very surprised if the numbers really differ by a factor of
two..

Regards,
-octo
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Forster | 2 May 2006 00:14
Favicon

Re: Compile problem on Fedora Core 5 64bit

Hi Daniel,

here, in the call to `libtool', the link-flags are still okay (note the
`-lidn'):
-- 8< --
  /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Werror -g -O2
  -o apache.la -rpath /opt/collectd/lib/collectd -module -avoid-version
  -L/usr/kerberos/lib64 - lcurl -ldl -lgssapi_krb5 -lkrb5 -lk5crypto
  -lkrb5support -lcom_err -lresolv -lidn -lssl -lcrypto -lz apache.lo
-- >8 --

`libtool' then calls `gcc' to link the previously compiled object file
`.libs/apache.o' into a shared object. In this call the `-lidn' argument
has been substituted with `/usr/lib/libidn.so':
-- 8< --
  gcc -shared  .libs/apache.o  -L/usr/kerberos/lib64 -lcurl -ldl
  -lgssapi_krb5 -lk rb5 -lk5crypto -lkrb5support -lcom_err -lresolv
  /usr/lib/libidn.so -lssl -lcrypt o -lz  -Wl,-soname -Wl,apache.so
  -o .libs/apache.so
-- >8 --

I have absolutely no idea why libtool does this and don't know how to
fix it.. A quick and dirty workaround would be to compile everything as
far as possible, issue the above line (with correction, of course) ``by
hand'' and then run `make' again so it picks up where is previously
stopped and finished it's job..

I've noticed that the same happends on my system, also with `libidn'.
I'll try to trace it down and report back if I find anything out, but I
have a rough week in front of me and can't promise to get to that on any
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Forster | 2 May 2006 00:29
Favicon

Re: Problems with 'traffic' plugin

Hi Sune,

On Sun, Apr 30, 2006 at 09:14:36PM +0200, Sune Marcher wrote:
> configure autodetects these settings:
> HAVE_SYS_SOCKET_H, HAVE_LINUX_IF_H, HAVE_LINUX_NETDEVICE_H,
> HAVE_GETIFADDRS, HAVE_IFADDRS_H

with these defines the traffic plugin will use `getifaddrs(3)' to read
system statistics..

> while the following aren't defined:
> HAVE_STRUCT_IF_DATA, HAVE_LIBKSTAT
> 
> Could that be the problem?

No, `libkstat' is only ever used under Solaris and `struct if_data' is a
BSD thing..

The behavior you describe either happends if `getifaddrs(3)' doesn't
return anything at all or none of the structures returned contain the
counters needed for graphing the traffic.. Unfortunatly there is no
debug-statement there, so simply compiling with ``--enable-debug'' won't
help..
If you feel like experimenting you can add a call to `DBG' or `syslog'
in `src/traffic.c':~164..
Could you send some more information about your system? You
Kernel(-version), libc version, gcc version, ...?

> The module *does* build and load without problems, though.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Sune Marcher | 2 May 2006 12:30
Picon
Gravatar

Re[2]: Problems with 'traffic' plugin

Hello Florian,

It's pretty weird. There's no messages in the syslog from collectd at
all (which should of course be a good sign, had 'traffic' worked).

I added a "syslog("it worked")" after the getifaddrs() null-check -
which *does* pop up in the syslog. Then I added a syslog() to the for
loop, and from that it seems like all the returned interfaces'
ifa_data member is NULL - weird!

Is there some kernel options I need enabled for getifaddrs to work?

> Could you send some more information about your system? You
> Kernel(-version), libc version, gcc version, ...?

Slackware 9.0.0, Kernel 2.4.30, gcc version 3.2.2 - and whatever libc
slack came with (libc-2.3.1.so?)

> No, sorry, I don't know.. But I wouldn't be surprised if `getifaddrs(3)'
> returned interface aliases as well..

Perhaps - if it worked :)
A discouraging thing, though, is that 'ifconfig' doesn't show traffic
for the alias interfaces, only for the main physical interface :/

> The various rrdtool-manpages are pretty good, though somewhat academic..
> A little easier to understand could be the `rrdtutorial' by Alex van den
> Bogaerdt: <http://oss.oetiker.ch/rrdtool/tut/rrdtutorial.en.html>. IIrc
> the RRDTool homepage has some links to more documentation..
(Continue reading)

Permalink | Reply | 6 comments |
headers
Daniel | 2 May 2006 16:13
Picon
Favicon

Compile problem on Fedora Core 5 64bit

Hi

Thanks for your help. I'm in no rush so take your time.

Regards
Daniel

> Hi Daniel,
> 
> here, in the call to `libtool', the link-flags are still okay (note the
> `-lidn'):
> -- 8< --
>   /bin/sh ../libtool --tag=CC --mode=link gcc -Wall -Werror -g -O2
>   -o apache.la -rpath /opt/collectd/lib/collectd -module -avoid-version
>   -L/usr/kerberos/lib64 - lcurl -ldl -lgssapi_krb5 -lkrb5 -lk5crypto
>   -lkrb5support -lcom_err -lresolv -lidn -lssl -lcrypto -lz apache.lo
> -- >8 --
> 
> `libtool' then calls `gcc' to link the previously compiled object file
> `.libs/apache.o' into a shared object. In this call the `-lidn' argument
> has been substituted with `/usr/lib/libidn.so':
> -- 8< --
>   gcc -shared  .libs/apache.o  -L/usr/kerberos/lib64 -lcurl -ldl
>   -lgssapi_krb5 -lk rb5 -lk5crypto -lkrb5support -lcom_err -lresolv
>   /usr/lib/libidn.so -lssl -lcrypt o -lz  -Wl,-soname -Wl,apache.so
>   -o .libs/apache.so
> -- >8 --
> 
> I have absolutely no idea why libtool does this and don't know how to
> fix it.. A quick and dirty workaround would be to compile everything as
(Continue reading)

Permalink | Reply | 0 comments |
headers
Muralito | 4 May 2006 05:30
Picon
Favicon

Re: Problems with 'traffic' plugin

Sune Marcher escribió:
> Hello Florian,
> 
> It's pretty weird. There's no messages in the syslog from collectd at
> all (which should of course be a good sign, had 'traffic' worked).
> 
> I added a "syslog("it worked")" after the getifaddrs() null-check -
> which *does* pop up in the syslog. Then I added a syslog() to the for
> loop, and from that it seems like all the returned interfaces'
> ifa_data member is NULL - weird!
> 
> Is there some kernel options I need enabled for getifaddrs to work?
> 
>> Could you send some more information about your system? You
>> Kernel(-version), libc version, gcc version, ...?
> 
> Slackware 9.0.0, Kernel 2.4.30, gcc version 3.2.2 - and whatever libc
> slack came with (libc-2.3.1.so?)
> 
> 
>> No, sorry, I don't know.. But I wouldn't be surprised if `getifaddrs(3)'
>> returned interface aliases as well..
> 
> Perhaps - if it worked :)
> A discouraging thing, though, is that 'ifconfig' doesn't show traffic
> for the alias interfaces, only for the main physical interface :/
> 

In the networking framework of linux kernel (2.4 and newers, I don't 
remember very well) the "alias interface" is a deprecated concept. There
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sune Marcher | 4 May 2006 20:04
Picon
Gravatar

Re[3]: Problems with 'traffic' plugin

Okay, I've played around some more.

I separated the getifaddrs code from collectd/traffic into an external
program and tried it on my Archlinux 0.7.1 vmware test. Kernel 2.6.16,
GCC 4.0.3, libc 2.3.6... somewhat more recent config than my slack
box.

And still, the data field is NULL for all the devices in the list. Do
I need any special kernel config, system setup, or whatnot? And do you
guys use getifaddrs() for traffic, or do you depend on /proc/net/dev
parsing? And if getifaddrs() works for you, what distro/kernel/etc do
you use?

I hand-edited config.h to make traffic use the proc-parsing instead of
getifaddrs(), and that _does_ work (duh). And I guess that it gives
the exact same data as getifaddrs(), so I should be happy. But getting
at the data without harving to parse text would just feel better :)

--

-- 
Best regards,
 Sune Marcher <sm@...>
Permalink | Reply | 4 comments |
headers
Sune Marcher | 4 May 2006 21:04
Picon
Gravatar

traffic plugin: ignore interfaces

In case anybody's interested, here's a patch to make the traffic
plugin ignore certain interfaces - I got tired of 'dummy0' and 'lo'
showing up in my stats. Only works for /proc/net/dev source, and could
probably use some more work, but so could the entire plugin ;)

--

-- 
Best regards,
 Sune Marcher <sm@...>
Attachment (collectd-traffic-ignoreif.patch): application/octet-stream, 2592 bytes
Permalink | Reply | 1 comment |
headers
Claus Herwig | 4 May 2006 23:14
Picon

bind9 nameserver plugin?

Hello,

just a question: does anybody happen to work on a plugin for the bind9
nameserver to collect the queries/second?

Thanks,
  Claus

--

-- 
CHECON   EDV-Consulting und Redaktion
         Claus Herwig * Barer Straße 70 * 80799 München
         +49 89 27826981 * Fax 27826982 * c.herwig@...
Permalink | Reply | 5 comments |

Gmane