I find this to be useful when developping new input plugins,
it allows creating a very simple configuration and combined
with `-f` can be used for a very simple workflow.
I'm proposing this, since I think it could be useful for
people wanting to debug their config on local agents as well.
Alex Petrov [Wed, 17 Dec 2014 11:43:24 +0000 (12:43 +0100)]
Change "plugin_dispatch_multivalue" to accept any metric type.
Currently, "plugin_dispatch_multivalue" works only with
"gauge_t" metric type. This commit changes it to accept a
"store_type" (one of "DS_TYPE_{GAUGE|COUTNTER|ABSOLUTE|DERIVE}").
Vincent Bernat [Wed, 10 Dec 2014 14:41:49 +0000 (15:41 +0100)]
write_kafka: check for partition availability before selecting one
When a partition is unavailable, sending to it will just lead to a lost
metric. Therefore, after selecting the partition, check if it is
available. If not, select the next one until we tried them all.
A future iteration may use consistent hashing to avoid to double the
work done on a partition when the previous one is unavailable.
Marc Fournier [Wed, 3 Dec 2014 15:15:28 +0000 (16:15 +0100)]
netlink: ensure size_t portability in DEBUG() statement
This prevents the following error when building on 32bit systems with
gcc 4.7.2:
netlink.c: In function 'ir_read':
netlink.c:783:7: error: format '%lu' expects argument of type 'long unsigned int', but argument 5 has type 'size_t' [-Werror=format]
Marc Fournier [Tue, 2 Dec 2014 23:10:54 +0000 (00:10 +0100)]
zookeeper: initialize a variable
If the loop on line 132 doesn't iterate at least once, the function would
return the "sk" variable uninitialized.
This fixes the following build error:
cc1: warnings being treated as errors
zookeeper.c: In function 'zookeeper_read':
zookeeper.c:107: warning: 'sk' may be used uninitialized in this function
make[3]: *** [zookeeper.lo] Error 1
Florian Forster [Tue, 2 Dec 2014 10:09:32 +0000 (11:09 +0100)]
cpu plugin: Fix ValuesPercentage to behave as documented.
The documentation claims that ValuesPercentage is only considered when
!ByState && !ByCpu. Fix the behavior to match this documented behavior.
This makes cpu_commit_without_aggregation much easier.
Yoga Ramalingam [Wed, 12 Nov 2014 21:07:15 +0000 (16:07 -0500)]
collectdctl command hangs on AIX and returns error 0 on Solaris.
Summary:
Problem: collectdctl command hangs on AIX and returns error 0 on Solaris.
Root cause - client (collectdctl) and server (collectd daemon) are using fprintf to communicate using Unix domain socket, Since fprintf buffers, command sent by client did not reach server, since client does not get the response, it closes the socket which forces the client to flush the command, now server receives the command, when responding, it gets socket error because the client already closed the socket.
Solution: Added flush after all fprintf calls.
Test Plan: Tested collectdctl on AIX and SunOS for listval, getval commands
- The query is expected to be the block argument
- The type instance is inferred from the query if unsupplied
- The type will default to gauge if not supplied
Now that the redis plugin has moved to hiredis, it could
be worthwhile to add support for custom commands.
This diff implements a mechanism for executing commands which
allows for setting the type and type-instance. It doesn not
support hash or array returns, but if this is deemed necessary
could be added later on.
The canonical use case for this is for people using redis
has a queue (for instance, using solutions such as rq,
sidekiq and similar solutions) who want a simple way to
ensure the work queue size is not growing. To address this
you would use:
When reading from tables, upon errors the PDUs sent are already
freed by snmp_synch_response since they are right after
snmp_send is called.
This commit syncs collectd's approach with other occurences of
snmp_synch_response calls.
There might be a few corner cases where we leak PDUs, but it
is unclear how to check for those since we would need to
have an indication that snmp_send was never called, which
as far as I can tell is not possible.
The potential for failure in snmp_send is rather low and will
be easily spotted though, since when crafting invalid PDUs
snmp send will constantly fail and since valid configurations
can never leak memory.
When reading from tables, upon errors the PDUs sent are already
freed by snmp_synch_response since they are right after
snmp_send is called.
This commit syncs collectd's approach with other occurences of
snmp_synch_response calls.
There might be a few corner cases where we leak PDUs, but it
is unclear how to check for those since we would need to
have an indication that snmp_send was never called, which
as far as I can tell is not possible.
The potential for failure in snmp_send is rather low and will
be easily spotted though, since when crafting invalid PDUs
snmp send will constantly fail and since valid configurations
can never leak memory.
When reading from tables, upon errors the PDUs sent are already
freed by snmp_synch_response since they are right after
snmp_send is called.
This commit syncs collectd's approach with other occurences of
snmp_synch_response calls.
There might be a few corner cases where we leak PDUs, but it
is unclear how to check for those since we would need to
have an indication that snmp_send was never called, which
as far as I can tell is not possible.
The potential for failure in snmp_send is rather low and will
be easily spotted though, since when crafting invalid PDUs
snmp send will constantly fail and since valid configurations
can never leak memory.