mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Mahler <benjamin.mah...@gmail.com>
Subject Re: Review Request 44473: Added decrement operator to Counter.
Date Fri, 11 Mar 2016 02:35:07 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message