[
https://issues.apache.org/jira/browse/MESOS-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194161#comment-16194161
]
Yan Xu commented on MESOS-6918:
-------------------------------
[~bmahler] let's chat about the reviews? [[email protected]] and I have
already discussed this offline and I have added comments to the design doc and
the reviews. Here's the summary:
- I am not convinced about the newly introduced {{enum Semantics \{COUNTER,
GAUGE\}}}. We already have metric *types* that are called {{Counter}} and
{{Gauge}} and I think people could be confused about Counter the semantics and
Counter the type, for example.
-- I understand that the semantics is supposed to help express:
bq. {{Timer}}'s value should be cumulative / monotonically increasing
(because it's more useful that way, as explained in the design doc) but this
enum seems to try to suggest that all metric types (potentially future ones as
well) can and should be classified into one of the two buckets. 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? To me
{{s/Semantics/Monotonicity/}} would have been clearer but I am not sure about
the usefulness of that either.
-- The use of this enum right now is just to pass the metric type info down to
the Prometheus formatter. We can just define {{enum Type \{COUNTER, GAUGE,
TIMER\}}} and pass it down.
- I hope we confine the Prometheus logic in a
`metrics/formatters/prometheus.hpp|cpp` file and keep the {{MetricsProcess}}
logic generic.
- I think we can keep the meaning the existing field {{Timer.value()}} (the
last sampled value). We can add a new field {{sum}} in the {{TimeSeries}}
alongside the new {{total}} (can we name it something like {{totalCount}}?) to
provide Prometheus its required info.
> 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)
