feat: introduce data sink to collect snapshot from each metric periodically #1117
Conversation
| class metric_entity : public ref_counter | ||
| { | ||
| public: | ||
| using attr_map = std::unordered_map<std::string, std::string>; | ||
| using attr_map = std::map<std::string, std::string>; |
There was a problem hiding this comment.
All of the attributes of an entity will be used as the labels of the metric. The labels will later be passed to metric_snapshot, thus each metric snapshot may has multiple labels. To maintain each snapshot in a map, data sink may choose to encode the labels a snapshot has, as what metric_snapshot::encode_attributes has done. In comparison with std::unordered_map, it is easier for std::map to be encoded since it's ordered.
| @@ -215,6 +221,54 @@ class metric_entity_prototype | |||
| DISALLOW_COPY_AND_ASSIGN(metric_entity_prototype); | |||
| }; | |||
|
|
|||
| // `metric_timer` is a timer class that runs metric-related computations periodically, such as | |||
There was a problem hiding this comment.
runs metric-related computations periodically
Even though there isn't any thirdparty monitoring system, it will still caculate periodically? Would it be a bit of cost?
Another way is to calculate lazily, that is to say, calculate will only be triggered when any body request these metrics, you can define some callbacks for that.
This PR is for #1116.
This PR introduces data sink to collect snapshot from each metric periodically. The base data sink is actually an abstract class that has interfaces needed by concrete monitoring systems. The unit test has implemented a data sink and verified if the snapshots can be received correctly.