> On March 10, 2016, 10:30 p.m., Ben Mahler wrote: > > It looks like we need to update the documentation at the top of Counter to > > reflect that we intentionally left out decrementing, because we found that > > some metrics libraries and systems have a counter type that only supports > > going up or potentially being reset to 0. For example: > > > > http://lymph.readthedocs.org/en/latest/api/metrics_api.html#lymph.core.monitoring.metrics.Counter > > https://prometheus.io/docs/concepts/metric_types/#counter > > https://blog.pkhamre.com/understanding-statsd-and-graphite/ > > > > Think of a counter as something that just counts events that go by, in > > which context decrementing doesn't apply. If we want this decrementing > > behavior, we probably want to distinguish it with a new type of Metric. > > This is because users have asked for the ability to distinguish different > > metric types (e.g. counter vs gauge) because some monitoring systems need > > to be told whether it can be decremented. > > > > Make sense? > > Cong Wang wrote: > Yeah, kinda. But I am not sure if it worth the effort, at least the > comments there already make sense for me: > > Counter: > > 847db528 (Dominic Hamon 2014-04-10 14:04:53 -0700 24) // A Metric > that represents an integer value that can be incremented and > 847db528 (Dominic Hamon 2014-04-10 14:04:53 -0700 25) // decremented. > > Gauge: > > 847db528 (Dominic Hamon 2014-04-10 14:04:53 -0700 26) // A Metric that > represents an instantaneous value evaluated when > 847db528 (Dominic Hamon 2014-04-10 14:04:53 -0700 27) // 'value' is > called. > > We are free to define our own Counter or Gauge, we don't have to follow > any standard here.
Yeah we removed the support for decrementing, because we couldn't come up with good use cases for counters that get decremented. It seems to be the case that when a counter can be decremented, we're actually just replacing a gauge with a counter. For example, one could use a Counter to represent the number of entries in a map upon every addition and deletion, but it this seems better represented as a gauge. That aside, I think we first need to do some deeper analysis on [MESOS-4740](https://issues.apache.org/jira/browse/MESOS-4740) to determine if gauges are actually causing performance issues. - Ben ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/44473/#review123017 ----------------------------------------------------------- On March 9, 2016, 7:07 p.m., Cong Wang wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/44473/ > ----------------------------------------------------------- > > (Updated March 9, 2016, 7:07 p.m.) > > > Review request for mesos, Ben Mahler, Ian Downes, Vinod Kone, and Jiang Yan > Xu. > > > Bugs: MESOS-4740 > https://issues.apache.org/jira/browse/MESOS-4740 > > > Repository: mesos > > > Description > ------- > > Added decrement operator to Counter. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/metrics/counter.hpp > a13cc7e18c8b23eae83c326d63874d9d2aaedc0d > 3rdparty/libprocess/src/tests/metrics_tests.cpp > b84dc8d858f58bc9f52b218b7153510417cf34c2 > > Diff: https://reviews.apache.org/r/44473/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Cong Wang > >
