Metrics are being reported in the order they were seen. This is a peculiarity of Object.keys() that persisted when we switched to Maps for metric storage.
In conjunction with #689, which will allow people to disable particular default metrics, and #539, which has a side effect of reducing the degree of label reordering between cluster_metrics calls, I think it would be useful from an ergonomics standpoint if someone reordered the defaultMetrics to register the metrics in order of their metric name.
Since each of the metrics uses a common prefix for all of its own stats, this should mostly be a matter of rearranging the entries in the object in lib/defaultMetrics.js to order the prefixes alphabetically, and then inspecting the output from one of the examples to verify.
Some defaults like heapSizeAndUsed may need a little tweak to make sure the first metric registered is the one with the collect() on it (currently that's total, which is alphabetically last).
Metrics are being reported in the order they were seen. This is a peculiarity of Object.keys() that persisted when we switched to Maps for metric storage.
In conjunction with #689, which will allow people to disable particular default metrics, and #539, which has a side effect of reducing the degree of label reordering between cluster_metrics calls, I think it would be useful from an ergonomics standpoint if someone reordered the defaultMetrics to register the metrics in order of their metric name.
Since each of the metrics uses a common prefix for all of its own stats, this should mostly be a matter of rearranging the entries in the object in lib/defaultMetrics.js to order the prefixes alphabetically, and then inspecting the output from one of the examples to verify.
Some defaults like heapSizeAndUsed may need a little tweak to make sure the first metric registered is the one with the collect() on it (currently that's total, which is alphabetically last).