I am currently working on this. Could someone assign me this JIRA issue?
https://issues.apache.org/jira/browse/MESOS-5731
On Tue, Jun 28, 2016 at 10:43 AM, Tuan-Anh Hoang-Vu <hvtuan...@gmail.com>
wrote:
> Sounds great! I'll spend time working on this.
>
> On Mon, Jun 27, 2016 at 10:41 PM, Vinod Kone <vi...@mesosphere.io> wrote:
>
>> v1 API is not yet declared stable, so we can make changes before 1.0.
>>
>> On Mon, Jun 27, 2016 at 10:10 PM, Tuan-Anh Hoang-Vu <hvtuan...@gmail.com>
>> wrote:
>>
>> > Hi Vinod,
>> >
>> > Yes! That will also works! My only concern is will this break backward
>> > compatibility?
>> > Would this be something worth pushing upstream?
>> >
>> > On Mon, Jun 27, 2016 at 6:39 PM, Vinod Kone <vinodk...@apache.org>
>> wrote:
>> >
>> > > I was thinking more along the lines of :
>> > >
>> > > ```
>> > > GetMetrics {
>> > > repeated Metric gauges = 1;
>> > > repeated Metric counters = 2;
>> > > }
>> > > ```
>> > >
>> > > On Mon, Jun 27, 2016 at 6:27 PM, Tuan-Anh Hoang-Vu <
>> hvtuan...@gmail.com>
>> > > wrote:
>> > >
>> > > > Timer will simply measure the amount of time it takes (in ns) for an
>> > > > operation.
>> > > >
>> > > > On Mon, Jun 27, 2016 at 6:14 PM, Benjamin Mahler <
>> bmah...@apache.org>
>> > > > wrote:
>> > > >
>> > > > > What is the timer type? Is it effectively a special case of a
>> > > histogram?
>> > > > >
>> > > > > On Mon, Jun 27, 2016 at 5:34 PM, Tuan-Anh Hoang-Vu <
>> > > hvtuan...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > Hi Benjamin,
>> > > > > >
>> > > > > > We used an in-house metrics system, which is basically a
>> > time-series
>> > > > > > database.
>> > > > > > I don't know in details about the metrics system, but the
>> > collection
>> > > > > client
>> > > > > > required me to specify metric type, probably for optimization
>> > > purpose.
>> > > > It
>> > > > > > accepts 3 different types: counter, gauge and timer
>> > > > > >
>> > > > > > On Mon, Jun 27, 2016 at 5:09 PM, Benjamin Mahler <
>> > bmah...@apache.org
>> > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > > 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.
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
