Re: [collectd] Interest in another in person meeting or hackfest?

[Sebastian Harl]

Hi,

On Fri, Dec 20, 2019 at 12:27:52PM +0100, Matthias Runge wrote:
> On 14/11/2019 20:01, Matthias Runge wrote:
> > I just wanted to circle the idea of having another
> > in person meetup, probably pre-FOSDEM in Brussels (like we had this year
> > [1]).

> Let's move this a bit later in the year and also to a different
> location. I have a plan where to have a meetup and roughly when,
> but I need to figure out the last details.

Thanks Matthias for setting this up!

I'm very interested in joining as well but I would have had a hard time
making it to Brussels. Munich, some time in February, should work for me
however.

Did you have plans yet for how to find a time that works for most
people? What days of the week would people prefer?

> Meanwhile, the etherpad is still up and open:
> https://etherpad.openstack.org/p/collectd-meetup-2020

This is a great list!

Cheers,
Sebastian


___
collectd mailing list
collectd@verplant.org
https://mailman.verplant.org/listinfo/collectd

Re: [collectd] Collectd Release Process Proposal

[Sebastian Harl]

Hi,

On Fri, Jul 19, 2019 at 07:26:44PM +0700, Pavel wrote:
> 19.07.2019 18:35, Sebastian Harl пишет:
> > Again, I fully understand your frustration and agree with you that
> > things have not been going well which is why we're working on improving
> > them and fixing the policy and processes.
> 
> "we're working" ... "improving"... I see all the results of "improvements"
> 
> > Based on your responses, I believe you're still very interested in the 
> > project
> 
> I just don't like to throw away the results of my work.
> And I just use Collectd on my servers.
> 
> > and it's goals and I hope that we can work together on finding an 
> > appropriate path forward.
> I don't know what are the goals and who really works on project.
> I see only several contributors, which permissions are same as mine was.
> Me and these people unable to tune project direction, we can only put new
> own PR or merge another's PR.
> 
> > Do you think the proposal is going into the right direction? Did
> > Matthias's change fix the most immediate issue at hand around code
> > owners?
> 
> Your question shows the real depth of the analysis of the problem and depth
> of control over what is happening.
> I already answered in #3224: I can't check this. Also, @rjablonx left his
> comment too, about additional actions which are required.
> 
> However, again, I dont think this is "direction". This is "patch" only,
> which tries to glue broken communication.
> 
> Such a patch does not make a thing brand new, and you will not go into a
> decent society in it.

I consider the proposal[1] a first (but important) step to hand more
"power" to the community at large, to allow more active contributions
from multiple parties and ultimately make it easier for others to
influence the project. My personal involvement is currently limited to
trying to fix the low level organizational aspects of all of this to
enable further work on top of that.

What do you think is missing to make this a more compelling and
impactful proposal rather than just a "patch"?

Cheers,
Sebastian

[1] 
https://docs.google.com/document/d/1Ha9zPyKa_1pBar58LUPRf4EV2ap1sMcrOtRz3qauogo


___
collectd mailing list
collectd@verplant.org
https://mailman.verplant.org/listinfo/collectd

Re: [collectd] Collectd Release Process Proposal

[Sebastian Harl]

Again, I fully understand your frustration and agree with you that
things have not been going well which is why we're working on improving
them and fixing the policy and processes. Based on your responses, I
believe you're still very interested in the project and it's goals and I
hope that we can work together on finding an appropriate path forward.
Do you think the proposal is going into the right direction? Did
Matthias's change fix the most immediate issue at hand around code
owners?

On Fri, Jul 19, 2019 at 05:19:56PM +0700, Pavel wrote:
> 19.07.2019 16:49, Sebastian Harl пишет:
> > Hi,
> > 
> > I understand the frustration here but I'd like to remind you that many
> > of us are working on collectd in their "spare time" and life can get
> > into the way of that. That's what this proposal is intended to address.
> 
> I want to remind YOU that many of us working on Collectd in ours _spare
> time_,
> and Team SHOULD do all possible to facilitate the work of people.
> 
> But I see the opposite.
> 
> https://github.com/collectd/collectd/issues/2958#issuecomment-464988065
> 
> There is no changes in "policy" for 5 months.
> There is no feedback.
> 
> Maintainer is ignored. Maintainer is unable to merge own changes.
> 
> If you ignore your maintainers, you will not found support from community
> and project will dead.
> 
> > There is no plan to fork the project
> 
> What would be strange to hear about fork plans from person with email in
> @collectd.org domain.
> From person of Team who implement destroying changes.
> 
> > but to improve how it operates so
> > that it scales to the community of today. There may have been missteps
> > (like the codeowner change) but those were done with the best intentions
> > to address this exact issue and I'm confident that hurdles can be
> > resolved (and they may already be resolved in that specific case).
> 
> There is russian proverb: "the road to hell is paved with good intentions",
> originally english "Hell is full of good meaning and wishings".
> 
> Again: There is no changes in "policy" for 5 months.
> 
> Great improvement: forbid to _maintainer_ / active developer merge his
> changes.
> 
> This is your thanks?
> 
> > This proposal was not done in isolation. It's a collaboration between
> > the three involved people (from different parts of the community) and
> > with input from Florian as well. We would like to learn what the larger
> > community thinks about it, so if you have feedback, please let us know
> > on the document or via email if you prefer that. We have a plan for how
> > to implement it but first we need to find consensus on *what* to
> > actually implement. We cannot change the past but we can improve the
> > future.
> IF you implement one change per half-year.
> IF you (will) answer to feedbacks, received on changes, after half-year of
> silence from your side.
> IF you merge pull requests after years of ignoring .
> 
> I have no comments about "project" growth then.
> > 
> 

___
collectd mailing list
collectd@verplant.org
https://mailman.verplant.org/listinfo/collectd

Re: [collectd] Collectd Release Process Proposal

[Sebastian Harl]

Hi,

On Thu, Jul 18, 2019 at 03:21:00PM +0700, Pavel wrote:
> 18.07.2019 14:20, Matthias Runge пишет:
> > Pavel, yes and no. The reason why we have this discussion here is, that
> > previous(*) most active developers are now busy with other stuff.
> 
> They found time to implement very strict checks to stop development, and
> went into the sunset.
> 
> Excellent, isn't it?
> 
> > You wouldn't see the noise here, if there wasn't any interest or if
> > there weren't companies interested both using and also having people
> > contribute to collectd. It is not the question if someone contribute,
> > but the question: how do we organize that.
> 
> You have permissions to do this on existing Github project, or you plan to
> do FORK?
> 
> As we have no any feedback from Owner, I don't think you have options to
> implement your interests or do any even minor changes in project policies.

I understand the frustration here but I'd like to remind you that many
of us are working on collectd in their "spare time" and life can get
into the way of that. That's what this proposal is intended to address.
There is no plan to fork the project but to improve how it operates so
that it scales to the community of today. There may have been missteps
(like the codeowner change) but those were done with the best intentions
to address this exact issue and I'm confident that hurdles can be
resolved (and they may already be resolved in that specific case).

This proposal was not done in isolation. It's a collaboration between
the three involved people (from different parts of the community) and
with input from Florian as well. We would like to learn what the larger
community thinks about it, so if you have feedback, please let us know
on the document or via email if you prefer that. We have a plan for how
to implement it but first we need to find consensus on *what* to
actually implement. We cannot change the past but we can improve the
future.

Cheers,
Sebastian


___
collectd mailing list
collectd@verplant.org
https://mailman.verplant.org/listinfo/collectd

Re: [collectd] Bug#819964: collectd: Collectd perl module emits perl warnings

[Sebastian Harl]

forwarded 819964 collectd@verplant.org
thanks

Hi,

On Mon, Apr 04, 2016 at 01:03:15PM +0200, Guillem Jover wrote:
> The Collectd.pm perl module emits perl warnings, which makes checking
> depending perl modules difficult to check for cleanliness:
[…]
>   ,---
>   $ perl -cw Test.pm
>   Bareword "LOG_ERR" not allowed while "strict subs" in use at 
> /usr/share/perl5/Collectd.pm line 165.
>   Bareword "TYPE_CONFIG" not allowed while "strict subs" in use at 
> /usr/share/perl5/Collectd.pm line 119.
[…]

Thanks for reporting this. Unfortunately, this is hard to fix in a
standard Perl setup. The problem is this: Collectd.pm depends on C code
provided by the collectd perl plugin. It's similar to other Perl modules
that wrap C code, except that those would load a shared object file but
the perl plugin depends on collectd's internal API provided by the core
daemon. That is, Collectd.pm would have to dynamically load the collectd
binary and the perl plugin which isn't feasible. Detangling that would
require a major refactoring of collectd.

That said, we could provide another binary, say 'collectd-perl' that
acts like a Perl interpreter. You can think of the perl plugin as a
customized Perl interpreter embedded into collectd, so that's basically
what we'd want. That shouldn't be hard to do and it would provide the
secondary benefit that you could use that to actually test functionality
as well alongside simple compilation tests (perl -c). The only drawback
is that you'd have to use collectd-perl in place of perl for your tests.

Thoughts anyone?

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ 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
https://mailman.verplant.org/listinfo/collectd

Re: [collectd] Bug#779483: collectd: Fails to install if no FQDN domain name

[Sebastian Harl]

forwarded 779483 collectd@verplant.org
thanks

Hi,

On Sun, Mar 01, 2015 at 11:05:28AM +0100, s3v wrote:
 attempting to install this package...
 
   # apt-get install collectd
[…]
   Setting up collectd (5.4.1-6) ...
   Job for collectd.service failed. See 'systemctl status
 collectd.service' and 'journalctl -xn' for details.
   invoke-rc.d: initscript collectd, action restart failed.
   dpkg: error processing package collectd (--configure):
   subprocess installed post-installation script returned error exit
 status 1
   Processing triggers for libc-bin (2.19-15) ...
   Errors were encountered while processing:
   collectd
   E: Sub-process /usr/bin/dpkg returned an error code (1)
 
   # systemctl -l status collectd.service
 
   ● collectd.service - LSB: manage the statistics collection daemon
 Loaded: loaded (/etc/init.d/collectd)
 Active: failed (Result: exit-code) since dom 2015-03-01 10:26:49
 CET; 2min 13s ago
 Process: 6119 ExecStop=/etc/init.d/collectd stop (code=exited,
 status=0/SUCCESS)
 Process: 6127 ExecStart=/etc/init.d/collectd start (code=exited,
 status=1/FAILURE)
 
 mar 01 10:26:49 s3v3land collectd[6130]: Looking up s3v3land
 failed. You have set the FQDNLookup option,
 but I cannot resolve my hostname to a fully qualified domain
 name. Please fix the network configuration.
 mar 01 10:26:49 s3v3land collectd[6127]: Starting statistics
 collection and monitoring daemon: collectd
 not starting, configuration error failed!
 mar 01 10:26:49 s3v3land systemd[1]: collectd.service: control
 process exited, code=exited status=1
 mar 01 10:26:49 s3v3land systemd[1]: Failed to start LSB: manage
 the statistics collection daemon.
 mar 01 10:26:49 s3v3land systemd[1]: Unit collectd.service
 entered failed state.
 
 The error occurs if /etc/hosts hasn't FQDN domain name:
 
 127.0.0.1   localhost
 192.168.1.3 s3v3land.FOO
 
 # The following lines are desirable for IPv6 capable hosts
 ::1 localhost ip6-localhost ip6-loopback
 ff02::1 ip6-allnodes
 ff02::2 ip6-allrouters
 
 After removing FOO from /etc/hosts file, the problem disappears
 and package installation ends fine.
 
 Can you provide some warnings regarding incorrect syntax in
 etc/hosts but, despite that, allowing a normal installation of the
 package?

Thanks for reporting this. By default, the Debian package configuration
uses 'FQDNLookup true' and I think it makes sense to abort if the lookup
fails. However, I think we can make that optional by allowing a third
value (besides true and false) like allow-fallback or something
which I could then use in the default package configuration.

With this email, I forwarded the issue to the upstream mailing list for
further comments.

Cheers,
Sebastian

-- 
Sebastian tokkee Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ 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] Bug#743881: collectd: collection.cgi don't graph apache stats

[Sebastian Harl]

tags 743881 + fixed-upstream
thanks

Hi,

On Mon, Apr 07, 2014 at 05:19:34PM -0300, Fabiano Pires wrote:
 When I tried to graph apache2 stats with collectd/collection.cgi, I got these 
 results:
 * No graph is generated for this plugin (others plugins are graphing ok).
 * Apache have mod_status enabled and configured (I can access it via brwoser 
 and wget).
 * Apache's log contains some lines like this:
   collection.cgi: RRDs::graph: No DS called 'count' in 
 '/var/lib/collectd/rrd/jb1.example.org/apache-raiz/apache_bytes.rrd' at 
 /usr/lib/cgi-bin/collection.cgi line 787
 
 After some googling, I found somewhere that the DS name in the rrd files 
 changed from 'count' to 'value'.
 So I opened collection.cgi in vim and did :960,1021s/count/value. This 
 solved the issue.

Thanks you for reporting this and providing a patch!

I've submitted your fix to the upstream repository:
https://github.com/collectd/collectd/commit/5d0a10f15f361c6f019b48d0619e87ee8bb936e3

It'll be included in the next upstream release.

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] postgresql plugin query help

[Sebastian Harl]

Hi Andrew,

