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