You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Yan Xu (JIRA)" <ji...@apache.org> on 2017/10/06 05:25:00 UTC

[jira] [Commented] (MESOS-6918) Prometheus exporter endpoints for metrics

    [ 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? [~jpeach@apache.org] 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)