[
https://issues.apache.org/jira/browse/MESOS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194713#comment-16194713
]
James Peach commented on MESOS-6918:
------------------------------------
{quote}
...all metric types (potentially future ones as well) ... But are we sure about
this is the right/only criterion? (The examples cited in the design doc don't
consistently define this and none defines it as "semantics") Could there be
other dimensions / features to classify metrics?
{quote}
Obviously there could be a large number of ways to classify how metrics behave.
However 2 is sufficient for all the metrics we have today. I am not trying to
boil the ocean here and invent the high temple of metrics systems; I'm just
trying to improve the one we already have. I think you are willfully reading
too much into this.
{quote}
We already have metric types that are called Counter and Gauge
{quote}
As I explained in person (and maybe in the design doc?), the class type is not
the preferred implementation because there are more class types than semantic
types. It's perfectly reasonable to use {{Counter}} to publish a metric that
has {{GAUGE}} semantics, and obviously we already use {{GAUGE}} in both
{{Counter}} and {{Timer}} class. It's pretty clear that we should separate the
implementation classes from the logical model.
{quote}
keep the MetricsProcess logic generic.
{quote}
{{MetricsProcess}} is not generic. It emits a specific format. I'm fine with
shuffling code around, but there's so little it isn't worth a separate
abstraction IMHO.
{quote}
I think we can keep the meaning the existing field Timer.value() (the last
sampled value).
{quote}
As I explained in the doc, this value is not helpful at all. I don't think
there's any point in keeping it.
{quote}
provide Prometheus its required info.
{quote}
Making {{Timer}} a {{COUNTER}} is not specific to Prometheus, it is necessary
to make {{Timer}} values useful at all.
> Prometheus exporter endpoints for metrics
> -----------------------------------------
>
> Key: MESOS-6918
> URL: https://issues.apache.org/jira/browse/MESOS-6918
> Project: Mesos
> Issue Type: Bug
> Components: statistics
> Reporter: James Peach
> Assignee: James Peach
>
> There are a couple of [Prometheus|https://prometheus.io] metrics exporters
> for Mesos, of varying quality. Since the Mesos stats system actually knows
> about statistics data types and semantics, and Mesos has reasonable HTTP
> support we could add Prometheus metrics endpoints to directly expose
> statistics in [Prometheus wire
> format|https://prometheus.io/docs/instrumenting/exposition_formats/],
> removing the need for operators to run separate exporter processes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
