RRDtool 2.x - Re-Engineering RRDtool for the next 15 Years
Since its release in 1999, RRDtool has become an integral part of many monitoring applications. Way beyond my initial vision. RRDtool is used everywhere: in tiny embedded systems as well as in huge enterprise monitoring systems with hundreds of thousands of data sources.
My main concerns when designing applications is to come up with simple and logical interfaces, covering all the necessary functionality and providing a path for further enhancement. This has worked very well with RRDtool 1.x, but there are some central design elements that are not so easily changed and are therefore blocking incremental development.
Part of the success of RRDtool is based on the fact that a single package takes care of all your time series data storage, retrieval and presentation needs. Any future version of RRDtool will do the same, only more so.
A prime objective of the 2.x rewrite is to create clear internal APIs for the interaction of the individual components of RRDtool. This will make it possible to replace or drastically modify one component without changes to the rest of the system. To some extent, this pattern was already present in RRDtool 1.x, but especially in the data storage layer the structure does not lend itself to extensions all that well.
The database component stores time series data.
The Data Retrieval and Postprocessing component takes care of all data retrieval and postprocessing needs. DEF, CDEF and VDEF functionality from RRDtool 1.x is located here, and is available to all data consumers.
The graphing component draws the charts. Its structure allow for mutliple chart types to be implemented.
RRDtool comes with a REST API. Unfortunately this raises a bunch of dependency issues, for the actual webserver, authentication, encryption. Ideally, RRDtool itself would provide some minimal implementation of these, to be able to use it standalone.
Rewriting RRDtool is a major software engineering effort. Here is the plan to achieve it.
- Collect requirements, using the GitHub Issue Tracker.
- Create Engineering Documents in the GitHub Wiki.
- Create and document a coherent, modular design, down to the internal API level.
- Plan and budget the implementation.
- Find financing. Large copr sponsors or crowd funding.
- Release 2.0
- Test Suite
All 2.x functionality is exercised by a test suite.
- Backward Compatibility
The 2.x design addresses all the complex issued not easily changed by altering RRDtool 1.x. Most of the 1.x functionality is present in RRDtool 2.x. An 1.x compatibility API emulates the 1.x behavior on top of the 2.x API.
A suitable Free Software License for RRDtool 2.x is to be determined based on feedback from the people financing the development. It could be GNU GPL V2, V3, GNU LGPL
This document will evolve as the project takes shape.
Tobi Oetiker <Ltobi@oetiker.ch>