Difference between revisions of "Roadmap"

From collectd Wiki
Jump to: navigation, search
(TokyoTyrant plugin: Section added.)
(TokyoTyrant plugin: Link to Paul's Git repository.)
Line 40: Line 40:
Plugin to use [http://tokyocabinet.sourceforge.net/tyrantdoc/ TokyoTyrant] to collect information about a [http://tokyocabinet.sourceforge.net/ Tokyo Cabinet] database. The plugin was written by ''Paul Sadauskas'' and is available in the ''ps/tokyotyrant'' branch in the Git repository.
Plugin to use [http://tokyocabinet.sourceforge.net/tyrantdoc/ TokyoTyrant] to collect information about a [http://tokyocabinet.sourceforge.net/ Tokyo Cabinet] database. The plugin was written by ''Paul Sadauskas'' and is available in the ''ps/tokyotyrant'' branch in the Git repository.
:''See also: [http://github.com/absperf/collectd/commits/tokyotyrant Paul's Git repository]''
== Wishlist / Ideas ==
== Wishlist / Ideas ==

Revision as of 22:08, 6 July 2009


Live goes on. Which features are planned in future releases? This page is more a list of ideas than a fixed plan for the future, but it may give you an idea where the journey is going. If you want to contribute but don't know what is to be done, simply drop us a short mail and we'll get you started.

This file is not automatically generated and may thus be out of date from time to time. To give you an idea how fresh this information is please take a look at its history.

Implemented features

The following features have been implemented and will be released as version 4.8.0. You can check out our Git repository to test these features. Any feedback and bug reports are welcome!

CouchDB plugin

The CouchDB plugin queries a page from the database of the same name and parses it, similar to the cURL and memcachec plugins. The plugin has been written by Doug MacEachern.

olsrd plugin

The olsrd plugin queries information about meshed networks from the Optimized Link State Routing daemon (olsrd).

Introduce a DERIVE data source type

In order to handle counter resets more gracefully, DERIVE and ABSOLUTE data sources have been added in addition to the already existing data source types. The initial patch was written by Mariusz Gronczewski.

Planned features

The following features are actively being worked upon. They are in various stages of completion and may or may not make it into the next release. They should have a contact (name) associated with them, so people who are interested can contact the person working on a feature. Please don't add email addresses of other people without their permission. If you want to contact a person below, please look for the email address using the mailing list archives.

perfmon output

Dave McLellan is looking into a text output plugin which creates perfmon compatible output (last contact: April 15th, 2009). See also: #output_text_plugin

Library for binary network protocol

Write a library for the binary network protocol, so that external applications have an easier job interfacing with collectd. The new authentication and encryption feature makes this even more desirable. Octo is working on it.

mon.itor.us plugin

A Perl-based plugin to read values from mon.itor.us has been contributed by Jeffrey B. Green.

TokyoTyrant plugin

Plugin to use TokyoTyrant to collect information about a Tokyo Cabinet database. The plugin was written by Paul Sadauskas and is available in the ps/tokyotyrant branch in the Git repository.

See also: Paul's Git repository

Wishlist / Ideas

The following is a list of ideas we had but so far nobody has stepped up to implement them. Feel free to add your own “cool stuff” :)

RRDtool plugin: Type-specific configuration

This would allow to keep interesting data longer and less interesting data only for a short time. Also seasonal data could be added. It's not reasonable to add seasonal data to all RRD files, because it operates on unconsolidated primary datapoints (thus taking up a lot of disk space) and you can't specify one seasonal period that fits all kinds of data. A discussion of this feature can be found in the mailinglist's archive.

Maybe an option that can be passed to write functions by the Chains mechanism would be a good idea for implementing this.

Distributed setups

Make it possible to have several "servers" with shared storage. When one server dies another one takes its place, so that you don't have gaps in your statistics. This is probably best implemented as a match that matches only those values the host is responsible for. Probably best to implement real simple first and add automatic fail-over as a second step.

A solution for non-shared storage is probably even harder to implement and likely not worth the effort.

Embed more scripting languages

Python and Lua come to mind.

Parrot is now at version 1.0 and provides a stable API. Thread- and reentrant-safety is not quite there yet, but it may be worth keeping on eye on.

Store to RDBMS

Being able to store values in an RDBMS would be nice. Bob Cotton has put together some SQL for PostgreSQL and a Perl based plugin to store values into it. This could serve as a starting point as a C based plugin with the same SQL backend.

See also: http://github.com/bcotton/collectd_dbstore/tree/master

output_text plugin

Sebastian has suggested a output_text plugin that can write values to arbitrarily formatted (text-)files. See also: #perfmon_output

Apache plugin: Per virtualhost stats

mod_watch gives access to stats like:

domain.com 8190 539056 20965428 4813 4813 0 14.520 0 4286618408
domain2.com 8190 539056 20965428 4813 4813 0 14.520 0 4286618408

Why not to use it?