It's worth doing because it has come up before [1] [2]. For our own education, in your case why is the metrics collection system interested in the type? Is it for optimization? Which metrics collection system are you using?
What are the types that the metrics collection system understands? The types that seem to show up consistently are counter, gauges, and histograms. [1] https://prometheus.io/docs/concepts/metric_types/ [2] http://docs.datadoghq.com/guides/metrics/ On Mon, Jun 27, 2016 at 4:37 PM, Tuan-Anh Hoang-Vu <hvtuan...@gmail.com> wrote: > Hi Vinod, > > Yes, my metric collection system need to distinguish between different > metrics. > Currently we hard coded all metric types into our system, but it's not very > scalable and error prone. > For example I recently discovered that we misclassified `timestamp` as > gauge instead of counter. > > On Mon, Jun 27, 2016 at 4:31 PM, Vinod Kone <vinodk...@apache.org> wrote: > > > Hey Tuan. Can I ask what you are trying to accomplish here? Does your > > metric collection system need to distinguish between different metrics? > > > > On Mon, Jun 27, 2016 at 10:35 AM, Tuan-Anh Hoang-Vu <hvtuan...@gmail.com > > > > wrote: > > > > > Hello, > > > > > > I am planning to extend current metrics endpoint (/metrics/snapshot) to > > > only > > > return a specific type of metrics (either counter, gauge or timer). It > > > would be great if I > > > can get feedback from you if this is worth pursuing, or there is an > > > existing solution, > > > or my implementation plan is sound. > > > > > > Current /metrics/snapshot endpoint returns all metrics as key-value > pairs > > > for both > > > master and agent. There is an additional timeout parameter for that > > > endpoint. > > > For backward compatibility, I want to add another parameter (`type` or > > > `metric_type`) > > > that will take a value of (`counter`, `gauge` or `timer`) and the > > endpoint > > > will > > > only return metrics of that type. > > > > > > My implement plan is to extend libprocess to support that, > particularly: > > > > > > 1. Introduce a variable called `type` in metric.hpp > > > 2. Extend constructors of Timer, Counter and Gauge classes to set that > > > variable > > > 3. Extend Future<http::Response> MetricsProcess::_snapshot() function > in > > > metrics.cpp to support additional query parameter > > > > > > How does that sound? I would love to hear feedback from you! > > > > > > Thanks, > > > Tuan. > > > > > >
