ChangeLog: Updated for the 4.8.0 release.
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:
<Threshold>
<Type "load">
DataSource "midterm"
WarningMax 1
Hysteresis 0.3
</Type "load">
</Treshold>
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.
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
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:
<Threshold>
<Type "load">
DataSource "midterm"
WarningMax 1
Hysteresis 0.3
</Type "load">
</Treshold>
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.
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
src/utils_cache.c: Implement “uc_{get,set,inc}_hits”.
Hi
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:
<Threshold>
<Plugin load>
<Type load>
WarninMax 1
Hits 3
</Type>
</Plugin>
</Threshold>
In this example the notification will be generated when load value is
greater than 1 for 3 intervals.
Here are two patches, the first one adds hit feature to the collectd
cached and the second one use hits in thresholds,
Of course comments and suggestions are welcome :)
Enjoy!
Regards,
Andres
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
Hi
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:
<Threshold>
<Plugin load>
<Type load>
WarninMax 1
Hits 3
</Type>
</Plugin>
</Threshold>
In this example the notification will be generated when load value is
greater than 1 for 3 intervals.
Here are two patches, the first one adds hit feature to the collectd
cached and the second one use hits in thresholds,
Of course comments and suggestions are welcome :)
Enjoy!
Regards,
Andres
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
contrib/collection3: Add graphing module for “arc_counts”.
Managed to forget this: script for generating the ArcCounts graphs.
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
Managed to forget this: script for generating the ArcCounts graphs.
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
zfs_arc plugin: add to default config file
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
write_http plugin: Make it possible to send values as JSON.
write_http plugin: Send “\r\n” line endings.
write_http plugin: Suppress the “Expect:” header.
write_http plugin: Fix a typo.
Merge branch 'ad/arc'
network plugin: “sizeof (send_buffer)” → “network_config_packet_size”.
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
README, AUTHORS: Add information about the zfs_arc plugin and Anthony.
zfs_arc plugin: Fix a small typo.
zfs_arc plugin: Renamed the “arc” plugin to “zfs_arc”.
arc plugin: Remove a left-over `printf'.
ARC stats plugin
Get stats for ZFS's Adaptive Replacement Cache.
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
Get stats for ZFS's Adaptive Replacement Cache.
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
Merge branch 'ps/http'
write_http plugin: Implement the usual SSL options.
write_http plugin: Implement support for multiple destinations.
collectd.conf(5): Updated to reflect the renaming of the “write_http” plugin.
write_http plugin: Rename the “http” plugin to “write_http”.
collectd.conf(5): Renamed the couchdb plugin to curl_json here, too.
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?
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?
configure.in: Check for the <linux/wireless.h> header.
network plugin: Free dynamically allocated buffers when appropriate.
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
configure.in: Sort the status output alphabetically.
http plugin: Update the copyright notice and AUTHORS file.
http plugin: Small fixes for the buffer handling.
Don't actually send anything when the buffer is empty. Initialize the
buffer in the ‘init’ function.
Don't actually send anything when the buffer is empty. Initialize the
buffer in the ‘init’ function.
http plugin: Implement a `flush' callback.
http plugin: http_write: Clean-up.
A couple of bugs have been fixed in the process. One error handling path
didn't release a mutex, for example. Also, the buffer may have been sent
truncated.
A couple of bugs have been fixed in the process. One error handling path
didn't release a mutex, for example. Also, the buffer may have been sent
truncated.
http plugin: Comment in the call to `curl_easy_perform'.
http plugin: http_value_list_to_string: Clean-up.
http plugin: Use the `FORMAT_VL' macro.
http plugin: Don't convert COUNTER values to rates.
http plugin: Remove an unused variable.
http plugin: Rename the “Location” option to “URL”.
That's more in line with other plugins.
That's more in line with other plugins.
http plugin: Remove tailing whitespace.
http plugin: Add entries to collectd.conf
http plugin: Man page about config vars
http plugin: Put the makefile stuff in the right place alphabetically
http plugin: Make the output match the PUTVAL plain-text protocol
configure.in: Add the http plugin to the status output.
http plugin: Remove trailing whitespace.
http plugin: Better error handling, and flush before shutdown
http plugin: Remove some debugging info
http plugin: POST when a 4K buffer is nearly full
http plugin: Set mutex around curl, so we only perform once at a time
http plugin: Fix a memory leak by cleaning up the curl handles
http plugin: don't copy the error buffer
http plugin: Dont hold open curl connections. It ties up apache
http plugin: Initialze curl every time, to we don't clobber things
http plugin: Separate values into multiple lines
http plugin: it works, i think
http plugin: Start in http plugin that can output csv to stdout
java bindings: GenericJMX: Implement user/password authentication.
network plugin: Remove a now invalid assertion.
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
contrib/GenericJMX.conf: Fix some typos and improve type instances.
src/types.db: Sort alphabetically.
contrib/GenerixJMX.conf: Add some example configuration for Tomcat.
Currently configured for tomcat are:
* Received / sent octets for each request processor.
* Number of requests.
* Time spent processing queries.
* Number of total/busy threads.
The first three values are available as a summary for a request processor
as well as detailed (for each thread).
This configuration is yet untested and may contain obvious typos!
Currently configured for tomcat are:
* Received / sent octets for each request processor.
* Number of requests.
* Time spent processing queries.
* Number of total/busy threads.
The first three values are available as a summary for a request processor
as well as detailed (for each thread).
This configuration is yet untested and may contain obvious typos!
java bindings: GenericJMX plugin: Implement the ‘InstanceFrom’ option for <value /> blocks.
swap plugin: Fix the ‘swap_submit’ invocation of non-Linux implementations.
And replace all the ‘unsigned long long’s with ‘derive_t’.
And replace all the ‘unsigned long long’s with ‘derive_t’.
added swapin/out support to swap plugin
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
Merge branch 'mg/jitter'
collectd.conf(5): Document the new `RandomTimeout' option.
rrdtool plugin: Optimize away the ‘random_timeout_mod’ variable.
rrdtool plugin: Call rand(3) less often.
2009/8/18 Florian Forster <octo@verplant.org>:
> Hi Mariusz,
>
> On Mon, Aug 17, 2009 at 02:20:29AM +0200, Mariusz Gronczewski wrote:
>> i was thinking how to "spread out" writes to rrd files a bit, because
>> now its big spike every CacheTimeout or little smaller "square" on
>> graph if u use WritesPerSecond.
>
> in general I like your patch, thank you very much for posting it :)
> I have some doubts about calling rand() in such a busy place though,
> since getting random numbers is potentially costly. Also, rand(3) is not
> thread-safe, though I don't think that's really an issue for us.
Yeah good point, but that would be probably noticable on very slow
(like PIII 800 slow) machines with tons of rrd, and then machine would
run out of disk bandwidth first.
> Maybe a solution would be to add a ‘random_timeout’ member to the
> ‘rrd_cache_t’ struct, too. This member is then set when creating the
> entry and set again right after the values have been removed. That way
> rand(3) is only called once for each write instead of calling for every
> check.
Yeah, very good idea, i didnt thougth about that (well tbh. i didnt
looked much into "interiors" of rrdtool plugin). Ive implemented it in
attached patch, so far ive been testing it for about 1 hour and works
pretty well.
> As an interesting sidenote: With the above approach, the random write
> times are distributed “uniform”, i. e. every delay from 0 to max-1
> seconds has the same probability. With your code, I think the actual
> time a value is written follows a “normal” distribution (you know, that
> famous bell curve). So I'd expect the above approach to spread the value
> quicker.
Yup, exactly as u said, its much quicker like that.
Im wondering how config variable should be called, name
"RandomTimeout" dont mean anything useful ("random timeout of what?"),
maybe TimeoutSpread ? RandomizeTimeout ?
2009/8/18 Florian Forster <octo@verplant.org>:
> Hi Mariusz,
>
> On Mon, Aug 17, 2009 at 02:20:29AM +0200, Mariusz Gronczewski wrote:
>> i was thinking how to "spread out" writes to rrd files a bit, because
>> now its big spike every CacheTimeout or little smaller "square" on
>> graph if u use WritesPerSecond.
>
> in general I like your patch, thank you very much for posting it :)
> I have some doubts about calling rand() in such a busy place though,
> since getting random numbers is potentially costly. Also, rand(3) is not
> thread-safe, though I don't think that's really an issue for us.
Yeah good point, but that would be probably noticable on very slow
(like PIII 800 slow) machines with tons of rrd, and then machine would
run out of disk bandwidth first.
> Maybe a solution would be to add a ‘random_timeout’ member to the
> ‘rrd_cache_t’ struct, too. This member is then set when creating the
> entry and set again right after the values have been removed. That way
> rand(3) is only called once for each write instead of calling for every
> check.
Yeah, very good idea, i didnt thougth about that (well tbh. i didnt
looked much into "interiors" of rrdtool plugin). Ive implemented it in
attached patch, so far ive been testing it for about 1 hour and works
pretty well.
> As an interesting sidenote: With the above approach, the random write
> times are distributed “uniform”, i. e. every delay from 0 to max-1
> seconds has the same probability. With your code, I think the actual
> time a value is written follows a “normal” distribution (you know, that
> famous bell curve). So I'd expect the above approach to spread the value
> quicker.
Yup, exactly as u said, its much quicker like that.
Im wondering how config variable should be called, name
"RandomTimeout" dont mean anything useful ("random timeout of what?"),
maybe TimeoutSpread ? RandomizeTimeout ?
src/Makefile.am: Add `madwifi.h' to madwifi_la_SOURCES.
The header file was not included in generated distribution tarballs.
The header file was not included in generated distribution tarballs.
network plugin: Add MaxPacketSize config option to the network plugin.
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
Signed-off-by: Florian Forster <octo@leeloo.lan.home.verplant.org>
contrib/GenericJMX.conf: Fix ‘property patterns’ in the sample config.
See also: <http://java.sun.com/j2se/1.5.0/docs/api/javax/management/ObjectName.html>
See also: <http://java.sun.com/j2se/1.5.0/docs/api/javax/management/ObjectName.html>
Random write timeout for rrdtool plugin
Hi,
i was thinking how to "spread out" writes to rrd files a bit, because
now its big spike every CacheTimeout or little smaller "square" on
graph if u use WritesPerSecond. So ive written little patch which
"spreads out" writing by changing Cache timeout every time rrdtool
plugin finds data to save. Basically instead of moving data older than
CacheTimeout to write queue it moves it if its older than CacheTimeout
+- RandomTimeout. What it changes?
Without it, gathered data is "synchronised" with eachother, for
example (CacheTimeout = 600):
1.collectd starts
2. after 10 minutes, data from all plugins get "too old" and get
pushed into write queue and get saved
3. after another 10 minutes, same thing, all data "ages" at same time
and get saved in one big chunk
With it (RandomTimeout=300) it works like that
1. collectd starts
2. after 5 minutes some data (lets call it A) starts to go into write queue
3. after 10 minutes from start about 50% (on average) data is saved
(lets call it B)
4. finally, after 15 minutes, all "leftover" data gets saved (lets call it C)
5. next "cycle"
6. data A ages first (cos it was put to disk first) and like before,
some of it gets writen earlier, some of it gets written later)
7. after that data B ages and like before writes are spread over 10 mins
8. same with C
so first cycle (looking at i/o) looks like sinus, next 10 minute cycle
is same sinus but flattened a bit and so on (looks like fading sinus),
and after few cycles it gives pretty much same amount on writes per
sec, no ugly spikes.
Effect looks like that:
http://img24.imageshack.us/img24/7294/drrawcgi.png
(after few more h it will be more "smooth")
Regards
Mariusz
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
Hi,
i was thinking how to "spread out" writes to rrd files a bit, because
now its big spike every CacheTimeout or little smaller "square" on
graph if u use WritesPerSecond. So ive written little patch which
"spreads out" writing by changing Cache timeout every time rrdtool
plugin finds data to save. Basically instead of moving data older than
CacheTimeout to write queue it moves it if its older than CacheTimeout
+- RandomTimeout. What it changes?
Without it, gathered data is "synchronised" with eachother, for
example (CacheTimeout = 600):
1.collectd starts
2. after 10 minutes, data from all plugins get "too old" and get
pushed into write queue and get saved
3. after another 10 minutes, same thing, all data "ages" at same time
and get saved in one big chunk
With it (RandomTimeout=300) it works like that
1. collectd starts
2. after 5 minutes some data (lets call it A) starts to go into write queue
3. after 10 minutes from start about 50% (on average) data is saved
(lets call it B)
4. finally, after 15 minutes, all "leftover" data gets saved (lets call it C)
5. next "cycle"
6. data A ages first (cos it was put to disk first) and like before,
some of it gets writen earlier, some of it gets written later)
7. after that data B ages and like before writes are spread over 10 mins
8. same with C
so first cycle (looking at i/o) looks like sinus, next 10 minute cycle
is same sinus but flattened a bit and so on (looks like fading sinus),
and after few cycles it gives pretty much same amount on writes per
sec, no ugly spikes.
Effect looks like that:
http://img24.imageshack.us/img24/7294/drrawcgi.png
(after few more h it will be more "smooth")
Regards
Mariusz
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
Merge branch 'collectd-4.7'
java plugin: Fix configuration with multiple blocks.
The number of children was not updated.
The number of children was not updated.
Merge branch 'collectd-4.7'
Conflicts:
src/network.c
Conflicts:
src/network.c
java plugin: Wait with the configuration until the daemon has forked.
Passing the configuration to Java-based plugins requires the JVM to be
active and running. However, the JVM starts some threads that are lost
when the daemon forks to the background.
This patch changes the behavior of the Java plugin to copy the
configuration blocks found to a local variable and run the configuration
of the Java-based plugins from the `init' callback, because it is
invoked after the daemon has forked to the background.
Passing the configuration to Java-based plugins requires the JVM to be
active and running. However, the JVM starts some threads that are lost
when the daemon forks to the background.
This patch changes the behavior of the Java plugin to copy the
configuration blocks found to a local variable and run the configuration
of the Java-based plugins from the `init' callback, because it is
invoked after the daemon has forked to the background.
Merge branch 'collectd-4.6' into collectd-4.7
contrib/fedora/init.d-collectd: Fix condrestart.
on upgrade collectd is not restarted
https://bugzilla.redhat.com/show_bug.cgi?id=516273
Signed-off-by: Alan Pevec <apevec@redhat.com>
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
on upgrade collectd is not restarted
https://bugzilla.redhat.com/show_bug.cgi?id=516273
Signed-off-by: Alan Pevec <apevec@redhat.com>
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
madwifi plugin: Signal an error in the read function when appropriate.
An error will be signaled to the daemon if querying all interfaces failed.
Querying an interface fails if all ioctls return an error.
An error will be signaled to the daemon if querying all interfaces failed.
Querying an interface fails if all ioctls return an error.
src/utils_cache.c: Update GETVAL output when missing state.
Hi
I think that I've found a bug when use unixsock plugin. The problem is
releate with missing state, when no value is received by daemon for a
while in the cache is marked as MISSING, but the last value is still
showing even when machine is not reporting in a GETVAL and LISTVAL
commands. Some utlities like collectd-nagios does not work correctly,
and report an OKAY value when host is not reporting from a long time.
I attach a patch with check the state value of an cache entry in
uc_get_names and in uc_get_rate_by_name. This patch works for me, but
it's not very tested yet, and I not very sure about if it's a good way
to check the problem. The patch is tested on 4.7.2 release version.
BTW a GETSTATE command will be an useful feature too :P
Regards,
Andres
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
Hi
I think that I've found a bug when use unixsock plugin. The problem is
releate with missing state, when no value is received by daemon for a
while in the cache is marked as MISSING, but the last value is still
showing even when machine is not reporting in a GETVAL and LISTVAL
commands. Some utlities like collectd-nagios does not work correctly,
and report an OKAY value when host is not reporting from a long time.
I attach a patch with check the state value of an cache entry in
uc_get_names and in uc_get_rate_by_name. This patch works for me, but
it's not very tested yet, and I not very sure about if it's a good way
to check the problem. The patch is tested on 4.7.2 release version.
BTW a GETSTATE command will be an useful feature too :P
Regards,
Andres
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
src/utils_cache.c: Update GETVAL output when missing state.
Hi
I think that I've found a bug when use unixsock plugin. The problem is
releate with missing state, when no value is received by daemon for a
while in the cache is marked as MISSING, but the last value is still
showing even when machine is not reporting in a GETVAL and LISTVAL
commands. Some utlities like collectd-nagios does not work correctly,
and report an OKAY value when host is not reporting from a long time.
I attach a patch with check the state value of an cache entry in
uc_get_names and in uc_get_rate_by_name. This patch works for me, but
it's not very tested yet, and I not very sure about if it's a good way
to check the problem. The patch is tested on 4.7.2 release version.
BTW a GETSTATE command will be an useful feature too :P
Regards,
Andres
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
Hi
I think that I've found a bug when use unixsock plugin. The problem is
releate with missing state, when no value is received by daemon for a
while in the cache is marked as MISSING, but the last value is still
showing even when machine is not reporting in a GETVAL and LISTVAL
commands. Some utlities like collectd-nagios does not work correctly,
and report an OKAY value when host is not reporting from a long time.
I attach a patch with check the state value of an cache entry in
uc_get_names and in uc_get_rate_by_name. This patch works for me, but
it's not very tested yet, and I not very sure about if it's a good way
to check the problem. The patch is tested on 4.7.2 release version.
BTW a GETSTATE command will be an useful feature too :P
Regards,
Andres
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
madwifi plugin: Rename the antenna stats.
The first part of the type instance is already something like `ast_ant_rx' -
using `antenna%i' as the second part is therefore redundant. Thanks to Ondrej
for the pointer.
The first part of the type instance is already something like `ast_ant_rx' -
using `antenna%i' as the second part is therefore redundant. Thanks to Ondrej
for the pointer.
madwifi plugin: Unify ioctl error handling.
If an ioctl fails, a debug message is generated rather than an error message.
There are several types of interfaces manages by the madwifi driver, and not
all interfaces support all ioctls. Thanks to Ondrej for pointing this out.
If an ioctl fails, a debug message is generated rather than an error message.
There are several types of interfaces manages by the madwifi driver, and not
all interfaces support all ioctls. Thanks to Ondrej for pointing this out.
madwifi plugin: Fix buffer handling around `readlink'.
readlink(2) doesn't null-terminate the buffer in any case. Thanks to Ondrej for
pointing this out.
readlink(2) doesn't null-terminate the buffer in any case. Thanks to Ondrej for
pointing this out.
src/plugin.c: Make `plugin_unregister_read' functional again.
Merge branch 'ff/genericjmx'
libvirt plugin: Further improve the connection handling.
Use the complaint mechanism for failed connection attempts and handle multiple
`Connection' configuration options like other options in other plugins (i. e.
later options overwrite earlier settings of the same name).
Use the complaint mechanism for failed connection attempts and handle multiple
`Connection' configuration options like other options in other plugins (i. e.
later options overwrite earlier settings of the same name).
libvirt plugin: Re-connect to libvirtd if connecting fails.
https://bugzilla.redhat.com/show_bug.cgi?id=480997
Signed-off-by: Alan Pevec <apevec@redhat.com>
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
https://bugzilla.redhat.com/show_bug.cgi?id=480997
Signed-off-by: Alan Pevec <apevec@redhat.com>
Signed-off-by: Florian Forster <octo@huhu.verplant.org>
src/meta_data.c: Fix a typo.
AUTHORS: Add Ondrej.
madwifi plugin: Add some assertions …
… to otherwise unchecked array indices.
… to otherwise unchecked array indices.
madwifi plugin: Fix a few best practices.
Use `sstrncpy' and `ssnprintf' instead of the unsafe versions. Don't
specify array dimensions twice. Don't cast _Bool to int.
Use `sstrncpy' and `ssnprintf' instead of the unsafe versions. Don't
specify array dimensions twice. Don't cast _Bool to int.
madwifi plugin: Rename the ‘DisableSysfs’ to ‘Source’.
Configurations like
DisableSysfs false
are confusing.
Configurations like
DisableSysfs false
are confusing.
madwifi plugin: Plugin for detailed information from the MadWifi driver.
Hello
After some time i managed to make a new version of Madwifi plugin. The
main change is that it is possible to finely tune the set of monitored
statistics and just the most important statistics are monitored by
default. Also the number of new data types is reduced (by using type
instances).
Signed-off-by: Florian Forster <octo@verplant.org>
Hello
After some time i managed to make a new version of Madwifi plugin. The
main change is that it is possible to finely tune the set of monitored
statistics and just the most important statistics are monitored by
default. Also the number of new data types is reduced (by using type
instances).
Signed-off-by: Florian Forster <octo@verplant.org>
collectd.conf(5): Fix two minor typos.
src/utils_cache.c: Don't tell the user about missing values.
This is bound to confuse users..
This is bound to confuse users..
network plugin: Use the meta data to implement the `Forward' option.
Previously, a cache in the network plugin was used to keep track of
which values were received via the network in order to distinguish
between ``forwarded'' values and values that were received from
somewhere else.
The same cache was also used to avoid loops when forwarding packages by
keeping track of the highest timestamp that was sent by the plugin and
discard received data that was older or as old as that.
This information is not kept in the meta data of the global cache (what
is the last timestamp sent) and the meta data of the value list (was
this value list received via the network?). The cache that was
maintained in the network plugin has been removed.
Previously, a cache in the network plugin was used to keep track of
which values were received via the network in order to distinguish
between ``forwarded'' values and values that were received from
somewhere else.
The same cache was also used to avoid loops when forwarding packages by
keeping track of the highest timestamp that was sent by the plugin and
discard received data that was older or as old as that.
This information is not kept in the meta data of the global cache (what
is the last timestamp sent) and the meta data of the value list (was
this value list received via the network?). The cache that was
maintained in the network plugin has been removed.
src/utils_cache.[ch]: Make the `value_list_t *' const.
The struct is only needed to build the name (a string) anyway..
The struct is only needed to build the name (a string) anyway..
network plugin: Fix an incorrectly used configuration variable.
The `CacheFlush' option was assigned to the `TTL' variable. Ouch.
Version 4.6 and earlier are not effected.
The `CacheFlush' option was assigned to the `TTL' variable. Ouch.
Version 4.6 and earlier are not effected.
src/utils_cache.c: Free the meta data when removing a cache entry.
src/utils_cache.[ch]: Implement a meta-data interface for cached values.
This should make it possible to write stateful matches and similar nifty
stuff - at last \o/
This should make it possible to write stateful matches and similar nifty
stuff - at last \o/
src/common.h: Remove the `ds' argument from the `FORMAT_VL' macro.
Since `type' is now included in `value_list_t' the `data_set_t' is no
longer required.
Since `type' is now included in `value_list_t' the `data_set_t' is no
longer required.