On Thu, Mar 28, 2013 at 02:20:10PM -0700, Andrew Hammond wrote:
 I have a working collectd setup publishing to graphite. I have the default
 postgresql queries working against a postgres database. I want to add the
 following query. https://gist.github.com/ahammond/811b3532f229bc4ec386 It
 doesn't appear to be generating any data. The existing default queries
 continue working, and I don't get any error messages either in syslog or on
 the console when I run it there directly.
 
 I've tested the query in the database and it runs error free. I've tried
 adding a ; to the end of the Statement string and putting single-quotes (')
 around the $1 parameter. Neither of these things seem to have any effect.

Hrm, the query and collectd configuration look fine to me. It's only
going to work with Postgres 9.2, though, as older versions don't have
the 'state' field in pg_stat_activity. If that is not the case, you
should see an error in the collectd log, though.

 What are my next steps to get this working please?

Which version of collectd do you use? The only case in which you should
not see any collectd error messages is when the query does not return
any rows (which should never happen in your case). Do you see any error
messages in the PostgreSQL log? I suppose that the easiest way to
further debug the issue is to increase log verbosity in Postgres. Do you
see any messages about the query being executed?

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

Re: [collectd] Mysql plugin works very strange

[Sebastian Harl]

Hi,

On Thu, Mar 21, 2013 at 02:48:35PM +, Benjamin Wang (gendwang) wrote:
   When I setup collectd and mysql, there are 5 rrd files generated for 
 mysql_commands as following:
 mysql_commands-admin_commands.rrd
 mysql_commands-select.rrd
 mysql_commands-show_databases.rrd
 mysql_commands-show_master_status.rrd
 mysql_commands-show_status.rrd
 
 Then I reboot the machine, two strange things happen:
 
 1.  mysql_commands-show_master_status.rrd will not be updated
 
 2.  There are 3 more rrd files generated(mysql_commands-change_db.rrd, 
 mysql_commands-show_fields.rrd, mysql_commands-show_tables.rrd)

I haven't looked into MySQL in detail recently but this could be
expected. The plugin will slurp in all Com_stmt_* rows returned from
SHOW GLOBAL STATUS and submit all values that are not zero. According
to that, if there are any commands that have not been issued then the
respective data-sets will not be stored by collectd (meaning: the files
won't be created or updated).

According to the mysql plugin code, these values are counter values,
that is, I suppose they are reset whenever MySQL restarts. Thus, a value
of zero actually means the respective command has not been used at all
and, thus, I think it's fine to ignore them.

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

Re: [collectd] [5.1] Multiple mysql instances?

[Sebastian Harl]

On Tue, Mar 19, 2013 at 08:19:57PM +0100, Jacek Osiecki wrote:
 Wiadomość napisana przez Sebastian Harl w dniu 18 mar 2013, o godz. 21:29:
  On Mon, Mar 18, 2013 at 11:12:24AM +0100, Fabien Wernli wrote:
  On Mon, Mar 18, 2013 at 09:37:22AM +0100, Jacek Osiecki wrote:
  LoadPlugin mysql
  Plugin mysql
Database sqlone
User backup
Password 
Host 192.168.0.21
Database mysql
#Socket /var/lib/mysql/sc-sqlcrit/mysql.sock
/Database
  I think the 'Database' directive *in* the block overrides the name in the 
  'Database'
  *definition*. This means that in your example, `sqlone` and `sqltwo` are
  both being overridden by `mysql`, thus yielding the error message. I
  remember banging my head on a hard surface too when trying to achieve the
  same goal.
  
  This issue should have been fixed in 5.1.1. The name of the Database
  definition is now used when registering the callback. The above
  configuration is perfectly fine in that case.
 
 Does that mean, that I need to upgrade to 5.1.1 in order to have
 multiple mysql instances handled (now I have 5.1.0)?

Yes, in case all instances connect to a database of the same name. In
5.1.0 and earlier, the Database Database NAME /Database had to be
unique. Starting with 5.1.1, the name specified in Database NAME is
used for purpose of identifying an instance within the plugin / daemon.

 I'm really confused...

I surely hope we can work that out :-)

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] Fwd: [5.1] Multiple mysql instances?

[Sebastian Harl]

Hi,

On Mon, Mar 18, 2013 at 11:12:24AM +0100, Fabien Wernli wrote:
 On Mon, Mar 18, 2013 at 09:37:22AM +0100, Jacek Osiecki wrote:
  LoadPlugin mysql
  Plugin mysql
  Database sqlone
  User backup
  Password 
  Host 192.168.0.21
  Database mysql
  #Socket /var/lib/mysql/sc-sqlcrit/mysql.sock
  /Database
  Database sqltwo
  User backup2
  Password 
  Database mysql
  Host 192.168.0.22
  #Socket /var/lib/mysql/sc-sqlmain/mysql.sock
  /Database
  /Plugin
  
  I tried many combinations: using Host in first database and Socket in 
  second one, using
  different users - nothing helped. Always only the first database is handled.
  
  Am I doing something wrong, or is collectd simply unable to handle two (or 
  more) mysql servers?
 
 I think the 'Database' directive *in* the block overrides the name in the 
 'Database'
 *definition*. This means that in your example, `sqlone` and `sqltwo` are
 both being overridden by `mysql`, thus yielding the error message. I
 remember banging my head on a hard surface too when trying to achieve the
 same goal.

This issue should have been fixed in 5.1.1. The name of the Database
definition is now used when registering the callback. The above
configuration is perfectly fine in that case.

 If I were you, I'd simply drop the `Database mysql` from your
 example, and it should work as-is.

No, this will only make the plugin not connect to any specific database.
Before 5.1.1, you'd have to specify *different* database names (using
the Database option within the Database block) in order to make
this work.

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

Re: [collectd] registering UnixSock as a write plugin

[Sebastian Harl]

Hi,

On Thu, Mar 14, 2013 at 11:19:17PM -0700, Derek Wood wrote:
 We use the UnixSock plugin exclusively to retrieve data from collectd.
 Since we are not using RRD, etc, collectd hammers the syslog with the
 following message.  Is there any way to register UnixSock as a Write
 plugin or otherwise suppress these messages?
[…]
 package: collectd-4.10.1-2.1ubuntu7

This is a problem that has been fixed in 4.10.3. In older versions
there's no other way around this except for actually registering a write
callback. For example, you could come up with a dummy plugin which will
register a no-op write callback. This can be done in C, Perl, Python,
etc. (whatever 4.10 supported at that time).

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

Re: [collectd] Nagios plugins

[Sebastian Harl]

Hi,

On Wed, Feb 20, 2013 at 02:56:30PM +0100, Frédéric Pégé wrote:
 For those who're interested, I've developped a few plugins for
 Nagios/Centreon/Icinga/Shinken to check a few things from Collectd
 Load / Mem / Swap / NIC / Spase / Disk IO
 
 The advantage of that is to connect only to one server : the collectd
 central node.
 
 They are written in python using the CollectD module shipped in contrib
 (I've added a few funcs), and nagaconda.

How about submitting the new functions to collectd? Either send a patch
to this list or (preferred) open a pull request on Github.

 I've also written a few files for shinken packs, and a discovery scripts.
 It connects to the unixsocket and gets the hosts lists, and each of them
 the nic list, disk list, mount-point list, ...
 
 Anyone interested ?
 Where I can put that stuff ?

Sounds interesting. I'd go for creating a new project for that on some
project / code hosting site or making the code available through your
website (if available).

Also, I think it would make sense to add some notes about this to
https://collectd.org/wiki/index.php/Collectd-nagios in a new section
(e.g. Alternate approaches).

As a side-note: I've already had the idea of doing something similar
using Lua. The advantage of Lua would be that writing new code should
still be fairly easy for everybody but it could also fairly easy be
embedded into C programs. E.g. the mod-gearman worker comes to my mind
:-)

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] Nagios Perfdatas Collectd

[Sebastian Harl]

Hi,

On Tue, Nov 20, 2012 at 11:49:24AM +0100, Cyril Feraudet wrote:
 Is there anyone using Collectd to graph Nagios Perfdata ?

I'm not doing that so far but I just recently had the idea to write a
gearman worker plugin which may receive the perfdata send by mod-gearman
;-)

Anyway, I'm not sure if that makes sense after all. We would probably
need some kind of mapping of Nagios services to collectd instances. We
could use a generic mapping like
nagios-hostname/nagios-service-desc-label/type (i.e. similar to
PNP4Nagios with RRD_STORAGE_TYPE = MULTIPLE) and then let the user
specify a default type and a list of exceptions for that (similar to
DATATYPE in the PNP4Nagios check_commands configuration). Anything more
flexible would probably require quite some (user configuration) work.

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] New aggregator plugin basic_aggregator (#136)

[Sebastian Harl]

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))

[Sebastian Harl]

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] New aggregator plugin basic_aggregator (#136)

[Sebastian Harl]

Hi,

On Wed, Oct 10, 2012 at 11:28:05PM -0700, ymettier wrote:
 After some use of the aggregator, I noticed that when you change
 something in the configuration of the aggregator (add,remove a
 hostname, type...), you have to restart all collectd to take the
 change into account.
 
 This new commit introduce a new feature : there is a distinct
 configuration file for the aggregator and when it changes, the
 aggregator notices it and updates its configuration. No more need to
 restart anything.

Hrm, from a first glance, I don't really like this idea. The following
are a couple of random ideas / notes; maybe we can get to a better
(more generic) solution from there. Also, I've Cc'ed the mailing list.
Imho, the discussion should happen there.

Background: currently, collectd does not support reloading any
configuration at run-time. This is due mostly to the rather generic
configuration approach. Support for config reloading would probably
require modifying each single plugin.

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.

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.

This approach will allow us to introduce a global reload operation
step by step. Also, if we decide never to implement a global operation,
some plugins (like the aggregator) will still be able to benefit from
the infrastructure.

What do others think?

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


___
collectd mailing list
collectd@verplant.org
http://mailman.verplant.org/listinfo/collectd

Re: [collectd] [PATCH 2/2] Add missing return statements, unify pthread_exit usage.

[Sebastian Harl]

Hi,

On Sun, Sep 02, 2012 at 11:54:35PM +0200, Benjamin Jacobs wrote:
 - pthread_exit (NULL);
 - return NULL;
 + pthread_exit ((void *) 0);
 + return ((void *) 0);

What's the motivation for doing that (in a couple of places)?

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

[collectd] RFC: Writing data to PostgreSQL

[Sebastian Harl]

Hi there,

I'd like to announce a new feature of the postgresql plugin and I'd
like to ask for feedback, comments, flames, etc. in order to further
tune and improve it before actually releasing it.

I've implemented generic support for writing data to PostgreSQL. This is
done by letting the user specify an arbitrary SQL statement to be used
for storing a value-list in PostgreSQL. Usually, this should be done by
creating custom helper functions (using PL/SQL) for that purpose.

This approach has two benefits: for one, a user may chose whatever
database layout best suits her needs. Also, it is very easy to
experiment with different approaches on how to structure the data in a
database without the need to modify the plugin. This can be done in SQL,
which (hopefully) is the language that people working with PostgreSQL
databases like most ;-) If it happens to turn out that some approach is
rather superior, it may still be re-implemented in a specific plugin in
later versions (in case that improves performance or usability).

The code is available at Github for now:
https://github.com/tokkee/collectd/tree/sh/postgresql-writer

I've included an example database setup (table layout and partitioning
and helper functions). See contrib/postgresql/collectd_insert.sql.
However, I'd like people to think and experiment on their own ;-)

I suppose that, currently, this won't work with large amounts of data
being processed by one collectd instance. I've got a couple of random
ideas floating around on how to possibly improve that situation but I
haven't tested any of that yet, so I won't talk about it ;-) Anyway,
some feedback about how this performs or some hints on how to tune
PostgreSQL in order to let it process large amounts of write workloads
would be much appreciated. Imho, decreasing data safety a bit (like
allowing some data to be lost in case of a crash) would be perfectly
fine for this kind of setup if that bursts performance.

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] Compilation issue on Solaris 10

[Sebastian Harl]

Hi,

On Fri, Jun 01, 2012 at 02:35:08PM +0100, Maciej (Matchek) Bliziński wrote:
 2012/5/31 Florian Forster o...@collectd.org:
  utils_dns.c:476:17: error: storage size of 'ext_hdr' isn't known
 
  It looks like Solaris is missing this struct. Since all extension
  headers are being ignored, we should be able to fall back to a
  self-defined struct like this one:
 
   struct ip6_ext
   {
     uint8_t ip6e_nxt;
     uint8_t ip6e_len;
   };
 
 This one is defined in a file called ip_compat.h. I'll try to get it
 to work.

This worked for me on Solaris 11 when manually defining SOLARIS2 to a
value greater than 8 (11 in my case). Not sure if there is some way to
get that define automatically set to the right version, though.

https://github.com/collectd/collectd/commit/4b3e4116a7c512b8e5ac660850a0a2cc6979fe3c

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] no rrd files created on solaris (Bad file number)

[Sebastian Harl]

Hi,

On Tue, Mar 22, 2011 at 02:26:47PM +0100, Mathijs Möhlmann wrote:
 On Wed, Mar 16, 2011 at 10:35:07AM +0100, Mathijs Möhlmann wrote:
  I'm using collectd 4.10.2 on Solaris 10 (gcc 3.4.6). Sometimes when I
  start with a clean rrd directory or add a host the .rrd file (rrdtools
  plugin) don't get created and I get the following message:
  
  collectd[2996]: [ID 702911 daemon.error] 
  stat(/usr/local/var/lib/collectd/rrd/asterix/load/load.rrd) failed: Bad 
  file number
 
 I've created a patch thats fixed this issue for me. Is this the right fix?

Sounds good to me. I've pushed that fix to Github -- see
https://github.com/collectd/collectd/pull/109.

Having reentrancy available sounds like a good idea in general ;-)
See also: http://docs.oracle.com/cd/E19455-01/806-5257/compile-4/index.html

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] collectd5 package for Ubuntu 12.04

[Sebastian Harl]

Hi,

On Mon, Jul 23, 2012 at 01:00:49PM -0700, Kimo Rosenbaum wrote:
  Is anyone working on a collectd5 package for Ubuntu 12.04 LTS?

 Nevermind, found tokkee's package files:
 
 http://git.tokkee.org/?p=pkg-collectd.git;a=summary

You might also want to have a look at
https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1020774 and
https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/995234.

I suppose the package will be auto-synced from Debian some time.

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] Bug#680660: collectd - runs as root without apparent reason

[Sebastian Harl]

Hi,

