Re: [collectd] New aggregator plugin basic_aggregator (#136)
On Sat, Oct 13, 2012 at 09:27:25AM +0200, Sebastian Harl wrote: most/many/all parts of collectd actually support reconfigure as people might expect too much from SIGHUP else. agreed Just to be sure: the main collectd thread has no control over its child threads in the current implementation? ___ collectd mailing list collectd@verplant.org http://mailman.verplant.org/listinfo/collectd
Re: [collectd] Modbus plugin seems to read garbage values
Hi, On Fri, Oct 12, 2012 at 05:30:32PM +0200, Gerry Demaret wrote: I've been playing with the modbus plugin to read the values from a Schneider Electric PowerLogic EGX100. I'm using Debian testing which has collectd 5.1. Are you sure the device is sending correct values? We've got an EGX400, and it's been a real PITA ever since we've comissioned it. We ended up writing our own plugin retrieving the data via ftp/http from the box. Then again, I've never used float type for registers, but I guess you've already played with that, as the EGX100 user guide seems rather sparse on this matter. Anyway, if it's just a matter of linear transformation, you could use the scale target plugin. Your config looks fine to me - Cheers ___ collectd mailing list collectd@verplant.org http://mailman.verplant.org/listinfo/collectd
Re: [collectd] New aggregator plugin basic_aggregator (#136)
Hi, On Sat, Oct 13, 2012 at 10:51:34AM +0200, Fabien Wernli wrote: On Sat, Oct 13, 2012 at 09:27:25AM +0200, Sebastian Harl wrote: most/many/all parts of collectd actually support reconfigure as people might expect too much from SIGHUP else. agreed Just to be sure: the main collectd thread has no control over its child threads in the current implementation? As mentioned on IRC: the main collectd process controls the child threads by means of a pthread conditional variable and a boolean variable indicating whether the main process is still in its main loop. The former may be used to signal the child threads to re-check the read loop condition. HTH, Sebastian -- Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature ___ collectd mailing list collectd@verplant.org http://mailman.verplant.org/listinfo/collectd
[collectd] RFC: implementing reload/reconfigure (was: New aggregator plugin basic_aggregator (#136))
Hi again, just a few more notes / detail … On Thu, Oct 11, 2012 at 09:11:24AM +0200, Sebastian Harl wrote: Now, my idea is to introduce a reconfigure callback that allows to reconfigure a single plugin. This could then be exposed, for example, through the 'unixsock' plugin. Example: /* plugin.h */ int plugin_register_reconfig (const char *name, int (*callback) (oconfig_item_t *)); /* UNIXSOCK */ RECONFIGURE PluginName Obviously, reconfigure will fail if the specified plugin did not register a reconfig callback. In case, the plugin did not specify a config callback either, reconfigure could be a no-op (no error). Internally, the callback would trigger re-parsing the whole collectd.conf file. Then, the appropriate config-block would be dispatched to the registered reconfig callback just in the same way that the original configuration was dispatched to the config callback. When thinking about the detailed side-effects, I came across the following: currently, collectd allows to specify multiple Plugin blocks for a single plugin. This is not documented anywhere and should not be considered to be officially supported. The current behavior greatly depends on the plugin. However, quite a few plugins probably handle this situation sanely and, thus, this might be used in a couple of reasonable use-cases. Now, when thinking about a reconfig operation, most plugins will probably de-configure and re-read the new configuration (possibly leaving some caches or certain state-information in place). Obviously, this would not work if there are more than one Plugin blocks. I.e., a plugin would behave differently when being configured and when being re-configured. The question is if this should be considered at all (after all, it's not officially supported). However, by splitting the reconfig into deconfig and reconfig (or config), we could easily handle this situation as well. So, I suggest the following: - typedef int (*deconfig_cb) (void); - typedef int (*reconfig_cb) (oconfig_item_t *); That is, 'deconfig' would use the same signature as 'shutdown' and 'reconfig' would use the same signature as 'config'. This would allow to use the appropriate callbacks twice, which in most cases should be sufficient (probably plus some checks for current settings). Any thoughts, comments on this? As a second step we could then think about also implementing a reload action. This would mean unloading and reloading the shared object of a plugin and then doing a reconfigure. In fact, thinking about this again, I think that a global reload should not unload and re-load the shared objects (but possibly unload plugins that are no longer used and load new plugins). Else, it's gonna be hard to keep plugin-global information (caches, etc.) in place. However, a second operation (available through the 'unixsock' plugin and similar) could be used for that case if anybody comes up with a use-case for that. Cheers, Sebastian -- Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature ___ collectd mailing list collectd@verplant.org http://mailman.verplant.org/listinfo/collectd
Re: [collectd] Modbus plugin seems to read garbage values
On 13/10/12 11:06, Fabien Wernli wrote: Are you sure the device is sending correct values? We've got an EGX400, and it's been a real PITA ever since we've comissioned it. We ended up writing our own plugin retrieving the data via ftp/http from the box. Then again, I've never used float type for registers, but I guess you've already played with that, as the EGX100 user guide seems rather sparse on this matter. Hi Fabien, Thanks for your reply. Turns out my config wasn't okay. The EGX's manual states that for example register 3000 holds the value for the current going through l1, so I assumed 3000 and 3001 were used to contain the float. Turns out it is actually 2999 and 3000. So this works: Data current-phase1 RegisterBase 2999 RegisterType float Type current Instance phase1 /Data Whereas this only produces garbage: Data current-phase1 RegisterBase 3000 RegisterType float Type current Instance phase1 /Data Also, regarding the patch I had to apply in order to have modbus working at all; is that already included in a newer version? Oh by the way, might be useful for your EGX400; after updating the EGX100's firmware to 3.0 its SNMP seems to have become a lot more responsive and might actually contain the data you need as well. Might be a better solution instead of parsing the HTTP output? :) Gerry. ___ collectd mailing list collectd@verplant.org http://mailman.verplant.org/listinfo/collectd
