Mailing-List: contact reviews-help@mesos.apache.org; run by ezmlm
Precedence: bulk
Reply-To: reviews@mesos.apache.org
Content-Type: multipart/alternative;
 boundary="===============2519646313174888398=="
MIME-Version: 1.0
Subject: Re: Review Request 61126: Converted Timer value to counting semantics.
From: Jiang Yan Xu <yan@jxu.me>
To: Kevin Klues <klueska@gmail.com>, Benjamin Mahler <bmahler@apache.org>,
 Jiang Yan Xu <yan@jxu.me>
Cc: James Peach <jpeach@apache.org>, mesos <reviews@mesos.apache.org>
Date: Fri, 01 Sep 2017 18:24:02 -0000
Message-ID: <20170901182402.29701.57872@reviews-vm2.apache.org>
Auto-Submitted: auto-generated
Sender: Jiang Yan Xu <noreply@reviews.apache.org>
References: <20170726000356.9520.84085@reviews-vm2.apache.org>
In-Reply-To: <20170726000356.9520.84085@reviews-vm2.apache.org>
Reply-To: Jiang Yan Xu <yan@jxu.me>
archived-at: Fri, 01 Sep 2017 18:24:15 -0000

--===============2519646313174888398==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/61126/#review184381
-----------------------------------------------------------


3rdparty/libprocess/include/process/metrics/timer.hpp
Lines 45-46 (patched)
<https://reviews.apache.org/r/61126/#comment260535>

    If we need a "sum", can we just add a field "sum"? Can we keep "value" to mean what it used to mean for backwards compatibility? It doesn't hurt right?
    
    Also, why do we (which must be Prometheus' rationale as well) need a sum? What useful thing can we do about it? This is related to the abstract concept of "counting semantics" that we need to document in a design. We need a whiteboard discussion offline but perhaps we should write it down for other reviewers.


- Jiang Yan Xu


On July 25, 2017, 5:03 p.m., James Peach wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61126/
> -----------------------------------------------------------
> 
> (Updated July 25, 2017, 5:03 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler, Kevin Klues, and Jiang Yan Xu.
> 
> 
> Bugs: MESOS-6918
>     https://issues.apache.org/jira/browse/MESOS-6918
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> The value of a Timer was the elapsed time of the last timed
> interval which is not a value that can be easily graphed
> or interpreted. Replaced this with a counter which tracks
> the cumulative elapsed time of all the measurements on this
> Timer. This allows a monitoring application to plot the elapsed
> time as a rate.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/metrics/timer.hpp 0a9c0227c457c6c81a59f65f901a5464ee00983d 
>   3rdparty/libprocess/src/tests/metrics_tests.cpp 161ca0dc7aea526d450d71a80839d8cc075aaa31 
> 
> 
> Diff: https://reviews.apache.org/r/61126/diff/3/
> 
> 
> Testing
> -------
> 
> make check (Fedora 26). Note that this requires Mesos test changes in r/61127.
> 
> 
> Thanks,
> 
> James Peach
> 
>


--===============2519646313174888398==--