Sven Trenkel [Tue, 22 Sep 2009 07:46:36 +0000 (09:46 +0200)]
netapp plugin: New plugin to collect statistics from NetApp filers.
Moin,
ich wollts ja eigentlich letzte Woche schon geschickt haben, aber hier ists
nun doch noch: Das collectd netapp Plugin. Es ist noch einiges an doppeltem
Code vorhanden, er ist noch nicht schön und der Configurationscode ist noch
nicht in der angemessenen Ausführlichkeit getestet, aber zumindest hier bei
mir funktioniert jetzt alles und ist voll konfiguriertbar.
Kompilieren tut ich das Ganze so:
gcc -g -c -Wall -I include -I /home/ifst/collectd-4.4.2/src netapp.c
gcc -g -o netapp.so -lnetapp -lxml -lpthread -ladt -lssl -lm -shared netapp.o
processes plugin: Remove unnecessary call of realloc(3).
Hi Florian (et al)
> you're right, the (re-)allocation of the memory can probably be avoided
> if the function is turned into one with the following prototype:
> -- 8< --
> static int *ps_read_tasks (int pid,
> unsigned long *ret_num_proc,
> unsigned long *ret_num_lwp);
> -- >8 --
Mmm, why not something like: "static int ps_read_task(pid)"?
This returns the number of task for pid passed as argument.
(AFAIK the function only return the number ot threads), why
we need the ret_num_proc and the ret_num_lwp parameters?
My proposal is attached (code is always cleaner than explanations :P)
Build system: Check for “libiptc/libip6tc.h” and “linux/netfilter/x_tables.h”, too.
Apparently “linux/netfilter/x_tables.h” is not available with older
kernels which leads to build fails there:
-- 8< --
In file included from libiptc.c:47,
from libip4tc.c:136:
xtables.h:24:38: linux/netfilter/x_tables.h: No such file or directory
-- >8 --
src/owniptc/Makefile.am: Don't search KERNEL_DIR for headers.
The iptc library is currenly only enabled, if the required headers where
found without “-I${KERNEL_DIR}”. Adding it to the CFLAGS when building
the shipped version of libiptc just breaks things, for example on
“collectd-master-amd64-linux-2.6”:
Linux hotdamn 2.6.9-42.ELsmp #1 SMP Tue Aug 15 10:35:26 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
Only check for “iptc_handle_t” and “ip6tc_handle_t” if using a
system-wide version of libiptc. If we use the shipped version, we *know*
it provides these types.
Build system: Improve detection of the iptc library.
When checking for the iptc headers and data types, the configure script
added the kernel directory to the CFLAGS. Later, when actually building
the iptables plugin, the CFLAGS were left untouched.
At least on Debian, the “real” kernel headers are not required – the
libc versions in /usr/include/linux are sufficient. The usage of
KERNEL_DIR has therefore been removed from the iptc checks.
In addition, an directory specified by “--with-libiptc=/path” is no
longer added to the global CFLAGS but rather to the iptables specific
CPPFLAGS.
Hopefully this resolved build problems on various platforms.
scale target: Fix C90 warning (which is upgraded to an error by default).
Should fix this warning:
-- 8< --
target_scale.c: In function 'ts_invoke_counter':
target_scale.c:90: warning: this decimal constant is unsigned only in ISO C90
target_scale.c:91: warning: this decimal constant is unsigned only in ISO C90
target_scale.c:93: warning: integer constant is too large for 'unsigned long' type
-- >8 --
powerdns plugin: Use the “ipt_packets” type rather than “io_packets”.
“io_packets”, as the name suggests, requires incoming *and* outgoing
packets. The infrastructure of the powerdns plugin uses only value lists
with one data source though.
Sebastian Harl [Sun, 6 Sep 2009 12:14:55 +0000 (12:14 +0000)]
iptables plugin: Support the new libiptc API.
When libiptc has been officially made available as a shared library, the API
and ABI have been changed slightly. By checking for the existance of a type
that has been removed in that course, configure now checks which version is
available. This is quite error prone (the type might be re-introduced any
time), so this should be improved some time - currently, I do not have an idea
how to do so, though :-/
src/owniptc: Moved the “src/libiptc” directory to “src/owniptc” to avoid build issues.
If there is a system-wide version of this library available, the “-I.”
argument (added automatically by automake :() will lead to the shipped
header files being used. Later, the binary is linked with the
system-wide library, which leads to severe problems when API/ABI
incompatibilities have been introduced in other versions.
Andrés J. Díaz [Mon, 31 Aug 2009 19:16:41 +0000 (21:16 +0200)]
src/utils_threshold.c: Implement the “Hits” and “Hysteresis” config options.
Hi all!
Based on Mariusz's idea, i attach a patch for thresholds (no for
filtering, yet) with basic hysteresis support adding the keyword
Hysteresis to configuration file, for example:
In this case the notification is raised when load (midterm datasource)
is greater than 1, and came back to OKAY when lower than 0.7 (1 - 0.3).
This is a proof of concept and I do not have a lot of time to test,
please use this patch with caution. Furthermore, the code is really hard
and dirty :)
Best regards,
Andres
P.S.: The patch also including hits support, so to compile you also
require to apply hits-cache.patch and, obviously this patch is
incompatible with hits-threshold.patch.
I've attached a patch to add hit counter to thresholds, that is, each
time when threhsold raised, then an internal hit counter is incremented,
when the value of the counter raise a specific value setted in
configuration, then the notification is generated and counter is reset.
Here are an example of threshold configuration with hit conter:
On Monday 31 August 2009 09:03:37 Sebastian Harl wrote:
> Hrm … from a quick look at the libcrypt documentation I suppose we need
> to call gcry_control() using the 'GCRYCTL_INIT_SECMEM' command to
> explicitly initialize the secure memory. Sounds like this was required
> in libgcrypt 1.4.1 but is handled automatically in later versions.
>
also looks like there's some special initialization necessary for threads. I
doubt that this is handled by the new default behavior in 1.4.4. Don't know
that it's truly necessary if the network plugin is the only plugin using
gcrypt.
Here's a patch that works for me with 1.4.1.
I followed an example for pthread initialization and initialized gcry to 32k,
only since that's apparently the default that's used in 1.4.3. I did it in
network.c's module_register function. Kind of an abuse, I know.
Florian Forster [Thu, 27 Aug 2009 07:06:16 +0000 (09:06 +0200)]
curl_json plugin: Renamed the “couchdb” plugin to “curl_json”.
On Thu, Aug 20, 2009 at 10:31:22AM -0700, Doug MacEachern wrote:
> Wanted to bring this up before 4.8..
> When I first started on the couchdb plugin, there were metrics
> specific to couchdb, but ended up making it generic and the metrics
> are all specified in the config. Since then, I've looked at Dynomite
> which has its own set of metrics exposed the same way:
> http://gist.github.com/137771
> Also noticed Hadoop 0.21 daemons now support: "/metrics?format=json to
> retrieve the data in a structured form.", but haven't had a chance to
> try yet. I'm sure there's more too. So I'm wondering if 'couchdb'
> should be renamed to something more generic, 'json' or 'yajl' maybe?
> And/or pushing the curl/yajl code out to util functions, then add the
> couchdb specific metrics to the couchdb plugin. Then also use the
> util functions for dynomite, hadoop, etc., specific plugins. Thoughts?
projects / thirdparty / collectd.git / log
