Statistics System Overhaul
The statistics layer in BIND suffers from poor separation of concerns, with several parts of BIND and its libraries each containing code for rendering statistics in XML, JSON, or in plain text. This leads to inconsistencies in the output, as well as making it harder to extend. The individual modules that generate statistics should be agnostic to the output format.
With some core parts of BIND likely to be moved into individual hooks modules (#15 (closed)) we need a way to record and access statistics without them having to be allocated space in static built-in structures.
The proposal then is to replace the existing static statistics structures with an abstract, extensible data store represented as a nested tree of key-value objects. BIND components would register counter variables within the tree of objects, and retain fast access to those variables by retaining copies of an opaque pointer for each variable.
The existing XML and JSON renderers would be replaced with generic code that can serialize the tree (or portions thereof) by enumeration without specific knowledge of the keys and values stored therein.
The supported data types would be:
- gauge
- counter
- timestamp
- text label
with additional structural types to create the tree of:
- object
- array
Wherever possible values should be accessed using atomic operations. Each variable should have a name that would be used in the XML renderer (or an implicit index for array elements). Each variable should have its associated description attached, although in cases where many variables share the same meaning (i.e. multiple entries in an array) we should be careful to avoid memory bloat.
Access to individual variables needs to be an O(1) operation for performance. Enumeration of the tree should be O(total size of tree). If variables are to be dynamically inserted or deleted, this should be O(log n) or better.