(Cc'ing the collectd mailing list, hoping for further input and
suggestions. For a full log of this bug report, see
http://bugs.debian.org/680660.)

On Mon, Jul 16, 2012 at 03:19:37PM +0200, Bastian Blank wrote:
 On Sun, Jul 08, 2012 at 02:50:02PM +0200, Sebastian Harl wrote:
  On Sat, Jul 07, 2012 at 10:23:00PM +0200, Bastian Blank wrote:
   All the informations recorded by default are available for normal users
   or at most need CAP_DAC_READSEARCH.
 
 I thought about it and no plugin should need this permission ever. All
 this stuff should be done by group permissions.

There might be plugins requiring some such permission in order to read
information from /proc/ but I haven't double-checked that. I suppose
that would be very few exceptions, though.

  I suggest to do the following: run collectd as nobody (or a newly
  created user 'collectd') by default; make that user configurable through
  /etc/default/collectd
 
 This works with start-stop-daemon. I have one test system run this way.

Yep, that's how I was going to implement that.

make it possible to provide a list of
  capabilities (through /etc/default/collectd) that would be applied to
  the collectd binary in the init script.
 
 This does not work without code modifications. Capabilities in the
 effective and permitted set do not survive execve(2) if not set in the
 filesystem.

Well, I was going to place them in the file-system (if possible). That
would have been a first step in the right direction which would not
require modifications to collectd and would be easy to modify for
testing purposes. Not sure which filesystems support capabilities,
though.

 What collectd should do IMHO:
 - General capability support:
   - Capabilities not known safe are dropped immediately even if run by
 root. It never needs to modify network setup or mount stuff.
 Yes, this may break setups if stuff is not root-owned.
   - Plugins can specify what capabilities they need, they will be
 retained, all others dropped.

Sounds good to me.

This could be implemented by providing a new callback like
'plugin_register_capability'.

 - Support to set user:
   - The process needs to set SECBIT_KEEP_CAPS to retain capabilities
 while changing user from root.

Sounds good to me.

 - Maybe set security bit SECBIT_NOROOT. It removes capabilities from all
   suid-root processes it may try to call.

This would be in the spirit of the exec plugin which refuses to run any
external programs / scripts as root. However, I'm not entirely sure if
that's a good idea, though, as that just limits the possibilities of the
user while I don't see much security benefits.

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] NetApp plug not writing any data

[Sebastian Harl]

Hi,

On Sat, Jun 09, 2012 at 02:41:22AM +, Ulf Zimmermann wrote:
 I configured the NetApp plugin to collect some data from our Netapps
 and although all the rrd files get touched, all values stay NaN.
 NetApp are using OnTap 8 and I have tried this against 2 different
 v3140 and one FAS2020. Here is the configuration:

Which version of collectd is that? I've successfully used collectd
(version 4 iIrc) with OnTap 8 but I've got some further patches applied
which I haven't had the time yet to merge back. Do you see any errors in
collectd's log?

 Plugin netapp
 Host nacorpfrmt01.autc.com
 Protocol  http

Did you try https? I think I vaguely remember some problems when using
http but I cannot remember any details right now.

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] [PATCH] IPVS plugin not handling firewall marks

[Sebastian Harl]

On Wed, May 30, 2012 at 01:50:51PM +0100, Mark Brooks wrote:
 Hi all,
 This was detected in 5.1.0, when using the ipvs plugin to collect
 stats from ipvs with firewall marks. (I am quite new to using collectd
 so if Ive missed something please shout)
 
 The observed normal folder naming convention is -
 ipvs-virtual IP_{UDP,TCP}port
 
 which is fine until you use a firewall mark as you get
 ipvs-0.0.0.0_TCP0/
 
 Which is usable unless you have more than one firewall mark pointing
 to the same real servers, as everything ends up in the same directory.
 
 The patch detects if the Virtual IP is a firewall mark and uses that
 to form the folder name instead. So if your using a firewall mark you
 would get
 
 ipvs-firewall_mark_FWM0

Signed-off-by: Sebastian Harl s...@tokkee.org

;-)

 Mark
 -
 
 diff -pur collectd-5.1.0/src/ipvs.c collectd-5.1.0-mine/src/ipvs.c
 --- collectd-5.1.0/src/ipvs.c   2012-04-02 09:04:58.0 +0100
 +++ collectd-5.1.0-mine/src/ipvs.c  2012-05-30 13:05:58.239637001 +0100
 @@ -188,14 +188,20 @@ static int get_pi (struct ip_vs_service_
 
 if ((NULL == se) || (NULL == pi))
 return 0;
 -
 -   addr.s_addr = se-addr;
 -
 +
 +   if (se-fwmark) {
 +   len = ssnprintf (pi, size, %u_FWM%u, se-fwmark,
 +   ntohs (se-port));
 +   }
 +   else {
 +   addr.s_addr = se-addr;
 +
 +   len = ssnprintf (pi, size, %s_%s%u, inet_ntoa (addr),
 +   (se-protocol == IPPROTO_TCP) ? TCP : UDP,
 +   ntohs (se-port));
 +   }
 /* inet_ntoa() returns a pointer to a statically allocated buffer
  * I hope non-glibc systems behave the same */
 -   len = ssnprintf (pi, size, %s_%s%u, inet_ntoa (addr),
 -   (se-protocol == IPPROTO_TCP) ? TCP : UDP,
 -   ntohs (se-port));
 
 if ((0  len) || (size = len)) {
 log_err (plugin instance truncated: %s, pi);
 
 ___
 collectd mailing list
 collectd@verplant.org
 http://mailman.verplant.org/listinfo/collectd

-- 
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] Bug#637875: collectd: FTBFS with ld that defaults to --as-needed: bad Perl linkage order

[Sebastian Harl]

clone 637875 -1
reassign -1 perl
retitle -1 perl: please support splitting linker options and libraries in ldopts
forwarded 637875 collectd@verplant.org
thanks

Hi,

On Mon, Aug 15, 2011 at 12:24:16PM +0100, Colin Watson wrote:
 collectd fails to build with a linker that defaults to --as-needed, as
 explained in this Ubuntu bug report:
 
   https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/796571
 
   
 http://people.canonical.com/~lamont/jamvm/logs/collectd_4.10.1-2.1ubuntu1-armel-20110612-1102
 
   /build/collectd-SQXwoT/collectd-4.10.1/conftest.c:202: undefined reference 
 to `Perl_Gthr_key_ptr'
   /build/collectd-SQXwoT/collectd-4.10.1/conftest.c:202: undefined reference 
 to `pthread_getspecific'
   /build/collectd-SQXwoT/collectd-4.10.1/conftest.c:203: undefined reference 
 to `Perl_newSVpv'
   /build/collectd-SQXwoT/collectd-4.10.1/conftest.c:203: undefined reference 
 to `Perl_load_module_nocontext'
 
 This happens because ExtUtils::Embed ldopts returns linker options and
 libraries all mixed together, but they need to be picked apart so that
 the libraries can correctly come after C files / objects.  For a similar
 case, see:
 
   
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=f2481f3df4521e731da36afe7f0fe19a5c93e46d

I'd prefer to see ExtUtils::Embed ldopts support splitting the output
rather than parsing its output (which, in theory, might be error
prone). I'm thus cloning this bug.

Perl maintainers / developers, what do you think about providing options
like -linker and -libs in order to be able to do something like the
following:

  perl -MExtUtils::Embed -e ldopts -- -linker
  perl -MExtUtils::Embed -e ldopts -- -libs

Also, I forwarding your patch upstream. Florian, what do you think about
applying the patch upstream? I'd like to avoid having to patch the build
system in the Debian packaging.

TIA,
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] lxc plugin

[Sebastian Harl]

Hi,

On Wed, May 02, 2012 at 07:19:49PM +0100, Ben Butler-Cole wrote:
 On 2 May 2012 18:56, Sebastian Harl s...@tokkee.org wrote:
   On Wed, May 02, 2012 at 04:24:41PM +0100, Ben Butler-Cole wrote:
   I see from the mailing list archives that there was work on a collectd
   plugin for reporting on resource usage by lxc containers. Does anyone
  know
   what the status of this is? I would be interested in contributing to
   development if it's still viable.
 
  In fact, this will be solved by a cgroup plugin. As far as I could
  see, there are currently two different proposals.
 
 
 Ah, that's much better than something lxc-specific. Thank you.
 
 Is there a sensible way to get hold of a single plugin like one of these on
 its own, without having to have a custom build of the whole of collectd?

Yep. All you need is the collectd headers (and possible further
third-party libs required by the plugin). Then, download the plugin's
sources and compile it with something like (on Linux) 'gcc -shared -fPIC
-o plugin.so plugin.c'. You might need to add a few -I and possibly -l,
-L.

If you stumble across any problems, don't hesitate to post compiler
errors on this list ;-)

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

Re: [collectd] Collectd 4.10.1 Interval per plugin patch available

[Sebastian Harl]

On Wed, Apr 04, 2012 at 10:16:27AM +0200, colle...@faxm0dem.org wrote:
 On Tue, Apr 03, 2012 at 11:48:27PM +, Sebastien Cramatte wrote:
  Does it available somewhere  interval per plugin patch for Collectd 4.10.1
 
 There's the following but I guess it will only apply to the 5.x branches
 https://github.com/collectd/collectd/pull/46

Well, this *might* apply on 4.x as well as the changes are limited to
the core only.

However, this is not finished yet and meant as an RFC ;-)

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

Re: [collectd] [PATCH] collectd fails to build ipvs plugin on RHEL based systems

[Sebastian Harl]

Hi Uli,

On Sun, Jan 22, 2012 at 01:36:48PM +0100, Ulrich Habel wrote:
 I did some mock builds on CentOS 6.2 with the latest version of
 collectd and noticed that the ipvs plugin doesn't build due to not
 finding the ip_vs.h header file. The include search path for this
 plugin is /usr/include/ip_vs.h and /usr/include/net/ip_vs.h.

 I've attached a patch for configure.in and src/ipvs.c to check for
 this location, too.

Thanks for reporting this.

This was a known issue. Please see [1] for a fix which has recently been
applied by Florian. This patch also takes into account that recent Linux
kernel headers and / or default GCC flags generate warnings when using
kernel headers directly and, thus, tries to lookup ip_vs.h without using
the kernel sources first.

Cheers,
Sebastian

[1] 
https://github.com/octo/collectd/commit/d87bf146cca2c78005cf3c915cbee3cf4a985ad9

-- 
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] Bug#631167: On purge, deletes RRD databases without prompting.

[Sebastian Harl]

severity 631167 important

Hi,

sorry for not coming back on this earlier. This has bugged me for quite
a bit now and I'm not sure at all how to handle this. I've talked to a
few people about this but we could not reach any consensus so far.

On Tue, Jun 21, 2011 at 11:33:41AM +1000, Trent W. Buck wrote:
 Recently I apt-get remove collectd-core and manually installed
 collectd for its git repo.  Later, I found that /etc/collection.conf
 was still around, so I did dpkg -P collectd-core.  To my surprise, I
 found that collectd-core's postrm purge script deletes, WITHOUT ANY
 PROMPTING OR WARNING, all my rrd databases and collectd configuration.

Removing configuration files on purge is mandated by policy [1].
However, policy does not talk about anything else (besides log files
which should be removed as well) in that respect. *Imho*, purge is
meant to be remove any trace of the package in question which includes
generated data as well. Anyway, for now I'm downgrading the severity of
this bug, since there is no clear requirement for any behavior.

 This is *not cool*.  I suppose it's reasonable to clean up /var/lib
 after oneself, but collectd-core should follow the example of RDBMSs
 and ask the user (via debconf) for confirmation before doing so.

This is not handled consistently across different RDBMSs: while MySQL
prompts the user (and defaults to keep the data) PostgreSQL
unconditionally removes all databases on purge as well.

I haven't found a respective bug report against PostgreSQL but there is,
for example, #535577 [2] without a clear consensus. That bug points to a
(draft?) of a database policy [3]. The latter talks about a package
should consider databases in a spirit similar to configuration files or
log files (i.e. remove) but at the same time recommends that the
administrator is prompted with a chance to preserve the data before
doing so. However, it does not differentiate between remove and
purge.

Anyway, prompting the user in case of purging databases seems to be a
commonly accepted behavior. I currently tend to prompt the user on
purge using a debconf question of priority high but default to
remove the data. This seems like the best approach to me; taking into
account the arguments of both sides. Also, imho, that's in the spirit of
with a chance to preserve the data as mentioned above.

Does that sound reasonable to you?

I've Cc'ed the collectd mailing list, hoping for some more user
feedback.

Cheers,
Sebastian

[1] 
http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails
[2] http://bugs.debian.org/535577
[3] 
http://people.debian.org/~seanius/policy/dbapp-policy.html/ch-dbapps.html#s-installationissues

-- 
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] [Collectd] Host resolution

[Sebastian Harl]

Hi,

On Wed, Aug 10, 2011 at 12:02:52AM +0200, Mariusz Gronczewski wrote:
 2011/8/9 Jeremy MAURO jma...@antidot.net:
 new versions of wireshark have collectd protocol decoder, that + ngrep
 should find it fast :)
 
 on related topic does anyone know is it possible to filter like
 ignore values if $host in putval doesn't match reverse DNS of host
 that send it ?

That's not currently possible. That information is only available to the
'network' plugin. However, it would be possible to let the network
plugin add the remote host's IP address to all received value-lists
using the meta-data mechanism. This could then be used in a new match
plugin to check the reverse DNS with the hostname provided in the value-
list. Feel free to send patches ;-) I'll add a note to the wiki and
might take care of it *some* day ;-)

  Let me explain the reason, on my collectd server I see rrdbases for the
  hostname 'localhost' (of course it is not from my collectd server
  itself), do cd ..I have a way to know which server is the sender? How to
  I determine the trouble maker?
 
  Of course I have 500 servers and it is not possible to stop the server
  one by one :D

The stuff suggested above would make it possible to detect, log,
whatever stuff like that as well ;-)

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] VMware Guest SDK plugin for Collectd 5

[Sebastian Harl]

Hi,

On Thu, Aug 04, 2011 at 06:21:20AM -0700, Keith Chambers wrote:
 I'm not a licensing expert either.  ;-)

While I'm not an expert, I guess I have a fair understanding of the
stuff ;-)

 vmGuestLib.h is part of the 'Open Virtual Machine Tools' hosted here:  
 http://sourceforge.net/projects/open-vm-tools/
 
 This is the license displayed at the top of the vmGuestLib.h file.
 
 
     /*
  * Copyright (C) 2003-2008 VMware, Inc. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU Lesser General Public License as published
  * by the Free Software Foundation version 2.1 and no later version.
  *
  * This program is distributed in the hope that it will be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of 
 MERCHANTABILITY
  * or FITNESS FOR A PARTICULAR PURPOSE.  See the Lesser GNU General Public
  * License for more details.
  *
  * You should have received a copy of the GNU Lesser General Public 
 License
  * along with this program; if not, write to the Free Software 
 Foundation, Inc.,
  * 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA.
  *
  */
 
 
 Would it be possible to license this plugin with the standard Collectd GPL2 
 license?

