Difference between revisions of "Roadmap"

From collectd Wiki
Jump to: navigation, search
(Planned features: +mon.itor.us plugin)
(perfmon output: Did not make it into 4.7.)
Line 23: Line 23:
 
=== perfmon output ===
 
=== perfmon output ===
  
<em>Dave McLellan</em> is looking into a text output plugin which creates <em>perfmon</em> compatible output (last contact: April 15<sup>th</sup>, 2009). This feature will probably not make it into 4.7. See also: [[#output_text_plugin]]
+
<em>Dave McLellan</em> is looking into a text output plugin which creates <em>perfmon</em> compatible output (last contact: April 15<sup>th</sup>, 2009). See also: [[#output_text_plugin]]
  
 
=== Library for binary network protocol ===
 
=== Library for binary network protocol ===

Revision as of 12:33, 20 June 2009

Description

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

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.

Introduce a DERIVE data source type

In order to handle counter resets more gracefully, it'd be desirable to have DERIVE data sources in addition to the already existing COUNTER data source type. Mariusz Gronczewski is working on a patch. Latest patch.

mon.itor.us plugin

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

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