#960 statsmanager: helper functions for obtaining common metadata of metrics
Reporter
Jonas Wielicki
Owner
MattJ
Created
Updated
Stars
★ (1)
Tags
Status-Fixed
Milestone-0.12
Priority-Medium
Type-Enhancement
Jonas Wielicki
on
The following metadata is common for all statsmanager metrics and should be easily available:
1. unit of measure (e.g. bytes, seconds, number of events ("total"))
2. plugin/module which declared the metric
3. host to which the metric belongs (possibly nil)
4. name of the metric
5. type of the metric (counter, gauge, …)
Currently, some of that can extracted from the metric name, for other information one needs to access the extras table.
I propose that host, module and type are also moved to the extras table and the metric name is cleaned up so that it really consists only of the name.
If that is not possible (e.g. because the name is used as a key internally), I propose to have the original metric name, host, module and type *also* in the extras so that pattern matching on the metric name is not needed to extract that information.
MattJ
on
Although it's not imminent on my todo list, I do intend to revamp the metrics API at some point, and will take these issues into account. Thanks!
The following metadata is common for all statsmanager metrics and should be easily available: 1. unit of measure (e.g. bytes, seconds, number of events ("total")) 2. plugin/module which declared the metric 3. host to which the metric belongs (possibly nil) 4. name of the metric 5. type of the metric (counter, gauge, …) Currently, some of that can extracted from the metric name, for other information one needs to access the extras table. I propose that host, module and type are also moved to the extras table and the metric name is cleaned up so that it really consists only of the name. If that is not possible (e.g. because the name is used as a key internally), I propose to have the original metric name, host, module and type *also* in the extras so that pattern matching on the metric name is not needed to extract that information.
Although it's not imminent on my todo list, I do intend to revamp the metrics API at some point, and will take these issues into account. Thanks!
ChangesWill you also take https://issues.prosody.im/959 into account?
This is done in https://hg.prosody.im/trunk/rev/5f15ab7c6ae5 right?
ChangesYes, among other previous work in that direction.