Nice! As you noted yourself, this is the LGPL (2.1), which is perfectly
compatible to the GPL 2 (and 3). So there is no problem at all licensing
the plugin under the GPL.

Do you need to link the plugin against anything else but that library?
In that case, make sure that the other libs are GPL-compatible as well.
However, looking at the project website, all required stuff seems to be
available under GPL-compatible licenses (which is very surprisingly nice
imho :-)).

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] VMware Guest SDK plugin for Collectd 5

[Sebastian Harl]

Hi,

On Wed, Aug 03, 2011 at 01:23:14PM -0700, Keith Chambers wrote:
 I understand that this will not get merged in to the mainline due to
 the associated VMware licensing. 

I haven't had a look at your code yet, but I'd like to comment this:
unless the VMWare license explicitly forbids to do so, the plugin may
either be put under a BSD-like license (which permits linking with
proprietary stuff) or the GPL using the linking exception [1].

Note, though, that this is a license change, so all authors and
contributors of the plugin have to agree about it.

HTH,
Sebastian

[1] http://en.wikipedia.org/wiki/GPL_linking_exception

-- 
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] Issue With Graphite Perl Plugin

[Sebastian Harl]

Hi,

On Tue, Jul 05, 2011 at 08:56:43PM -0500, Tom Purl wrote:
 I then tried to use the collectd-graphite plugin
 (https://github.com/joemiller/collectd-graphite).

Oh, I didn't know about this plugin yet … sounds quite interesting.
Would you (or somebody else) mind adding a page to the wiki and add it
to http://collectd.org/wiki/index.php/List_of_front-ends ;-)

 It uses the perl
 plugin, so I added the following to my config file:
 
 LoadPlugin perl
 Plugin perl
 IncludeDir /usr/local/share/perl/5.10.1
 BaseName Collectd::Plugins
 LoadPlugin Graphite
 Plugin Graphite
   Buffer 256000
   Prefix servers
   Host   localhost
   Port   2003
 /Plugin
 /Plugin
 
 I know that I didn't set the Global property to true, but from what
 I understand, that's not necessary in the 5.0 version of collectd.

collectd 5.0 automatically sets that flag for some plugins (those, that
are known to benefit from that). So, the flag is required (when using
plugins that are [in parts] written in C) but it does not have to be set
explicitly.

 Then, when I try to start collectd, I get the following errors:
 
 [2011-07-05 20:42:31] plugin_load_file: The global flag is not
 supported, libtool 2 is required for this.

This is a result of automatically adding the global flag for the perl
plugin (NB: we should check for libtool 2 as well, when automatically
setting that flag). I suggest to recompile collectd with libtool 2
(which is available since Ubuntu Lucid) even though that might not be
necessary in your case … but better be sure and safe for the future ;-)

 [2011-07-05 20:42:31] perl: Initializing Perl interpreter...
 Can't locate Collectd.pm in @INC (@INC contains:
 /usr/local/share/perl/5.10.1 /etc/perl /usr/local/lib/perl/5.10.1
 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5
 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .).
 BEGIN failed--compilation aborted.

 Here's the contents of my /usr/local/share/perl/5.10.1 directory:
 
 ./Collectd
 ./Collectd/Plugins
 ./Collectd/Plugins/Graphite.pm
 
 These files should be readable by the collectd daemon because it is
 running as root.
 
 So it appears to me that collectd can't find Collectd.pm in
 /usr/local/share/perl/5.10.1, but that should be ok since a Collectd
 folder is in there, right?

Nope, you need Collectd.pm as well … that's part of the perl plugin
(implemented in plain Perl). It should have been installed during 'make
install' as well. The default is ${prefix}/share/perl/perl_version/
(${prefix} defaults to /opt/collectd/). Either copy Collectd.pm to any
of the directories in @INC (see above) or add the path to Collectd.pm to
the IncludeDir config option.

 Does anyone have any idea what I'm doing wrong? Is this an issue with
 the perl plugin, or should I contact the author of the
 collectd-graphite plugin?

Making Collectd.pm available to the perl plugin should fix your problem.
As a second step, I recommend to recompile with libtool2 -- else, some
third-party perl modules cannot be used with the perl plugin.

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

Re: [collectd] Issue With Graphite Perl Plugin

[Sebastian Harl]

Hi again,

On Wed, Jul 06, 2011 at 07:22:17AM -0500, Tom Purl wrote:
 On 7/6/11, Sebastian Harl s...@tokkee.org wrote:
  Oh, I didn't know about this plugin yet … sounds quite interesting.
  Would you (or somebody else) mind adding a page to the wiki and add it
  to http://collectd.org/wiki/index.php/List_of_front-ends ;-)
 
 I'll be happy to once I get it up-and-running :)

Great :-)

Some screenshots would be nice as well, btw. ;-)

  Then, when I try to start collectd, I get the following errors:
 
  [2011-07-05 20:42:31] plugin_load_file: The global flag is not
  supported, libtool 2 is required for this.
 
  This is a result of automatically adding the global flag for the perl
  plugin (NB: we should check for libtool 2 as well, when automatically
  setting that flag). I suggest to recompile collectd with libtool 2
  (which is available since Ubuntu Lucid) even though that might not be
  necessary in your case … but better be sure and safe for the future ;-)
 
 How do I explicitly enable libtool 2 when I compile? Here's the
 version of that libtool that I have on the system now (and when I
 compiled 5.0):
 
 tom@millhouse:/opt/collectd/sbin$ sudo dpkg -l |grep libtool
 ii  libtool  2.2.6b-2ubuntu1
   Generic library support script
 
 I don't see an explicit libtool option for the configure script. Is
 there something I'm missing?

Sorry, I forgot to mention that you need libltdl as well. libtool is the
command line program used at build time while that lib is used by
collectd. In Ubuntu, the required package should be libltdl-dev.

  So it appears to me that collectd can't find Collectd.pm in
  /usr/local/share/perl/5.10.1, but that should be ok since a Collectd
  folder is in there, right?
 
  Nope, you need Collectd.pm as well … that's part of the perl plugin
  (implemented in plain Perl). It should have been installed during 'make
  install' as well. The default is ${prefix}/share/perl/perl_version/
  (${prefix} defaults to /opt/collectd/). Either copy Collectd.pm to any
  of the directories in @INC (see above) or add the path to Collectd.pm to
  the IncludeDir config option.
 
 Thanks! I set my IncludeDir value to /opt/collectd/share/perl/5.10.1
 and restarted, so I'm not getting that error any more. Unfortunately,
 I'm now getting this error:
 
 Can't load '/usr/lib/perl/5.10/auto/threads/threads.so' for module
 threads: /usr/lib/perl/5.10/auto/threads/threads.so: undefined symbol:
 PL_no_mem at /usr/lib/perl/5.10/XSLoader.pm line 70.
  at /usr/lib/perl/5.10/threads.pm line 32
[…]
 I found a few posts that said I should run this before I start collectd:
 
 export LD_PRELOAD=/usr/lib/libperl.so.5.10.1
 
 However, this didn't seem to help.

Hrm, that should still work … anyway, I don't currently have time to see
why that could fail.

 Am I getting this because of the missing libtool dependency?

Right.

 Also, why do you suppose it's looking for
 a Perl 5.10 plugin if I'm using 5.10.1?

The 5.10 directory is a symlink to the latest Perl version, i.e.
5.10.1 in your case.

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

Re: [collectd] plugin_dispatch_values: errors in syslog

[Sebastian Harl]

Hi,

On Mon, Jun 27, 2011 at 06:18:13PM +0200, glide creme wrote:
 Hi I'm getting errors in my syslog after installing collectd on a
 ubuntu machine using the repos.
 
 I've installed version 4.6.3-1
 
 My /var/log/syslog is full of messages like
 
 Jun 27 08:02:01 SERVER collectd[1142]: plugin_dispatch_values: Dataset
 not found: swap_io
 Jun 27 08:02:11 SERVER collectd[1142]: plugin_dispatch_values: Dataset
 not found: fork_rate

Do you have clients running newer versions of collectd and sending
values to that server? In that case, you should copy an up-to-date
types.db (see types.db(5) for details) on the server.

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

Re: [collectd] apache plugin issue w/collectd 4.8 spokes, collectd 5.0 hub

[Sebastian Harl]

Hi,

On Fri, Jun 24, 2011 at 02:15:53PM +1000, Trent W. Buck wrote:
 If I have a collectd 5.0 hub receiving data from collectd 4.8
 spokes, should that Just Work?

Yes, but you'll have to enable that. Some data-sets have changed in 5.0
(that's one of the reasons it has been declared a new major release): in
the PreCache chain, you need to enable the v5upgrade target. It'll
take care of translating v4 data-sets to v5 data-sets.

 I ask because while most plugins are getting through OK (e.g. process,
 df, etc), there is no evidence of the apache plugin sending any data
 to the hub, nor am I seeing any errors in syslog from either host.

The data types the apache plugin uses, have changed a bit, so this could
be the problem.

 It makes me wonder if the apache plugin has changed substantially,
 where the other plugins haven't, and this is the problem?  Or maybe it
 is because my hub collectd was compiled on a host without apache, so
 didn't get something compiled into e.g. its types.db...

The types.db is a static file, it does not depend on any compile time
settings.

You can find more information about migration from v4 to v5 (and having
both versions in your environment working together) in the wiki:
http://collectd.org/wiki/index.php/V4_to_v5_migration_guide

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

Re: [collectd] Collectd bind plugin patch: timesaving problem

[Sebastian Harl]

Hi,

On Fri, Jun 24, 2011 at 12:28:22PM +0200, Bruno Prémont wrote:
 On Fri, 24 Jun 2011 12:10:41 Aurelien ROUGEMONT wrote:
  I'm working for a registrar. We use intensively isc-bind, and since a
  few month collectd's bind plugin.
  
  We were experiencing a very specific behavior from this plugin only. The
  datetime returned was shifted. After some diggin', i figured what was
  the problem : the current code was not handling timesavings.
  
  the bind plugin works like this :
   * query to xmlrpc bind webservice
   * process data : bind statistics and datetime
   * returns processed data
  
  Since it's the only plugin returning a datetime not using timesavings i
  read [1] and wrote a quick fix that :
  
  1- substracts the constant timezone to the about to be returned datetime
  2- adds to the result timezone and timesaving ( with *localtime() )
  3- returns the result instead of the UTC datetime + timezone

  [1]  http://www.gnu.org/s/hello/manual/libc/Time-Zone-Functions.html
 
 The more simple/safe solution should be to revert timegm() - mktime()
 change done in
 http://git.verplant.org/?p=collectd.git;a=commitdiff;h=1641c82ec4e14968ea31021dfb8b520df5f4483a

timegm() is a GNU extension, thus, using it should be avoided. So, imho,
the approach taken in the patch is fine.

 In your patch you refer to a timezone variable, where does that one
 come from?

It's defined in 'time.h' -- it's defined as a mandatory XSI extension of
POSIX.

 In addition, localtime() and friends depend on process-global timezone
 setting which is rather bad in a multithreaded process such as collectd!

Hrm … do you really consider that to be an issue? Imho, having the
timezone a process-global setting is fine even in a multi-threaded
process. I'd rather consider code buggy that touches that setting ;-)

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] collection4 FastCGI vs. HTTP [was: collection4 nitpicking]

[Sebastian Harl]

Hi,

On Wed, Jun 22, 2011 at 05:13:13PM +1000, Trent W. Buck wrote:
 Sebastian Harl wrote:
  Secondly, why is FastCGI being used?  My life would be easier if
  collection4 was an app server, i.e. it was a permanently-running
  daemon that spoke HTTP to the real web server, being a reverse
  proxy like varnish, nginx or apache mod_proxy.
 
  I suppose, FastCGI has been used as that was (or seemed to be ;-))
  easier than implementing a stand-alone app server talking HTTP.
 
 A slight acquaintance suggested this can be achieved with libevent:
 
 17:05 SpamapS twb: In that case, libevent FTW
 17:06 SpamapS full http server code built in.. :)
 17:06 twb I've only ever seen libevent used in rxvt
 17:07 SpamapS twb: recent versions of libevent have evhttp.h ...
 17:07 SpamapS http://monkey.org/~provos/libevent/doxygen-1.4.3/
 17:07 SpamapS twb: you just register a callback per URI, and a default 
 callback for dynamic URI's
 17:09 SpamapS I played around with it a few months ago.. VERY easy to write 
 an HTTP server

Sounds interesting … libevent should have a good enough userbase to
provide decent stability ;-)

 My C-fu is pretty darn weak, so if someone else wants to take point on
 this, they're more than welcome.  Otherwise I'll try to look into it
 this week, but most likely I will completely forget about it.

It should be fairly easy to implement the FastCGI / standalone app
supports side-by-side. Implementing a replacement for src/main.c might
do the magic. Imho, that approach should be taken, if possible, to allow
users to chose which mode to use.

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] On $Interval differences between hosts

[Sebastian Harl]

Hi,

On Wed, Jun 22, 2011 at 02:07:29PM +1000, Trent W. Buck wrote:
 Suppose I have centralized monitoring (i.e. hub-and-spoke), similar to
 centralized syslogging.  On the central host (accepts UDP and writes
 RRD), I have
 
 Interval 60
 
 On the nodes (collectd data and write to UDP), I have
 
 Interval 10
 
 Is a given RRD file updated every ten seconds, or every minute?

All RRD files are updated in the right interval. I.e., RRDs containing
data from some node are updated using a ten seconds interval and those
belonging to the central server are updated using a 60 seconds interval.

Each plugin knows the interval with which it's queried and passes that
information along when dispatching data to collectd. This information is
also transferred over the network and, thus, available on the server as
well.

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

Re: [collectd] Wish for tcpconns ListeningPorts privileged

[Sebastian Harl]

Hi again ;-)

On Wed, Jun 22, 2011 at 04:58:24PM +1000, Trent W. Buck wrote:
 I'm using tcpconns to look at e.g. the number of open SSH and HTTP
 connections.
 
 It's really useful that it auto-detects which ports are in use, rather
 than me having to list them.  It means if a new service is added to a
 machine (especially a customer machine which I monitor, but don't
 directly control), collectd will automatically pick up on it.
 
 Unfortunately, my users are in the habit of also running ssh -L and -X
 and NFS, and these basically get random ports, which leads to an
 explosion of annoying extra graphs.
 
 It would be nice if I could set ListeningPorts to privileged, which
 would make it work as true for ports 1024 and below, and like
 false for ports 1025 and above.

Ack! Something like that would be a useful feature. However, I would go
for adding an option PortRange min max, as that would be more
flexible (and could possible be used several times to specify multiple
ranges).

Would you mind adding a note to the [roadmap] in the wiki?

[roadmap] http://collectd.org/wiki/index.php/Roadmap

 In the meantime I haven't thought of a workaround, but I was thinking
 I could possibly just have a hourly cron job that does something like
 
 rm -rf /var/lib/collectd/rrd/*/tcpconns-[^1]???*-local
 
 Or maybe I'll just turn tcpconns off and use stuff like curl-json to
 test the availability of services from the client side...

You could use the filter-chain mechanism (see [filter-conf], [chains])
to filter out those values by using a regex similar to the one you
specified above to remove the files.

This also brought up the idea to add support for numeric comparison
operators to the [regex-match] ;-)

[filter-conf] 
http://collectd.org/documentation/manpages/collectd.conf.5.shtml#filter_configuration
[chains] http://collectd.org/wiki/index.php/Chains

[regex-match] http://collectd.org/wiki/index.php/Match:RegEx

HTH,
Sebastian

PS: Thanks a lot for your verbose feedback! Very much appreciated :-)

-- 
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] collection4 FastCGI vs. HTTP

[Sebastian Harl]

Hi,

On Wed, Jun 22, 2011 at 05:57:31PM +1000, Trent W. Buck wrote:
 Sebastian Harl wrote:
  Sounds interesting … libevent should have a good enough userbase
  to provide decent stability ;-)
 
 PS: I remembered urxvt used it, but I couldn't see a dependency on
 libevent in Debian.  So I asked, and apparently the urxvt guy makes a
 better drop-in replacement (libev).

libev does not provide any http functionality, though. Supposedly, it is
possible to use the libevent HTTP code and link that against (the
libevent compat layer of) libev.

The libev guys claim it is “loosely modelled after libevent, but without
its limitations and bugs.” I haven't found any comparison of the two
libs (besides a benchmark), so I'm not sure what limitations and bugs
they are talking about.

  It should be fairly easy to implement the FastCGI / standalone app
  supports side-by-side.
 
 You are thinking a bunch of #ifdef's and an compile-time option
 between the two?  Or make it a runtime choice?

I'd use two main files, each one providing a main() function and
taking care of the specific request handling and main loop stuff.

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] On $Interval differences between hosts

[Sebastian Harl]

Hi,

On Wed, Jun 22, 2011 at 06:01:10PM +1000, Trent W. Buck wrote:
 Sebastian Harl wrote:
  On Wed, Jun 22, 2011 at 02:07:29PM +1000, Trent W. Buck wrote:
   Suppose I have centralized monitoring (i.e. hub-and-spoke), similar to
   centralized syslogging.  On the central host (accepts UDP and writes
   RRD), I have
   
   Interval 60
   
   On the nodes (collectd data and write to UDP), I have
   
   Interval 10
   
   Is a given RRD file updated every ten seconds, or every minute?
  
  All RRD files are updated in the right interval. I.e., RRDs containing
  data from some node are updated using a ten seconds interval and those
  belonging to the central server are updated using a 60 seconds interval.
 
  Each plugin knows the interval with which it's queried and passes that
  information along when dispatching data to collectd. This information is
  also transferred over the network and, thus, available on the server as
  well.
 
 OK, that makes sense.  So a follow-on question: if I define thresholds
 in the central hub collectd, do all thresholds apply/check every sixty
 seconds, or do they do the right thing?

Thresholds are checked whenever a value is dispatched to the daemon,
i.e. that's done live and depending on the specific interval of some
data-set (i.e., the right thing ;-)).

 If I happened to have it the other way around (leaves update each
 minute, hub updates even ten seconds), I can imagine the thresholds
 all freaking out (when $Important is set) because they haven't seen an
 update for five intervals (50s)...

The timeout used to check for missing values depends on the interval of
the data-sets as well (see the Timeout config option in
collectd.conf).

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] collection4 nitpicking

[Sebastian Harl]

Hi,

On Tue, Jun 21, 2011 at 12:13:06PM +1000, Trent W. Buck wrote:
 I notice that /etc/collection.conf starts with CacheFile
 /tmp/collection4.json, which immediately sets off my spidey security
 senses[0].  Would it be better to a different default, such as
 /var/cache/collection/collection.json?

Full ack! Imho, /var/cache/collection4 (or possibly
/var/run/collection4) would be an appropriate place for that file.

 Secondly, why is FastCGI being used?  My life would be easier if
 collection4 was an app server, i.e. it was a permanently-running
 daemon that spoke HTTP to the real web server, being a reverse proxy
 like varnish, nginx or apache mod_proxy.

I suppose, FastCGI has been used as that was (or seemed to be ;-))
easier than implementing a stand-alone app server talking HTTP.

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] Graphing rrd output of CPU plugin

[Sebastian Harl]

Hi,

On Sun, Apr 17, 2011 at 03:49:41PM -0400, lanas wrote:
   Are there examples around for quickly graphing the out put of some
 plugin modules (such as CPU) without having to use a web server (as
 shown in first steps).  Simply producing a (some) graphic
 file(s) from the files in cpu-0 directory for instance, to get a feel
 about how it works and how collectd resulting data is worked with
 rddtool. 

For quickly looking at locally collected data, you have give kcollectd
[1] a try. It does not produce the same look and feel as the graphs
created by RRDtool and it currently uses /var/lib/collectd/rrd/ as a
hard-coded path to the RRDs but it's a simple tool to get a quick glance
at your data.

HTH,
Sebastian

[1] http://collectd.org/wiki/index.php/Kcollectd

-- 
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] update to the Monitorus.pm plugin

[Sebastian Harl]

On Tue, Mar 29, 2011 at 04:29:41PM -0400, Jeffrey B. Green wrote:
 Attached is a diff/patch of changes made to make the Monitorus plugin
 work with the new system at mon.itor.us. I trimmed unused code (for the
 most part).

That looks like the new plugin won't work with older versions of
mon.itor.us any more. Is that right? Is it possible to detect with
version of mon.itor.us is used and support both versions? Imho that
would be preferred.

TIA,
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] Per-plugin interval (was: New major version 5.0.0 available.)

[Sebastian Harl]

Hi Darren,

On Tue, Mar 29, 2011 at 11:55:05AM +0100, Darren Worrall wrote:
 Can I ask how the roadmap looks from here? Are there any specific
 plans for per-plugin intervals (I seem to remember version 5 being a
 target for this, as it may have involved a backwards incompatible
 change).

There are plans for that and they do not include any backward
incompatibilities. It's rather a matter of more or less stupid
implementation work to which nobody stepped up yet ;-)

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] [Bug 734179] [NEW] collectd runs as root unnecessarily

[Sebastian Harl]

Source: collectd
Version: 4.10.1-2.1
Severity: wishlist

Hi,

(With this E-mail, I'm also submitting this as wishlist bug report to
the Debian BTS and I'm going to fix it in my next upload. So, Ubuntu
should get that as well on the next sync after that.)

On Sun, Mar 13, 2011 at 07:04:39AM -, Andrew Yates wrote:
 The collectd init script runs collectd as root and does not provide a
 way to change the user in /etc/default/collectd. Many of collectd's
 plugins do not require root permissions, so USER and GROUP options
 should be included in the init script and default file.(It might
 also be a good idea to run collectd as an unprivileged user by default.
 A quick test suggests that of the default plugins only 'df' may require
 root privileges.)

Fully agreed.

Also, I was thinking about (re)introducing a possibility to start
several instances of collectd with different configurations from one
init script, i.e. having the init script start one instance for each
configuration file found in some subdirectory. I'm not yet sure, how to
handle that properly. I guess, adding an option to /e/d/collectd to
specify that directory (empty by default) and then ignoring any other
files (including /e/collectd/collectd.conf) is the way to go.

Any comments, suggestions, questions about 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] Version 5.0.0.beta0 available

[Sebastian Harl]

Hi,

On Tue, Dec 07, 2010 at 09:52:52AM -0800, Thorsten von Eicken wrote:
[version 5.0.0.beta0 available]
 Congrats! Can you provide a summary about the 4-5 compatibility and
 migration? What is compatible with what? It gets a bit tricky when
 considering that you changed a lot of the details how plugins report
 data (e.g. to 'value' and derive instead of counter), that affects all
 front-ends that display data.

For a, probably incomplete, list of changes see [1]. Also, see [2] for a
more detailed list of changes/improvements introduced in version 5.

HTH,
Sebastian

[1] http://collectd.org/wiki/index.php/V4_to_v5_migration_guide
[2] http://collectd.org/wiki/index.php/Version_5.0/Plans

-- 
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] Thresholds help.

[Sebastian Harl]

Hi Scott,

On Thu, Sep 02, 2010 at 05:58:40PM -0700, Scott M. Likens wrote:
 Wanting to collect and alert based on the queue size in exim, so I
 setup a plugin that calls this,
 
 echo PUTVAL `hostname -f`/exim/queue_count N:`/usr/sbin/exim -bpc`
 
 I added queue_count to types.db which maybe bad, but I copied 'counter'...

Not bad by itself (that's basically the way it's intended), but some
short hints:

 * Instead of modifying an existing types.db, I'd add an additional
   custom types.db and use the TypesDB config option in collectd.conf
   to tell collectd to use both. That'll make updates easier.

 * You could as well have used counter. Adding a new type which is an
   exact copy of an existing type does not make any difference to
   collectd -- that's for the user's convenience only ;-)

 I have an existing Threshold setup working with cpu/etc, so I just
 wanted to drop this into the Threshold block like, 
 
   Plugin Threshold
 Plugin exec
 Type queue_count
   WarningMin 0.00
   WarningMax 10.0
   FailureMin 0.00
   FailureMax 20.0
   DataSource value
 /Type
   /Plugin
 /Threshold
 Plugin exec
   Exec nobody /etc/exim/collectd_mailq.sh
 /Plugin
 
 What am I missing here? I would love to know as I have a graph that
 has stats... it counts beautifully... but I don't have Thresholds
 working :(

collectd identifies a plugin by the identifier assigned to a dataset. In
case of the exec plugin's PUTVAL command, this is the first option
passed to PUTVAL. So, in your case (identifier = FQDN/exim/
queue_count), the plugin is called exim. The name of the plugin which
actually dispatches the value (i.e. the name of the shared object) does
not matter to collectd at all. While this might sound a bit confusing,
this is (imho) the only reasonable way to handle this -- else, e.g., all
values received and submitted by the network plugin would be assigned to
the network plugin. See the collectd-exec(5) manpage for more details
about the identifier.

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

Re: [collectd] collectd-4.9.1 and perl OpenVZ plugin

[Sebastian Harl]

Hi Sergey,

On Wed, Sep 01, 2010 at 04:22:17PM +0400, Sergey wrote:
 I try to use perl OpenVZ plugin, but collectd is not started:
 
 Sep  1 13:02:47 collectd[31662]: perl: Initializing Perl interpreter...
 Sep  1 13:02:47 collectdmon[31661]: Warning: collectd terminated with exit 
 status 2
 Sep  1 13:02:47 collectdmon[31661]: Warning: restarting collectd

Does collectd start, if the OpenVZ plugin is not used (i.e., no
LoadPlugin in the perl configuration)? What happens if you disable
the perl plugin altogether? Do you get any other messages on the
terminal when starting collectd? What about when starting collectd in
the foreground (using 'collectd -f' + any other options)? Where did you
get collectd from (did you compile it yourself or did you install
pre-compiled packages)?

Unfortunately, the above error messages do not tell much about what's
going on :-/

 config:
 
 Plugin perl
 BaseName Collectd::Plugin
 LoadPlugin OpenVZ
 /Plugin
 
 I can see error collectd[941]: perl: init_pi: Unable to bootstrap Collectd:
 Can't locate Devel/OpenVZ.pm in @INC when I added 'EnableDebugger OpenVZ'.
 Why is Devel used ?

The option passed to 'EnableDebugger' specifies a debugging module to be
loaded (i.e., *not* a plugin to be debugged). Perl expects/requires
those plugins in the Devel namespace -- see the documentation for
perl's '-d' command line option (in perlrun(1)) for more details. So,
this is unrelated to the initial problem your facing.

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

Re: [collectd] Can't locate Collectd/Unixsock.pm in @INC

[Sebastian Harl]

Hi there,

On Tue, Aug 31, 2010 at 10:39:21AM +0800, Salimane Adjao Moustapha wrote:
 collection3/bin/index.cgi seems to be working now but there is no data in
 the graphs images.

Does collection3 display any graphs and those graphs are empty or are
there no graphs at all? In the former case, what exactly do you mean by
no data in the graph images? Is there an x- and y-axis but no other
plotted data or is it an empty (white, whatever) image?

 i've installled collectd and rrd-tool through yum
 i have modifies /etc/collectd.conf to enable the plugins i want.
 i've set collection3 etc/collection.conf DataDir

There could be a couple possible issues. It's easier to tell, once I get
the information requested above. Anyway, for now: Do you have caching
enabled in the rrdtool plugin (if in doubt, please provide you
collectd.conf)? Are there any error messages in your webserver's logs?

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

Re: [collectd] Can't locate Collectd/Unixsock.pm in @INC

[Sebastian Harl]

Hi,

On Wed, Aug 25, 2010 at 03:27:33PM +0800, Salimane Adjao Moustapha wrote:
 I've now resolved all the perl modules errors. I could access now the page
 but the data selector page in empty. the select boxes are empty. I have
 enables some plugins and restarted collectd. Any ideas what's wrong there ?

collection3 expects a config-file (by default in collection3/etc/).
Please verify that this is available and that 'DataDir' is uncommented
and pointing to the data directory of the rrdtool plugin.

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

Re: [collectd] Strange issue with exec and unixsock plugin

[Sebastian Harl]

On Mon, Aug 23, 2010 at 02:50:33PM +0200, XANi wrote:
 Dnia 2010-08-23, pon o godzinie 13:42 +0200, Sebastian Harl pisze:
  On Mon, Aug 23, 2010 at 01:34:08PM +0200, XANi wrote:
   Dnia 2010-08-23, pon o godzinie 13:11 +0200, Sebastian Harl pisze:
On Mon, Aug 23, 2010 at 04:02:57AM +0200, XANi wrote:
 So after running something like:  
 while sleep 30 ; do /etc/init.d/collectd restart; done
 after some time (sometimes few minutes sometimes an hour or more) i 
 get
 tons of collectd processes lying around (ive added output of ps aux as
 attachment) and sometimes after restart.
[…]
 It seems to trigger when both exec and unixsock plugins are on, if i
 turn off one of them it works fine. Ah and im using 64 bit debian
 testing.

Uhm, strange. Could you please check (e.g. using strace -p pid) what
those collectd processes are doing? What's the parent of those processes
(PPID in ps ax -l or use something like ps axjf)? Are you able to
kill those processes using signal SIGINT or SIGTERM?
  
   Ok so:
   --
   # ps ax |grep col
   4792 ?SLsl   0:00 /usr/sbin/collectd
   -C /etc/collectd/collectd.conf -P /var/run/collectd.pid
   4800 ?S  0:00 /usr/sbin/collectd
   -C /etc/collectd/collectd.conf -P /var/run/collectd.pid
   --
   as attachment result of strace -t -ff -o /tmp/4792 -p 4792 and
   strace -t -ff -o /tmp/4800 -p 4800
   
   parent of PID 4800 is 4792
   4792 reacts on sigterm, 4800 both SIGTERM and SIGQUIT doesn't work, only
   SIGKILL
  
   4800.4800:
   13:25:33 futex(0x7fe9098f7550, FUTEX_WAIT_PRIVATE, 2, NULL unfinished 
   ...
  
  Thanks. Looks like some kind of deadlock :-/ I'll look into that.
 
 If u want i can give u access to VM with that bug already trigerred
 and root access so u can install debug tools, just send me ur ssh pubkey

Thanks. I'll have a look at the code first but I might come back to that
offer after that ;-) Not quite sure when I'll have some time for that
though. Possibly some time this week.

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] Strange issue with exec and unixsock plugin

[Sebastian Harl]

Hi,

On Mon, Aug 23, 2010 at 03:24:40PM +0200, XANi wrote:
[exec plugin child processes hang in call to futex()]
 Also i noticed that locked process is running as user ive told exec
 plugin to run script as so
 Exec postfix /usr/local/bin/a.pl
 results in:
 template:~# ps aux |grep coll|grep -v grep
 root  2469  0.0  0.2 162764  1436 ?SLsl 15:22
 0:00 /usr/sbin/collectd -C /etc/collectd/collectd.conf
 -P /var/run/collectd.pid
 postfix   2476  0.0  0.2 101408  1168 ?S   15:22
 0:00 /usr/sbin/collectd -C /etc/collectd/collectd.conf
 -P /var/run/collectd.pid

Ah, nice! That's an interesting detail that might help debugging quite a
bit.

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

[collectd] Fwd: [Thank you] Thanks for collectd.

[Sebastian Harl]

Hi everybody,

as some of you might have heard, Debian turned 17 yesterday. Some nice
people used that opportunity to set up a Thank you service [1] thru
which I received the message appended to this E-mail. Since collectd, as
it is today, would not be possible without hundreds of contributions and
feedback from users, I'd like to forward and share this with all of you.

- Forwarded message from Johann joh...@phyfus.com -

From: Johann joh...@phyfus.com
To: Sebastian Harl (collectd) colle...@packages.debian.org
Date: Mon, 16 Aug 2010 20:42:25 -0400 (EDT)
Subject: [Thank you] Thanks for collectd.

I use collectd on a bunch of Ubuntu Servers your uploads to Debian test
keep my systems running.Thanks.

--
This is message was sent to you from http://thanks.debian.net

- End forwarded message -

[1] http://thanks.debian.net

-- 
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] [PATCH 1/2] Add collectd-flush command line utility.

[Sebastian Harl]

Hi again :-)

On Mon, Aug 09, 2010 at 12:17:50AM +0200, Sebastian Harl wrote:
 Some possible TODOs:
 
  * Add support for PUTVAL and PUTNOTIF. The latter would have to be
added to libcollectclient first. The former is a bit hard to
implement since lcc_putval() expects the data-type to be passed along
with the data-set. Not sure yet, how to properly solve that.

I've added support for PUTVAL in sh/next now. I'm using the following
(a bit) dirty trick to tell apart gauge or counter values (derive
and absolute are handled exactly the same by lcc, so there's no point
in handling them differently in the client): any value containing a dot
is considered a gauge value, while everything else is a counter.
Since lcc uses that information for formatting the values only, this is
a feasible approach imho. Another possible approach that came to my mind
would be to introduce a new data-type (in lcc) called something like
automatic_t which would be passed to lcc as a string and then passed
along to the daemon without further touching it. Personally, I like that
approach a bit better (after all, it's the daemon's job to handle types
and, in theory, it might use different type definitions anyway) but it's
more intrusive, so, I've used the other approach for now. Florian, if
you have any preferences on that, please tell me and I'll change the
code ;-)

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] [PATCH 1/2] Add collectd-flush command line utility.

[Sebastian Harl]

Hi Håkon,

On Fri, Aug 06, 2010 at 01:22:53PM +0200, Florian Forster wrote:
 On Thu, Aug 05, 2010 at 04:37:45PM +0200, hakon-dugstad.john...@telenor.com 
 wrote:
  collectd-flush is a small command-line utility which uses
  libcollectdclient to flush collectd through the unixsock plugin.
[…]
  I am no C wizard, so please bear with me if I have done something a
  stupid way. :)
 
 Your code looks fine to me :) I've found one missing break, but that's
 it. I'm a bit concerned about using getopt_long, since - to the best
 of my knowledge - that's a GNU extension and not portable. Unless I'm
 mistaken I will probably remove the long option names and go back to
 getopt.

Yes, that's a GNU extension.

I've removed the long options and done a bit of more hacking on that
tool and turned it into a more powerful frontend to libcollectdclient.
The tool is now called ‘collectdctl’ (collectd control interface). You
can find the code in my ‘sh/next’ branch in my Git repo [1].

The calling syntax now looks similar to the text-based protocol used by
the ‘unixsock’ plugin itself, i.e.:

  collectdctl command [command options]

E.g.:

  collectdctl -s /path/to/unixsock flush host/foo/bar

or

  collectdctl listval

Some possible TODOs:

 * Add support for PUTVAL and PUTNOTIF. The latter would have to be
   added to libcollectclient first. The former is a bit hard to
   implement since lcc_putval() expects the data-type to be passed along
   with the data-set. Not sure yet, how to properly solve that.

 * Add an interactive mode (similar to a shell) and support reading
   multiple commands from a file (script). This will require properly
   parsing input lines. This is already done in utils_cmd_* and the
   appropriate code should probably be factored out for that.

 * More testing ;-)

Any feedback, suggestions, etc. would be very appreciated.

Cheers,
Sebastian

[1] git://git.tokkee.org/collectd.git

-- 
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] Bug#590656: collectd: apache traffic cut off at 1 GBit/sec

[Sebastian Harl]

Hi,

On Wed, Jul 28, 2010 at 08:47:59AM +0200, Carsten Otto wrote:
 When apache (httpd) does more than 1 GBit/sec of traffic, the RRD file
 does not contain these values. I assume there is some maximum defined at
 1 GBit/sec and/or some overflow occurs. My server does 1,5 GBit/sec in
 average, so the graph currently is useless to me.

Right, the maximum value for the apache_bytes type is set to 1 GiBit
(per second). RRDtool will consider any higher values as invalid and
store UNKNOWN instead. I'm not sure what amount of traffic Apache is
(currently) able to handle but with 10 GiBit connections becoming
increasingly common, I think this limit should be raised to at least
that value.

Also, other data types could possibly be affected in a similar way.
The reason for setting max. values in the first place is to avoid huge
peaks in case of a counter reset (e.g., after restarting some service).
In the future (collectd 5), this will probably be handled by using the
DERIVE data type rather than COUNTER in the RRD files. In the
meantime, I think we should raise the limits.

Florian, do you agree with this?

As a work-around for now, you can do the following:

 * Change the max. value defined in /usr/share/collectd/types.db (see
   the types.db(5) manpage for details) -- this will make sure RRD files
   created in the future will have the right max. value.

   However, note that this file will be overwritten on the next upgrade.
   So, a somewhat better approach would be to create a new, custom
   types.db file (e.g. /etc/collectd/types.db.local) and add a custom
   definition for apache_bytes which will then overwrite the default.
   Then, add the following line to your collectd.conf:

 TypesDB /usr/share/collectd/types.db /etc/collectd/types.db.local

   (The custom types.db has to be specified after the default!)

   (You'll then get a notice message in the log on startup saying
   Replacing DS `apache_bytes' with another version., which, obviously
   can be ignored.)

 * tune any existing apache_bytes RRD files using something like

 rrdtool tune $file --maximum count:$new_max

   See the rrdtune(1) manpage for details.

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

Re: [collectd] Varnish plugin

[Sebastian Harl]

Hi,

On Sun, Jun 20, 2010 at 04:48:58PM +0200, Jerome Renard wrote:
 I added Marc's branch as a remote branch so I have this in my
 .git/config file :
 
 [...]
 [remote octo]
   url = git://github.com/octo/collectd.git
   fetch = +refs/heads/jr/varnish:refs/remotes/octo/jr/varnish
 [remote mfournier]
   url = http://github.com/mfournier/collectd.git
   fetch = +refs/heads/master:refs/remotes/mfournier/master
 [...]
 
 But whenever I run git merge mfournier/master revnumber git just merges
 everything (34 commits) and not only the one I want. Did I do something wrong 
 ?

The purpose of git-merge is to join two lines of history to form a new
commit that is supposed to represent the same state of the repository as
if *all* commits of the merged branches had happened in the current
branch. Branches are specified by their head commit, i.e. the tip of
the requested branch. This may either be done using a name (e.g.
mfournier/master) or by specifying the SHA1 of the head commit (or
whatever else is supported by git-rev-parse ;-)). Also, git-merge allows
to specify more than one branch. This is, what you actually did: you
specified the branch mfournier/master and the branch, whose head
commit is revnumber and told git to merge those two into the current
branch.

If you want to pick and apply a single commit only, use git-cherry-pick:
git cherry-pick revnumber. This will then apply the changes introduced
by revnumber on top of your current branch.

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

Re: [collectd] Unable to compile collectd 4.10.0 on Rocks 5.3 (CentOS 5.4) 64-bit

[Sebastian Harl]

Hi Finn,

On Thu, Jun 03, 2010 at 03:54:00PM +0200, Finn Andersen wrote:
 I tried to compile collectd from source, typing configure;make
 This is the output I got (ran make twice to get rid of the stuff that
 compiled fine):

 cc1: warnings being treated as errors
 python.c: In function 'cpy_write_callback':
 python.c:422: warning: dereferencing type-punned pointer will break
 strict-aliasing rules

This seems to be a problem with the (Python) implementation of the
Py_True and Py_False variables. A fix/work-around is available in
the Git repo in commit 2f2f3a6 [1].

HTH,
Sebastian

[1] http://git.verplant.org/?p=collectd.git;a=commit;h=2f2f3a6

-- 
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] Collectd stops data collection after change in System time (towards the past time)

[Sebastian Harl]

Hi Saurabh,

On Sat, May 29, 2010 at 05:22:12PM +0530, saurabh wrote:
 Scenario:
 I am starting collectd, and allow it to run for some time. After then
 I am changing system time (let say: changing time to 1 minutes : past),
 
 collected then not collecting data for 1 minutes (may be for obvious
 reason !: )
 it again then starts reading values after next one minute laps.

Well, the problem is two-fold. First, RRDtool (which is used as data
storage in most cases) discards updates in the past, i.e. if an
update arrives which is older than the previous update. This might or
might not be considered a reasonable behavior, but I guess the main
reason is that changing that would be fairly complicated (since old data
is consolidated).

Second, collectd checks for that as well. I suppose, this might be some
leftovers from the early days when collectd could write to RRDs only.
However, collectd does not discard that value (completely). It does not
add it to the global cache (which, e.g., is used by the unixsock
plugin) but it does send it to the write/output plugins. So., e.g., if
you're using the csv plugin (which probably does not make much sense,
though, in most cases), the data should be written out.

Unfortunately, we cannot do much about the behavior of RRDtool.

 What it seems to me is , if I start collected with 1 year advance date
 (future date),
 then after some time I correct time again , It will not collect data for
 One year ?!

collectd *will* collect data for that time but when writing to RRD
files, RRDtool will discard them.

 Could you please me point out the modules where such time logic is being
 accessed?
 If this is such problem, i will try to look in this.

As I said above, there's not much we can do about that (in collectd).
You could write to the RRDtool developers [1] and discuss the issue
there.

 As in various embedded systems, Systems may start with some defaults
 dates and , then
 many date corrections occurs during  life time, without system restart

What you should do in that case is to start collectd after initially
correcting the system time. Then, if you have any time-drifts later on,
you'll lose a few data points only, which, hopefully, should happen
rarely and, thus, not matter (that) much.

 (and so without any
 deamon restart :) )

A daemon restart won't help you either, since this is not caused by the
daemon.

HTH,
Sebastian

1 https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

-- 
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] [PATCH] make rrdcached.c accept RRD creation options

[Sebastian Harl]

Hi Thorsten,

On Fri, Apr 30, 2010 at 08:08:04AM -0700, Thorsten von Eicken wrote:
 I patched rrdcached.c to accept the same RRD creation options as the 
 rrdtool plugin accepts. It's not pretty in that it duplicates code, but 
 it works. Patch for rrdcached.c and collectd.conf.pod below.

Just a quick note, without having looked at the patch or anything ;-) It
probably makes sense to provide config handling functions in the
`utils_rrdcreate' module for parsing those options. This could then be
used in the `rrdtool' and `rrdcached' plugins. Would you be willing to
refactor the code in order to implement 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] Need help with sensors plugin

[Sebastian Harl]

Hi,

On Wed, Apr 14, 2010 at 11:03:56PM +0200, Bruno Friedmann wrote:
 On 04/14/2010 09:39 AM, Sebastian Harl wrote:
  Where did you get collectd from? Did you compile it yourself or do you
  use some pre-compiled packages? Which Linux distribution do you use?
 
 I'm using the rpm package coming from 
 http://download.opensuse.org/repositories/server:/monitoring/openSUSE_11.2
 openSUSE 11.2 64Bits
 
 As what I've seen there's nothing special in this package.
 Do you need to check something special ?

Well, in Debian, I've had the problem that libsnmp depended on
libsensors3 (i.e. lm-sensors 2.x) which conflicted with lm-sensors 3.x.
So, I had the choice of either disabling the “snmp” plugin or linking
the “sensors” plugin against libsensors3 and, thus, having very limited
functionality in that plugin. The former was no real option for me, so I
decided to do the latter. I suppose that other distributions might have
similar problems. In Debian, this is now solved by updated net-snmp
packages which now support lm-sensors 3.x as well.

As Marco suggested, re-compiling the “sensors” plugin using lm-sensors
3.x will help but I would not expect SuSE to provide updated packages (I
have no clue though about how package updates are handled in SuSE and
this particular repository) or compile it yourself.

Anyway, you could try to contact the maintainer of the packages you are
using, describe your problem and forward the solution mentioned above.

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

Re: [collectd] nanosleep configure tests

[Sebastian Harl]

Hi Vincent,

On Fri, Mar 26, 2010 at 09:55:32AM +1100, Vincent McIntyre wrote:
 I found another discussion of this
   http://lists.apple.com/archives/Darwin-development/2002/Apr/msg00408.html
 that suggests the patch is more like
 
 - AC_CHECK_FUNCS(nanosleep, [], AC_CHECK_LIB(rt, nanosleep,
 nanosleep_needs rt=yes], AC_MSG_ERROR(cannot find nanosleep)))
 
 + 
 AC_CHECK_FUNCS(nanosleep,,[AC_CHECK_LIB(rt,nanosleep,LTHREAD_LIBS=$LTHREAD_LIBS
 -lrt,[AC_CHECK_LIB(posix4,nanosleep,LIB=$LTHREAD_LIBS -lposix4)])])

Thanks for reporting this and digging up a solution!

The attached patch should integrate this fix into the collectd build
system. Could you please verify that this works for you? I don't have
Solaris around to test the patch myself.

The patch is also available in the sh/collectd-4.8 branch in
git://git.tokkee.org/collectd.git (to be merged by Florian, who will
then merge it into 4.9 and master).

To apply the patch, do (in the toplevel source directory):

  patch -p1  posix4-check.patch

To rebuild the build system, do:

  make configure

If that does not work (e.g., in case your autoconf version does not
match), do:

  ./build.sh

… and then re-run configure.

TIA,
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

configure, src/Makefile: Check for nanosleep() in libposix4 as well.

On, e.g., Solaris 2.6, nanosleep() is only available from that library.

Thanks to Vincent McIntyre for reporting this and providing an initial patch.

diff --git a/configure.in b/configure.in
index f46a362..f8bf90c 100644
--- a/configure.in
+++ b/configure.in
@@ -528,8 +528,16 @@ AC_CHECK_FUNCS(socket, [], AC_CHECK_LIB(socket, socket, [socket_needs_socket=ye
 AM_CONDITIONAL(BUILD_WITH_LIBSOCKET, test x$socket_needs_socket = xyes)
 
 nanosleep_needs_rt=no
-AC_CHECK_FUNCS(nanosleep, [], AC_CHECK_LIB(rt, nanosleep, [nanosleep_needs_rt=yes], AC_MSG_ERROR(cannot find nanosleep)))
+nanosleep_needs_posix4=no
+AC_CHECK_FUNCS(nanosleep,
+[],
+AC_CHECK_LIB(rt, nanosleep,
+[nanosleep_needs_rt=yes],
+AC_CHECK_LIB(posix4, nanosleep,
+[nanosleep_needs_posix4=yes],
+AC_MSG_ERROR(cannot find nanosleep
 AM_CONDITIONAL(BUILD_WITH_LIBRT, test x$nanosleep_needs_rt = xyes)
+AM_CONDITIONAL(BUILD_WITH_LIBPOSIX4, test x$nanosleep_needs_posix4 = xyes)
 
 AC_CHECK_FUNCS(sysctl, [have_sysctl=yes], [have_sysctl=no])
 AC_CHECK_FUNCS(sysctlbyname, [have_sysctlbyname=yes], [have_sysctlbyname=no])
diff --git a/src/Makefile.am b/src/Makefile.am
index 0ed299b..f533b12 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -53,6 +53,9 @@ collectd_DEPENDENCIES =
 if BUILD_WITH_LIBRT
 collectd_LDADD += -lrt
 endif
+if BUILD_WITH_LIBPOSIX4
+collectd_LDADD += -lposix4
+endif
 if BUILD_WITH_LIBSOCKET
 collectd_LDADD += -lsocket
 endif


signature.asc
Description: Digital signature
___
collectd mailing list
collectd@verplant.org
http://mailman.verplant.org/listinfo/collectd

Re: [collectd] Not seeing postgres data from collectd.

[Sebastian Harl]

Hi,

On Wed, Mar 10, 2010 at 10:47:39AM -0800, James Armstrong wrote:
 Sebastian Harl wrote:
  On your local machine, are there any files in /var/lib/collectd/rrd/
  hostname/postgresql-dwh/?
  
  Are there any other files in /var/lib/collectd/rrd/ (on the local
  machine)?
 
 Here is the problem!
 
 The data is appearing in
 /var/lib/collectd/rrd/192.168.X.YY/postgresql-dwh/counter-eventcount.rrd
 
 All the other data appears under the hostname directory.
 
 So, it appears the postgresql plugin is using the Host from the
 Database stanza.  The database doesn't allow connections through the
 fully qualified domain name (that we use for the collectd collections.)
 Is there a way to tell the plugin that data from Host 192.168.X.YY
 should be associated with Hostname FQDN?

Yes, in case you're connecting through a UNIX socket or when connecting
to localhost. I suppose, you're running PostgreSQL on the same
machine, right? In that case, simply leaving out the Host config
option will let the plugin connect to the UNIX socket.

So, you're getting values on the local machine now? Do you get the same
values on the central server as well?

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

Re: [collectd] [PATCH] Interface option for network plugin

[Sebastian Harl]

Hi,

On Tue, Mar 09, 2010 at 06:17:35PM +0100, Florian Forster wrote:
 On Fri, Feb 26, 2010 at 12:49:02PM +0100, Max Henkel wrote:
  +   if (! IN_MULTICAST (ntohl (addr-sin_addr.s_addr)))
  +   return (0);
 
 Doesn't it make sense to be able to set the interface in unicast mode,
 too? For example if the host has multiple default gateways. The
 socket(7) option SO_BINDTODEVICE could be used for this I guess.

Please note that, iIrc, that option is Linux-specific. Not sure whether
that also applies to the patch proposed by Max, though.

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] Not seeing postgres data from collectd.

[Sebastian Harl]

Hi James,

On Tue, Mar 09, 2010 at 03:36:31PM -0800, James Armstrong wrote:
 Sebastian Harl wrote:
  On Tue, Mar 09, 2010 at 01:51:24PM -0800, James Armstrong wrote:
  Sebastian Harl wrote:
  One possibility, this query takes a while to return, over 30 seconds.
  Could it be timing out, and if so, how can I change the timeout for this
  query without changing other intervals?

  I would not expect the query to time out (it runs fine from an
  interactive client, which should basically be the same). However, it
  will cause RRDtool to generate an empty graph. Do you use the rrdtool
  plugin? Did you really make sure that *no* data at all arrives at the
  server? Does collectd create any RRD files at all ($hostname/ 
  postgresql-dwh/counter-eventcount.rrd)? Is there any data in that file
  (run 'rrdtool fetch path/to/counter-eventcount.rrd MAX')? Did you try to
  store the collected data on the client as well? Does that work fine?
 
 Yes, we use rrdtool.  No data was arriving at the remote machine (none
 was in the UDP packet I captured with tcpdump.)  So, I enabled rrdtool
 on the local machine -- no data was being captured there, either.

For how long did you capture packets? If there query takes over 30
seconds, you'd, obviously, have to capture for at least that amount of
time.

Your server does receive and collect the other data, right?

On your local machine, are there any files in /var/lib/collectd/rrd/
hostname/postgresql-dwh/?

Are there any other files in /var/lib/collectd/rrd/ (on the local
machine)?

Btw., if the query would time out, you should get a warning / error
message in the logs.

Are there *any* messages related to postgresql in the log file?
grep -Fi postgresql /var/log/collectd.log

 Here's the complete /etc/collectd.conf file (with IP's and passwords
 changed for all the obvious reasons!) in case there are conflicts:

That config looks fine to me.


Sorry for being a bit in the dark and possibly asking stupid questions,
but I could not reproduce that behavior so far (I'll see if I can find
some query that takes such a long time) and your setup looks fine to me.

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] Not seeing postgres data from collectd.

[Sebastian Harl]

Hi,

On Mon, Mar 08, 2010 at 01:04:19PM -0800, James Armstrong wrote:
 We're trying to add a monitor for some table sizes to collectd for a
 postgres database.  Our configuration is to use a central server to host
 the data, and various machines send the data to that server.
 
 I've added the following to /etc/collectd.conf on a working machine and
 restarted collectd, but the postgres data is not appearing in the UDP
 packets.  I have confirmed this with tcpdump.
 
 LoadPlugin postgresql
 
 ...
 
 Plugin postgresql
   Query eventcount
 Statement SELECT COUNT(*) AS count FROM events;
 Result
   Type counter
   InstancePrefix eventcount
   ValuesFrom count
 /Result
   /Query
 
   Database dwh
 Host 192.168.X.YY
 User dbuser
 Password (correct password)
 Query eventcount
   /Database
 /Plugin

That config snippet looks fine to me.

 The connection information for the database works, confirmed with psql.

What's the exact psql command line you were using to verify that?

Did you verify that the postgresql plugin actually connects to the
database (select * from pg_stat_activity where datname = 'dwh')?

Given that nobody else accesses the same table, the following query
might give you an idea whether the query is executed at all: select
seq_scan, seq_tup_read from pg_stat_user_tables where relname = 'dwh'.
That query should return numbers that are increased after each collectd
interval. Else, you could also configure PostgreSQL to log every query
to make sure the query is actually executed by collectd.

Which version of collectd do you use?

 There are no error messages in the logfile, we're using the logfile
 plugin at loglevel debug.

To make use of loglevel debug, collectd has to be compiled with
debugging enabled. Is that the case? You should then see *lots* of
messages in the log file.

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

Re: [collectd] Proposal: Make collectdmon start several instances of collectd based on configuration file

[Sebastian Harl]

Hi Yann,

On Tue, Feb 23, 2010 at 04:31:27PM +, Yann Hamon wrote:
  On Tue, Sep 08, 2009 at 10:45:35AM +0200, Peter Fischer wrote:
   I was playing with the 1wire plugin lately und of cource came about the
   EXPERIMENTAL! paragraph.
   I think there would be a relatively simple solution for that:
* In every plugin's stanza in collectd.conf an interval can be given. If
   there is none, the global default is being used.
* During startup, collectdmon would enumerate every plugin's desired
   interval, group these, and would start in collectd instance for every 
   single
   interval in the group.
   for example:
* soil temperature and humidity is measured every 30min
* barometric pressure is read every 5 min
* ambient temperature and humidity is measured every 2 min
* everything else uses the default 10 seconds interval
   in that case collectdmon would start four instances of collectd running 
   with
   different intervals
  
  In fact, support for a similar feature has already been implemented
  in collectd. However, currently, there is no way to actually use
  that since it cannot be configured so far.
  
  The problem is that we'd probably have to touch any single plugin to
  be able to make that configurable, so this is going to be a fair bit
  of rather boring coding work. Another issue, we're currently a bit
  unsure about is how to reflect this feature in the config file, i.e.
  what kind of config option should be introduced. I guess, it's the
  best to introduce a config option (e.g. Interval) for each and
  every plugin (as you suggested as well), but I'm not a 100% sure
  about that yet. Any comments would be appreciated.

 In an ideal world, you would set a DefaultInterval for all plugins
 (20secs?) and then potentially overwrite that value in the
 configuration of every plugin. That would be perfect. 

Yes, that is the idea, basically.

 But maybe there are restrictions, like a plugin could only have an
 interval that is a multiple of the base interval?

There are no such restrictions (from a collectd-core architectural point
of view). The question is, whether we want to introduce a config block
for each and every plugin where most plugins will support a single
config option (Interval) only. This would, e.g., look like this:

  Interval 10 # default

  LoadPlugin cpu
  LoadPlugin load
  LoadPlugin postgresql
  LoadPlugin rrdtool

  Plugin cpu
  Interval 5
  /Plugin

  Plugin postgresql
  Interval 60
  # more postgresql configuration
  /Plugin

  # more configuration

Then, cpu would read its values using a 5 seconds interval, load would
use the default of 10 seconds and postgresql would use 60 seconds. As I
said before, the downside of this approach is that this feature has to
be implemented in every single plugin.

Another approach might be to do something like this:

  Interval 10

  LoadPlugin cpu
Interval 5
  /LoadPlugin
  LoadPlugin load

  # more configuration

This could be implemented in the daemon itself, so it would not require
a modification of every plugin. Plugins could still support a more
specific Interval option (e.g., the postgresql plugin might want to
support different intervals for querying different databases). However,
that would introduce three different kinds of intervals: a global
interval, a plugin specific interval overwriting the global
configuration and a plugin instance (or whatever) specific interval
overwriting the plugin specific interval. That might be confusing to
users but it would probably require the least code changes and the most
consistent behavior (as in: it's not possible to accidentally have some
plugin not implementing the plugin specific interval option). Also, I'm
not yet a 100% sure how to implement that [*].

Any comments about that?

Cheers,
Sebastian

[*] One approach might be to keep a look-up table in the daemon, storing
(plugin name, interval) pairs. When a plugin registers a read
callback without specifying an interval, the daemon would try to
look up the interval in that table and fall back to the global
interval. This would require all plugins to strictly follow a naming
convention when registering read callbacks, though (e.g.
plugin_name-instance).

-- 
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] rrdcached/collectd ports

[Sebastian Harl]

Hi Stefan,

On Fri, Aug 07, 2009 at 10:50:14AM +0200, stefan.wiedero...@kaufland.de wrote:
 sorry about the late reply, two weeks holiday and other stuff kept me away 
 from my collectd POC.

Apparently, your reply got lost somewhere in the backwaters of my
mailbox … sorry for that :-/

 the only thing I´m not sure about are the rrd-files on my central
 server running rrdcached, because rrdcached will complain if I setup a
 new host - because he has no data files to write to:
 Aug  6 09:31:47 ipmzs02 rrdcached[25924]: handle_request_update: 
 stat 
 (/opt/collectd/collectd/var/lib/collectd/host.on.somedomain/df/df-import-QPL_lsarch.rrd)
  
 failed.
 do I have to transfer the files initially from my client?

As of now, RRDCacheD does not support to create any RRD files on it's
own (i.e. rrdcreate is not supported by the caching daemon).

The only sensible approach I can think of how to fix that, would be to
run collectd on your central server. Then, do not send to RRDCacheD
directly but use the collectd network plugin to transfer the traffic
using the collectd network protocol (from a collectd client to the
collectd server). That central collectd server could then send all
values to RRDCacheD and take care of creating any new files (set the
CreateFiles config option to true).

It might make sense to mention that option in the manpage … any
volunteers? ;-)

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

Re: [collectd] [PATCH] add contrib/Openvz with perl code to monitor and graph openvz beancounters

[Sebastian Harl]

Hi Fabian,

Sorry that you did not receive any reply so far -- your E-mail must have
been lost somewhere in Florian's *and* my mailbox … :-/

On Sun, Jul 05, 2009 at 01:38:43PM +0200, Fabian Linzberger wrote:
 i finally got round get some perl code to monitor openvz [1] guest
 instances with collectd to work. i also wrote a little README.
 
 i included a patch to add it to the contrib directory. i hope it will
 be useful to somebody.

Thanks a lot for your patch!

 if you have any suggestions on how to better integrate it with the
 collectd distribution, i would be happy to improve it a little more.

I think it would make sense to merge Openvz.pm and OpenvzFailcnt.pm into
a single plugin (and, possibly, add a config option to configure which
values to collect). Also, that commented out ignorelist like feature
could be implemented as a set of config options (similar to the
ignorelist used in some C-based plugins).

Also, please note that in December last year, Jonathan Kolb submitted
another Perl-based OpenVZ plugin collecting interface, cpu, df, load,
process and users statistics by calling vzctl and vzlist. Do you happen
to know if that information is available from /proc (on the host system)
as well? Do you think it would make sense to merge his and your plugins?

Cheers,
Sebastian

 [1] http://wiki.openvz.org/Main_Page

-- 
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] Proposal: Make collectdmon start several instances of collectd based on configuration file

[Sebastian Harl]

Hi Peter,

On Tue, Sep 08, 2009 at 10:45:35AM +0200, Peter Fischer wrote:
 I was playing with the 1wire plugin lately und of cource came about the
 EXPERIMENTAL! paragraph.
 I think there would be a relatively simple solution for that:
  * In every plugin's stanza in collectd.conf an interval can be given. If
 there is none, the global default is being used.
  * During startup, collectdmon would enumerate every plugin's desired
 interval, group these, and would start in collectd instance for every single
 interval in the group.
 for example:
  * soil temperature and humidity is measured every 30min
  * barometric pressure is read every 5 min
  * ambient temperature and humidity is measured every 2 min
  * everything else uses the default 10 seconds interval
 in that case collectdmon would start four instances of collectd running with
 different intervals

In fact, support for a similar feature has already been implemented in
collectd. However, currently, there is no way to actually use that since
it cannot be configured so far.

The problem is that we'd probably have to touch any single plugin to be
able to make that configurable, so this is going to be a fair bit of
rather boring coding work. Another issue, we're currently a bit unsure
about is how to reflect this feature in the config file, i.e. what kind
of config option should be introduced. I guess, it's the best to
introduce a config option (e.g. Interval) for each and every plugin
(as you suggested as well), but I'm not a 100% sure about that yet. Any
comments would be appreciated.

In any way, implementing that in collectdmon sounds totally wrong to me.

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] Redesign of the Debian collectd package

[Sebastian Harl]

Hi Mariusz,

Sorry for the late reply -- I'm still fairly undecided about this.

On Wed, Oct 14, 2009 at 12:35:25PM +0200, Mariusz Gronczewski wrote:
 one more thing about collectd package. Atm (at least in testing) when
 u purge package it removes all rrd files from /var/lib/collectd, so
 when for example (like i did on one of my servers) u want to compile
 ur own version (coz u need plugin x or function y and ure using stable
 whch dont have it) and u remove collectd package all data is gone
 (good i had backups ;]), it should ask like some other packages do u
 want to remove statistic data also (i think mysql and dokuwiki have
 something like that)

The way I currently see this is that purge is supposed to remove all
tracks of the package from your system and I'm not sure if this warrants
introducing an, imho, rather annoying debconf question. If you want to
keep your data (including configuration), you should use remove rather
than purge. OTOH, removing collected data is really annoying as well …

I guess, I'll see if I can find out about best practices regarding
that kind of issue.

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] Monitoring collectd

[Sebastian Harl]

Hi,

On Wed, Oct 14, 2009 at 04:14:27PM +0200, Andrés J. Díaz wrote:
  I'm looking for a way to monitor, in collectd server, data coming from
  multiples servers and make me some kind of alert when some server
  stops sending UDP packages to collectd. How do you know if some server
  stops sending  data to collectd server?
 
 You can define a threshold to do this, if you only need a online
 threshold, that is
 only send an alert when host down, you can use a dummy threshold like this:
 
 Threshold
   Plugin load
  WarningMin 0 # dummy threshold
   /Plugin
 /Threshold
 
 So, the threshold never raises, because load never will be lower than 0,
 but when NaN, a FAILURE alert will be dispatched.

Hrm, this might even warrant a new (boolean) config option, which, if
set, will mark a data-set as interesting and thus causes a
notification to be dispatched if the value is missing. Of course, your
work-around works as well, but that should rather be considered a bad
hack (no offense ;-)) and it's fairly hard to understand when looking at
the config file.

Any other opinions about 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] monitor ethernet network throughput

[Sebastian Harl]

Hi Israel,

On Thu, Oct 22, 2009 at 01:30:02PM -0500, Israel Garcia wrote:
 Can I monitor this parameter in collectd?

Does the interface plugin provide what you're looking for?

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] dns plugin patch

[Sebastian Harl]

Hi Amit,

On Mon, Feb 15, 2010 at 07:20:26PM +0530, Amit Gupta wrote:
 On Wed, Feb 10, 2010 at 7:04 PM, Florian Forster o...@verplant.org wrote:
  On Wed, Feb 10, 2010 at 05:13:22PM +0530, Amit Gupta wrote:
   - struct ip6_ext is defined in netinet/ip_compat.h for Solaris
 10/OpenSolaris and thus needs to be included in utils_dns.c.
 
   +#define SOLARIS2 10
 
  What does this define do? Can you document that in the code so the
  casual reader knows what's going on?
 
 This is needed by ip_compat.h on solaris to include the right structures and
 include files for a particular version of solaris. I am thinking of moving
 this define to the config.h.in and its value will be the solaris version
 (extracted from $host_os)

Sounds good to me. Also, imho, this should be defined on Solaris only,
i.e. if KERNEL_SOLARIS is defined.

   +#include netinet/ip_compat.h
 
  That file isn't available under Debian Linux. Could you find out if
  that file needs to be included before / after some other file (there are
  such limitations under BSD for other netinet/*.h files) and add an
  appropriate check to the configure script?
 
 I am not sure about this. I will try to figure out.
 
# include netinet/in_systm.h
 
  It's probably a good idea to base the check for netinet/ip_compat.h on
  the check for netinet/in_systm.h.
 
 Does including the ip_compat.h under #if KERNEL_SOLARIS makes sense given
 that this is a solaris specific fix?

Makes sense to me.

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] [patch] WriteHttp plugin StoreRates config option

[Sebastian Harl]

Hi Paul,

On Sun, Feb 14, 2010 at 10:36:18PM -0700, Paul Sadauskas wrote:
 I've added a StoreRates option to the write_http plugin, similar to
 how it works in the csv plugin. I've attached the patch, or there's
 this branch on github, which should merge cleanly with 4.9.

Thanks for your patch!

Since Florian is offline for a few days, I've put your patch into the
sh/next branch in git.tokkee.org/collectd.git, ready to be merged into
Florian's master whenever he's back.

See two quick comments below.

 @@ -142,7 +143,7 @@ static int wh_callback_init (wh_callback_t *cb) /* {{{ */
  ssnprintf (cb-credentials, credentials_size, %s:%s,
  cb-user, (cb-pass == NULL) ?  : 
 cb-pass);
  curl_easy_setopt (cb-curl, CURLOPT_USERPWD, 
 cb-credentials);
 -curl_easy_setopt (cb-curl, CURLOPT_HTTPAUTH, 
 CURLAUTH_DIGEST);
 +curl_easy_setopt (cb-curl, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
  }
  
  curl_easy_setopt (cb-curl, CURLOPT_SSL_VERIFYPEER, cb-verify_peer);

This hunk is already available in collectd-4.8 and will be merged into
4.9 and master soonish. I've, thus, removed it from your patch.

 @@ -299,7 +302,22 @@ static int wh_value_list_to_string (char *buffer, /* {{{ 
 */
  if (ds-ds[i].type == DS_TYPE_GAUGE)
  BUFFER_ADD (:%f, vl-values[i].gauge);
  else if (ds-ds[i].type == DS_TYPE_COUNTER)
 -BUFFER_ADD (:%llu, vl-values[i].counter);
 +{
 +if (cb-store_rates != 0) 
 +{
 + if (rates == NULL)
 + rates = uc_get_rate (ds, vl);

The memory returned by uc_get_rate() has to be freed by the caller. I've
fixed that in sh/next as well.

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

[collectd] How/Whan branches are merged in git.verplant.org (was: write_http not working)

[Sebastian Harl]

Heya,

On Fri, Feb 12, 2010 at 11:19:36AM -0700, Paul Sadauskas wrote:
 Yes, it works for us, we're using it. For the first part, basic/digest
 auth, there is a patch that got applied to the 4.8 branch that uses
 both, but it doesn't look like it got forwarded to the 4.9 branch. I
 pinged octo on IRC, hopefully this will be fixed soon.

Patches are applied to the oldest branch it applies to (and which is
still actively maintained). Every once in a while (on a more or less
irregular base), old branches are then merged into newer branches
one after another. So, it will take a bit of time until patches are
available in all branches. See [1] for some more details.

Cheers,
Sebastian

[1] http://collectd.org/wiki/index.php/Repository#Organization

-- 
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] df plugins doesn't compile on OpenBSD 4.3

[Sebastian Harl]

Hi Andreas,

On Wed, Dec 30, 2009 at 10:38:40AM +0100, Andreas Maus wrote:
 The only error occurs on OpenBSD 4.3 compiling the df plugin:
[…]
 df.c:313: error: structure has no member named `f_favail'

 The member f_favail in the structure statfs has been introduced in OpenBSD 
 4.4.
 
 I modified the configure.in and src/df.c files to check the availability of
 f_favail (see attached diff).

Thanks for your patch! See a minor comment below.

 +#ifdef HAVE_STATFS_F_FAVAIL
   inode_free = (uint64_t) statbuf.f_favail;
   inode_reserved = (uint64_t) (statbuf.f_ffree - 
 statbuf.f_favail);
 +#else
 + inode_free = (uint64_t) statbuf.f_ffree;
 + inode_reserved = (uint64_t) 0;
 +#endif

Rather than setting the value to zero, if f_favail is not available, I'd
not submit the free (and reserved, which is calculated using f_favail)
at all.

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] curl_xml plugin

[Sebastian Harl]

Hi Amit,

On Tue, Dec 29, 2009 at 07:24:46PM +0530, Amit Gupta wrote:
 On Tue, Dec 29, 2009 at 3:31 PM, Amit Gupta amit.gupta...@gmail.com wrote:
  On Mon, Dec 21, 2009 at 11:59 PM, Florian Forster o...@verplant.orgwrote:
  Where:
 
   * The argumetn to XPath is an xpath which returns a base block in
 which to look further.
   * The arguments to Instance and Values are xpath expressions, too.
 
  Just a clarification, Instance here will be type_instance(s) and thus can
  be anything (not just xpath), right?
 
 I guess I understood why Instance has to be a xpath expression if table
 is true. Instance xpath would return list of values which will be used as
 type_instances for multiple type values returned by evaluating xpaths in
 Values. Is my understanding correct?.

Yep, that's right.

If Table is false, a simple string would be sufficient as well, but
changing the semantics of Instance depending on Table would be
confusing -- also, people might still want to fetch the instance from
the XML file.

Other plugins (e.g., postgresql) handle that by introducing an option
called InstancePrefix which expects a string as argument. That string
is prepended to the type_instance.

If Table is false, Instance would be optional, thus making it
possible to specify a constant string as type_instance using Instance-
Prefix.

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] Bug#495936: Redesign of the Debian collectd package

[Sebastian Harl]

Hi everybody,

On Wed, Sep 30, 2009 at 06:37:48PM +0200, Sebastian Harl wrote:
 This is a follow-up to Debian bug report [bts495936] and to other people
 interested in that issue. Below, you'll find a summary of the changes, I
 intend to implement in the Debian packaging of collectd.
[package split]

Sorry for the huge delay! Life (work mostly) has struck me quite hard
during the last couple of weeks. Anyway, splitting the package into
collectd-core and collectd has finally been implemented and uploaded
now. The 4.8.2-1 upload should hit NEW in a few moments.

Despite my original proposal, the collectd package still has a hard
dependency on librrd and there is no debconf support to configure the
write plugins yet. I've decided that splitting some plugins' config-
uration out of collectd.conf would not be a good idea. Also, managing
that configuration sanely is not trivial as of now. What I'm planning to
do instead is to introduce a tool called collectdconf upstream. Similar
to Postfix's postconf, this will be able to modify collectd's config
file. This tool will then be used in the collectd packge.

Anyway, of course, collectd-core does not have a dependency on
anything else than libc and libltd (I'm no longer using the embedded
copy to avoid (binary) code duplication in the archive).

Since the new package will have to be manually processed by Debian's
FTPmasters (due to the new binary package), I've made amd64, i386 and
powerpc packages available on [people.d.o]. Any feedback (especially
about upgrading from previous installations) would be very appreciated.

Further comments and suggestions are very welcome as well.

Cheers,
Sebastian

 [bts495936] http://bugs.debian.org/495936

[people.d.o] http://people.debian.org/~tokkee/collectd-4.8.2/

-- 
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