Re: [prometheus-developers] [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Chris Marchbanks]

YES

On Thu, May 28, 2020 at 9:30 pm, Julius Volz  
wrote:

Dear Prometheans,

 proposes to list an 
exporter for Fortigate devices that uses a REST API. Brian's stance 
so far has been to only add exporters for metrics that cannot be 
already produced by another exporter on the list at 
, with the 
intention of focusing community efforts rather than spreading them 
over multiple competing exporters for the same thing.


Since the Fortigate device can also be monitored via SNMP, Brian's 
argument is that the SNMP Exporter 
() already covers this 
use case and a more specialized REST-API-based exporter for Fortigate 
should not be listed. On the other hand, many people feel that SNMP 
is painful to work with, and monitoring via a REST API is much 
preferrable. (Further, and not directly relevant to this vote, the 
Fortigate REST API also reports some information that is not 
available via SNMP (see 
)).


In general I like the guideline of not adding too many competing 
exporters for the same thing to our public integrations list, but I 
believe that it should only be a guideline. I believe that SNMP is 
enough of an operational pain that we should allow exceptions for 
more specific, non-SNMP-based exporters like the linked one. It seems 
that the discussion has been had and is laid out in the issue.


I therefore call a vote for the following proposal:

Allow adding exporters to 
 although the 
devices or applications that they export data for can already be 
monitored via SNMP (and thus via the SNMP Exporter). This proposal 
does not affect other criteria that we may use in deciding whether to 
list an exporter or not.


The vote closes on 2020-06-04 20:30 UTC.

Cheers,
Julius
 --
 You received this message because you are subscribed to the Google 
Groups "Prometheus Developers" group.
 To unsubscribe from this group and stop receiving emails from it, 
send an email to prometheus-developers+unsubscr...@googlegroups.com 
.
 To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YozJK6v%2B9HtYC_n1F7fMH_XPVJqd%2BtU_shAihc70jp%3Dn2g%40mail.gmail.com 
.


--
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/8BP2BQ.G5L7O895A2RZ%40gmail.com.

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Chris Marchbanks]

YES

On Thu, May 28, 2020 at 8:52 pm, Bjoern Rabenstein  
wrote:

Dear Prometheans,

So far, we have recommended Celsius as the base unit for temperatures,
despite Kelvin being the SI unit. That was well justified by the
overwhelming majority of use cases, where Kelvin would be just
weird. I'd really like to see more scientific usage of Prometheus, so
I was never super happy with that recommendation, but since it was
just a recommendation, I could live with it.

Now Matt Layher came up with another, more technical use case: color
temperature. Here, using Celsius would be even weirder. So there is a
case where you clearly do not want to follow the suggestion of the
linter, which is more in line with typical Prometheus use cases than
my arguably somewhat far fetched time series for low-temperature
experiments.

Therefore, Matt suggested to make the metrics linter not complain
about kelvin.

I think this is a clearly defined problem with clear arguments and a
clear disagreement between Brian Brazil on the one side and Matt and
myself on the other side. The appropriate amount of effort has been
spent to find a consensus. All arguments can be found in
 and
 .

I hereby call a vote for the following proposal:

Allow Kelvin as a base unit in certain cases and update our
documented recommendation and the linter code accordingly.


(The changes may take the form of the two PRs out there, but the vote
in about the general idea above, not the implementation detail.)


The vote closes on 2020-06-04 20:00 UTC.
--
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in 

--
You received this message because you are subscribed to the Google 
Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, 
send an email to prometheus-developers+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
.


--
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/SZO2BQ.2RQROSN209B71%40gmail.com.

[prometheus-developers] Re: Changing Prometheus from lazy to rough consensus?

[Richard Hartmann]

The current situation is what I want to avoid with my suggestion.

Short-circuiting discussions directly into votes, potentially after mere
hours, is not healthy for the project long term and likely reflects
frustrations built up over time.

Voting results are also harder to adapt and evolve as they will need new
votes, not just consensus, to change. This might not be a problem in the
two current well-scoped votes at the moment, but it will become one more
and more over time.

While I can understand the underlying motivations for quick voting on ALL
the things I would much prefer to fix the default mechanism, consensus,
over moving to a different one, voting ,as the new default.

On Mon, May 25, 2020, 14:04 Richard Hartmann 
wrote:

> Dear all,
>
> as most of you know, the Prometheus governance[1] has three levels of
> formalized decision making. In increasing order of strength and
> requirements, they are:
> * Consensus
> * Majority vote
> * Supermajority vote
>
>
> The consensus definition is taken from CouchDB[2] and goes deeply into
> its intention to be lightweight and easy to reverse. Yet, a careful
> and literal reading of it enshrines what is factually a veto
> mechanism. Vetos are easy to utter but hard to unblock short of voting
> or an in-between secondary consensus mechanism we have come to call
> "Call for Consensus" on the mailing lists.
>
> In practice, it sometimes feels as if consensus is heavier a process
> than outright voting, an order which goes against the initial
> intention behind our governance.
>
> Contrast this to the IETF definition[3] which is more
> formal, but explicitly acknowledges that "Rough consensus is when all
> issues are addressed, but not necessarily accommodated". IETF has
> decades of experience with highly contentious topics which are,
> sometimes, discussed by directly opposed parties. It's important to
> note that the IETF rough consensus mechanism presumes the existence of
> Chairs, but I think we would not need to rely on such heavyweight
> process.
>
> Personally, I am more used to the IETF definition and have not seen
> the CouchDB version seen wide adoption, which is part of the reason
> why I adopted rough IETF consensus for the Grafana governance[4]
> recently released.
>
> In order to make Prometheus move more quickly and more smoothly, I
> would like to suggest adoption the following change:
>
> https://github.com/prometheus/docs/commit/f7ee6ac5a9b841be6be25d92e2c403de15949491
>
>
> Best,
> Richard
>
> [1] https://prometheus.io/governance/
> [2] https://couchdb.apache.org/bylaws.html#lazy
> [3] https://tools.ietf.org/html/rfc7282
> [4] https://github.com/grafana/grafana/blob/master/GOVERNANCE.md
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAD77%2BgTb6cnjVAJPyCKY9bCpEcKBqB88sT2Vi7fO4nSiVCAbSg%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Richard Hartmann]

YES, based on technical merit.

Please see rough consensus thread for social considerations.

On Thu, May 28, 2020, 21:30 Julius Volz  wrote:

> Dear Prometheans,
>
> https://github.com/prometheus/docs/pull/1640 proposes to list an exporter
> for Fortigate devices that uses a REST API. Brian's stance so far has been
> to only add exporters for metrics that cannot be already produced by
> another exporter on the list at
> https://prometheus.io/docs/instrumenting/exporters/, with the intention
> of focusing community efforts rather than spreading them over multiple
> competing exporters for the same thing.
>
> Since the Fortigate device can also be monitored via SNMP, Brian's
> argument is that the SNMP Exporter (
> https://github.com/prometheus/snmp_exporter) already covers this use case
> and a more specialized REST-API-based exporter for Fortigate should not be
> listed. On the other hand, many people feel that SNMP is painful to work
> with, and monitoring via a REST API is much preferrable. (Further, and not
> directly relevant to this vote, the Fortigate REST API also reports some
> information that is not available via SNMP (see
> https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).
>
> In general I like the guideline of not adding too many competing exporters
> for the same thing to our public integrations list, but I believe that it
> should only be a guideline. I believe that SNMP is enough of an operational
> pain that we should allow exceptions for more specific, non-SNMP-based
> exporters like the linked one. It seems that the discussion has been had
> and is laid out in the issue.
>
> I therefore call a vote for the following proposal:
>
> Allow adding exporters to
> https://prometheus.io/docs/instrumenting/exporters/ although the devices
> or applications that they export data for can already be monitored via SNMP
> (and thus via the SNMP Exporter). This proposal does not affect other
> criteria that we may use in deciding whether to list an exporter or not.
>
> The vote closes on 2020-06-04 20:30 UTC.
>
> Cheers,
> Julius
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YozJK6v%2B9HtYC_n1F7fMH_XPVJqd%2BtU_shAihc70jp%3Dn2g%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAD77%2BgSm8qcaJuBWFaPffxYKqGbJxyq4iVfrugWj3s0jd2BO%2Bg%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Richard Hartmann]

YES, based on technical merit.

Please see rough consensus thread for social considerations.

On Thu, May 28, 2020, 20:52 Bjoern Rabenstein  wrote:

> Dear Prometheans,
>
> So far, we have recommended Celsius as the base unit for temperatures,
> despite Kelvin being the SI unit. That was well justified by the
> overwhelming majority of use cases, where Kelvin would be just
> weird. I'd really like to see more scientific usage of Prometheus, so
> I was never super happy with that recommendation, but since it was
> just a recommendation, I could live with it.
>
> Now Matt Layher came up with another, more technical use case: color
> temperature. Here, using Celsius would be even weirder. So there is a
> case where you clearly do not want to follow the suggestion of the
> linter, which is more in line with typical Prometheus use cases than
> my arguably somewhat far fetched time series for low-temperature
> experiments.
>
> Therefore, Matt suggested to make the metrics linter not complain
> about kelvin.
>
> I think this is a clearly defined problem with clear arguments and a
> clear disagreement between Brian Brazil on the one side and Matt and
> myself on the other side. The appropriate amount of effort has been
> spent to find a consensus. All arguments can be found in
> https://github.com/prometheus/client_golang/pull/761 and
> https://github.com/prometheus/docs/pull/1648 .
>
> I hereby call a vote for the following proposal:
>
> Allow Kelvin as a base unit in certain cases and update our
> documented recommendation and the linter code accordingly.
>
>
> (The changes may take the form of the two PRs out there, but the vote
> in about the general idea above, not the implementation detail.)
>
>
> The vote closes on 2020-06-04 20:00 UTC.
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/20200528185216.GK2326%40jahnn
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAD77%2BgTgyMwB6yO3w885pFZ9ms%2BUxFrh7pW472YBs7%3Dy3h3nDg%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Tobias Schmidt]

YES

On Thu, May 28, 2020 at 8:52 PM Bjoern Rabenstein 
wrote:

> Dear Prometheans,
>
> So far, we have recommended Celsius as the base unit for temperatures,
> despite Kelvin being the SI unit. That was well justified by the
> overwhelming majority of use cases, where Kelvin would be just
> weird. I'd really like to see more scientific usage of Prometheus, so
> I was never super happy with that recommendation, but since it was
> just a recommendation, I could live with it.
>
> Now Matt Layher came up with another, more technical use case: color
> temperature. Here, using Celsius would be even weirder. So there is a
> case where you clearly do not want to follow the suggestion of the
> linter, which is more in line with typical Prometheus use cases than
> my arguably somewhat far fetched time series for low-temperature
> experiments.
>
> Therefore, Matt suggested to make the metrics linter not complain
> about kelvin.
>
> I think this is a clearly defined problem with clear arguments and a
> clear disagreement between Brian Brazil on the one side and Matt and
> myself on the other side. The appropriate amount of effort has been
> spent to find a consensus. All arguments can be found in
> https://github.com/prometheus/client_golang/pull/761 and
> https://github.com/prometheus/docs/pull/1648 .
>
> I hereby call a vote for the following proposal:
>
> Allow Kelvin as a base unit in certain cases and update our
> documented recommendation and the linter code accordingly.
>
>
> (The changes may take the form of the two PRs out there, but the vote
> in about the general idea above, not the implementation detail.)
>
>
> The vote closes on 2020-06-04 20:00 UTC.
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/20200528185216.GK2326%40jahnn
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAChBsdCP210kkrWM6CLYXcY_3Ku%3DjVzLvonFMt796o12YO6-Nw%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Brian Brazil]

On Thu, 28 May 2020 at 19:52, Bjoern Rabenstein  wrote:

> Dear Prometheans,
>
> So far, we have recommended Celsius as the base unit for temperatures,
> despite Kelvin being the SI unit. That was well justified by the
> overwhelming majority of use cases, where Kelvin would be just
> weird. I'd really like to see more scientific usage of Prometheus, so
> I was never super happy with that recommendation, but since it was
> just a recommendation, I could live with it.
>
> Now Matt Layher came up with another, more technical use case: color
> temperature. Here, using Celsius would be even weirder. So there is a
> case where you clearly do not want to follow the suggestion of the
> linter, which is more in line with typical Prometheus use cases than
> my arguably somewhat far fetched time series for low-temperature
> experiments.
>
> Therefore, Matt suggested to make the metrics linter not complain
> about kelvin.
>
> I think this is a clearly defined problem with clear arguments and a
> clear disagreement between Brian Brazil on the one side and Matt and
> myself on the other side. The appropriate amount of effort has been
> spent to find a consensus.


I disagree that sufficient effort has been made to find concensus, and in
particular I don't feel that my objection that this change would have wider
ranging consequences for the best practices of metrics names as a whole has
been addressed.

Jumping so quickly to a vote also makes it difficult to discover if maybe a
concensus could have been found here.
The question has not been asked that if there are valid use cases where an
exception makes sense, does that now mean that the linter must never
complain about that unit as whole?
In case you aren't aware the node exporter exposes the size of the entropy
pool in bits - which I'm okay with along roughly the lines you're arguing
on - but yet the linter does not accept bits.
The linter is a recommendation, not a hard rule that must be followed.

One potential concensus might be around adding the nuance/clarification in
the exporter guidelines where this is covered (it already kinda says it,
but it takes some squinting).

My vote is NO, as I disagree with the linter accepting any more than one
base unit.

Brian

All arguments can be found in
> https://github.com/prometheus/client_golang/pull/761 and
> https://github.com/prometheus/docs/pull/1648 .
>
> I hereby call a vote for the following proposal:
>
> Allow Kelvin as a base unit in certain cases and update our
> documented recommendation and the linter code accordingly.
>
>
> (The changes may take the form of the two PRs out there, but the vote
> in about the general idea above, not the implementation detail.)
>
>
> The vote closes on 2020-06-04 20:00 UTC.
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/20200528185216.GK2326%40jahnn
> .
>


-- 
Brian Brazil
www.robustperception.io

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLopqQ%3Dc_dhjSFG8kC6G4-82nxmEmN1PJGPfs8qRyjjxpw%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Julien Pivotto]

On 28 May 21:53, Brian Brazil wrote:
> On Thu, 28 May 2020 at 20:30, Julius Volz  wrote:
> 
> > Dear Prometheans,
> >
> > https://github.com/prometheus/docs/pull/1640 proposes to list an exporter
> > for Fortigate devices that uses a REST API. Brian's stance so far has been
> > to only add exporters for metrics that cannot be already produced by
> > another exporter on the list at
> > https://prometheus.io/docs/instrumenting/exporters/, with the intention
> > of focusing community efforts rather than spreading them over multiple
> > competing exporters for the same thing.
> >
> > Since the Fortigate device can also be monitored via SNMP, Brian's
> > argument is that the SNMP Exporter (
> > https://github.com/prometheus/snmp_exporter) already covers this use case
> > and a more specialized REST-API-based exporter for Fortigate should not be
> > listed. On the other hand, many people feel that SNMP is painful to work
> > with, and monitoring via a REST API is much preferrable. (Further, and not
> > directly relevant to this vote, the Fortigate REST API also reports some
> > information that is not available via SNMP (see
> > https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).
> >
> > In general I like the guideline of not adding too many competing exporters
> > for the same thing to our public integrations list, but I believe that it
> > should only be a guideline.
> >
> 
> Uhm, it is only a guideline. There's already cases where technically
> overlapping exporters provide sufficient distinct value that both end up
> listed. For example the smokeping exporter duplicates the blackbox
> exporter's ability to do ICMP, but its goals and uses are different enough
> to be worth listing.
> 
> I'd also ask that we take a step back briefly to not focus entirely on
> SNMP. The exporter/integration list and policy around it has developed
> organically over time, and I've tried to keep things internally consistent,
> while also seeking input from others the rare times a unique situation came
> up. So as the list and policy are highly based on precedent, a vote like
> this doesn't just impact on SNMP. It could create precedent making it
> easier to list mild-variant exporters, such as someone not liking the
> language in which the listed exporter is implemented, or how it's
> configured, or adding one minor metric - all of which have come up. This
> would work against the goal of discouraging excess proliferation of
> exporters, and ultimately result in an inferior choice of exporters
> available to users.


At the beginning of the conversation I was also thinking about launching
this vote.

This vote makes it clear that it is about SNMP and the intention seems
to make the SNMP exporter a 'last resort' exporter. I do not see how it
affects the other exporters.

> > I believe that SNMP is enough of an operational pain that we should allow
> > exceptions for more specific, non-SNMP-based exporters like the linked one.
> > It seems that the discussion has been had and is laid out in the issue.
> >
> 
> I am aware of the operational fun of SNMP, but I get a sense that several
> important details in relation to this exporter have been missed due to the
> focus on SNMP-bad.

Not only SNMP is fun but also the MIBS game is really no fun. The
snmp_exporter generator creates a high bar to use the exporter for
specialized mibs.

> As it currently stands the code of this particular exporter has only 7
> metrics, representing a tiny fraction of the metrics that are available
> with the SNMP exporter for these devices. The metrics exposed are covered
> via the SNMP exporter, with only minor improvements (two metrics are now
> split by v4 vs v6). It doesn't cover the most basic of network metrics such
> as bytes transmitted. The cases mentioned in
> https://github.com/prometheus/docs/pull/1640#issuecomment-633303249 where
> this exporter would be better than the snmp exporter are hypothetical as
> they have not been implemented. As such I view it that listing it in its
> current state would be a disservice to our users looking to monitor
> Fortigate devices, and there is precedent for not listing an exporter where
> the metrics it offers are significantly inferior to the alternatives.
> Accordingly if this vote were to go though, I would still not list this
> exporter.

That is no issue. The vote is not about that exporter, and I think that
the PR is going in a bad direction - requesting to add metrics just to
be listed instead of solving actual issues is kinda not what we should
aim at.

> From a quick check, this vote going through would not have affected the
> listing of any previous proposed exporter.
> 
> > Brian's stance so far has been to only add exporters for metrics that
> cannot be already produced by another exporter on the list
> 
> To clarify a little in this case, what I have said is that once the
> exporter has matured more and actually implemented metrics such as those
> mentioned in
> https://github

Re: [prometheus-developers] [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Brian Brazil]

On Thu, 28 May 2020 at 20:30, Julius Volz  wrote:

> Dear Prometheans,
>
> https://github.com/prometheus/docs/pull/1640 proposes to list an exporter
> for Fortigate devices that uses a REST API. Brian's stance so far has been
> to only add exporters for metrics that cannot be already produced by
> another exporter on the list at
> https://prometheus.io/docs/instrumenting/exporters/, with the intention
> of focusing community efforts rather than spreading them over multiple
> competing exporters for the same thing.
>
> Since the Fortigate device can also be monitored via SNMP, Brian's
> argument is that the SNMP Exporter (
> https://github.com/prometheus/snmp_exporter) already covers this use case
> and a more specialized REST-API-based exporter for Fortigate should not be
> listed. On the other hand, many people feel that SNMP is painful to work
> with, and monitoring via a REST API is much preferrable. (Further, and not
> directly relevant to this vote, the Fortigate REST API also reports some
> information that is not available via SNMP (see
> https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).
>
> In general I like the guideline of not adding too many competing exporters
> for the same thing to our public integrations list, but I believe that it
> should only be a guideline.
>

Uhm, it is only a guideline. There's already cases where technically
overlapping exporters provide sufficient distinct value that both end up
listed. For example the smokeping exporter duplicates the blackbox
exporter's ability to do ICMP, but its goals and uses are different enough
to be worth listing.

I'd also ask that we take a step back briefly to not focus entirely on
SNMP. The exporter/integration list and policy around it has developed
organically over time, and I've tried to keep things internally consistent,
while also seeking input from others the rare times a unique situation came
up. So as the list and policy are highly based on precedent, a vote like
this doesn't just impact on SNMP. It could create precedent making it
easier to list mild-variant exporters, such as someone not liking the
language in which the listed exporter is implemented, or how it's
configured, or adding one minor metric - all of which have come up. This
would work against the goal of discouraging excess proliferation of
exporters, and ultimately result in an inferior choice of exporters
available to users.


> I believe that SNMP is enough of an operational pain that we should allow
> exceptions for more specific, non-SNMP-based exporters like the linked one.
> It seems that the discussion has been had and is laid out in the issue.
>

I am aware of the operational fun of SNMP, but I get a sense that several
important details in relation to this exporter have been missed due to the
focus on SNMP-bad.

As it currently stands the code of this particular exporter has only 7
metrics, representing a tiny fraction of the metrics that are available
with the SNMP exporter for these devices. The metrics exposed are covered
via the SNMP exporter, with only minor improvements (two metrics are now
split by v4 vs v6). It doesn't cover the most basic of network metrics such
as bytes transmitted. The cases mentioned in
https://github.com/prometheus/docs/pull/1640#issuecomment-633303249 where
this exporter would be better than the snmp exporter are hypothetical as
they have not been implemented. As such I view it that listing it in its
current state would be a disservice to our users looking to monitor
Fortigate devices, and there is precedent for not listing an exporter where
the metrics it offers are significantly inferior to the alternatives.
Accordingly if this vote were to go though, I would still not list this
exporter.

>From a quick check, this vote going through would not have affected the
listing of any previous proposed exporter.

> Brian's stance so far has been to only add exporters for metrics that
cannot be already produced by another exporter on the list

To clarify a little in this case, what I have said is that once the
exporter has matured more and actually implemented metrics such as those
mentioned in
https://github.com/prometheus/docs/pull/1640#issuecomment-633303249 that a
listing can be reconsidered. I'd also hope to see basic metrics like bytes
transmitted included, so that if a user started using it they'd not be
disappointed and then presume that Prometheus can't monitor Fortigate
devices. That's not to say that it would have to exhaustively implement
everything in MIB, nor that this the only way in which I'd be happy with an
apparent duplicate (unusual circumstances happen after all), but I've yet
to see any arguments that were heading in that direction.

Brian

I therefore call a vote for the following proposal:
>
> Allow adding exporters to
> https://prometheus.io/docs/instrumenting/exporters/ although the devices
> or applications that they export data for can already be monitored via SNMP
> (and thus via the SNM

Re: [prometheus-developers] Re: [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Matt Layher]

YES

On Thursday, May 28, 2020 at 4:18:16 PM UTC-4, Julius Volz wrote:
>
> Since the vote is not about the Governance or team members, but would 
> rather fall under "technical decision", it is automatically a majority 
> vote: https://prometheus.io/governance/#technical-decisions
>
> On Thu, May 28, 2020 at 9:54 PM Bartłomiej Płotka  > wrote:
>
>> Sorry for the spam, but can we make sure to mention* what kind of vote 
>> is it? (*majority/supermajority/yolo)
>>
>> I personally don't have opinion on this topic, but don't want to block 
>> the vote as well.
>>
>> Kind Regards,
>> Bartek
>>
>> On Thu, 28 May 2020 at 20:35, Julius Volz > > wrote:
>>
>>> YES
>>>
>>> On Thu, May 28, 2020 at 9:30 PM Julius Volz >> > wrote:
>>>
 Dear Prometheans,

 https://github.com/prometheus/docs/pull/1640 proposes to list an 
 exporter for Fortigate devices that uses a REST API. Brian's stance so far 
 has been to only add exporters for metrics that cannot be already produced 
 by another exporter on the list at 
 https://prometheus.io/docs/instrumenting/exporters/, with the 
 intention of focusing community efforts rather than spreading them over 
 multiple competing exporters for the same thing.

 Since the Fortigate device can also be monitored via SNMP, Brian's 
 argument is that the SNMP Exporter (
 https://github.com/prometheus/snmp_exporter) already covers this use 
 case and a more specialized REST-API-based exporter for Fortigate should 
 not be listed. On the other hand, many people feel that SNMP is painful to 
 work with, and monitoring via a REST API is much preferrable. (Further, 
 and 
 not directly relevant to this vote, the Fortigate REST API also reports 
 some information that is not available via SNMP (see 
 https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).

 In general I like the guideline of not adding too many competing 
 exporters for the same thing to our public integrations list, but I 
 believe 
 that it should only be a guideline. I believe that SNMP is enough of an 
 operational pain that we should allow exceptions for more specific, 
 non-SNMP-based exporters like the linked one. It seems that the discussion 
 has been had and is laid out in the issue.

 I therefore call a vote for the following proposal:

 Allow adding exporters to 
 https://prometheus.io/docs/instrumenting/exporters/ although the 
 devices or applications that they export data for can already be monitored 
 via SNMP (and thus via the SNMP Exporter). This proposal does not affect 
 other criteria that we may use in deciding whether to list an exporter or 
 not.

 The vote closes on 2020-06-04 20:30 UTC.

 Cheers,
 Julius

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Prometheus Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to prometheus-developers+unsubscr...@googlegroups.com 
>>> .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowGqNyL7DavAaSuEE33DjFziiD6x%3Duc1EPUy6p1aJaH7Q%40mail.gmail.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/185f0308-f41a-4f77-9af4-9a91dd8c7dad%40googlegroups.com.

Re: [prometheus-developers] Re: [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Julius Volz]

Since the vote is not about the Governance or team members, but would
rather fall under "technical decision", it is automatically a majority
vote: https://prometheus.io/governance/#technical-decisions

On Thu, May 28, 2020 at 9:54 PM Bartłomiej Płotka 
wrote:

> Sorry for the spam, but can we make sure to mention* what kind of vote is
> it? (*majority/supermajority/yolo)
>
> I personally don't have opinion on this topic, but don't want to block the
> vote as well.
>
> Kind Regards,
> Bartek
>
> On Thu, 28 May 2020 at 20:35, Julius Volz  wrote:
>
>> YES
>>
>> On Thu, May 28, 2020 at 9:30 PM Julius Volz 
>> wrote:
>>
>>> Dear Prometheans,
>>>
>>> https://github.com/prometheus/docs/pull/1640 proposes to list an
>>> exporter for Fortigate devices that uses a REST API. Brian's stance so far
>>> has been to only add exporters for metrics that cannot be already produced
>>> by another exporter on the list at
>>> https://prometheus.io/docs/instrumenting/exporters/, with the intention
>>> of focusing community efforts rather than spreading them over multiple
>>> competing exporters for the same thing.
>>>
>>> Since the Fortigate device can also be monitored via SNMP, Brian's
>>> argument is that the SNMP Exporter (
>>> https://github.com/prometheus/snmp_exporter) already covers this use
>>> case and a more specialized REST-API-based exporter for Fortigate should
>>> not be listed. On the other hand, many people feel that SNMP is painful to
>>> work with, and monitoring via a REST API is much preferrable. (Further, and
>>> not directly relevant to this vote, the Fortigate REST API also reports
>>> some information that is not available via SNMP (see
>>> https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).
>>>
>>> In general I like the guideline of not adding too many competing
>>> exporters for the same thing to our public integrations list, but I believe
>>> that it should only be a guideline. I believe that SNMP is enough of an
>>> operational pain that we should allow exceptions for more specific,
>>> non-SNMP-based exporters like the linked one. It seems that the discussion
>>> has been had and is laid out in the issue.
>>>
>>> I therefore call a vote for the following proposal:
>>>
>>> Allow adding exporters to
>>> https://prometheus.io/docs/instrumenting/exporters/ although the
>>> devices or applications that they export data for can already be monitored
>>> via SNMP (and thus via the SNMP Exporter). This proposal does not affect
>>> other criteria that we may use in deciding whether to list an exporter or
>>> not.
>>>
>>> The vote closes on 2020-06-04 20:30 UTC.
>>>
>>> Cheers,
>>> Julius
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Prometheus Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to prometheus-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowGqNyL7DavAaSuEE33DjFziiD6x%3Duc1EPUy6p1aJaH7Q%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoxOuUjfkFjQWd2FBbFhEph3GaH8EYWHZ0cmn4V85ofZKg%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Goutham Veeramachaneni]

YES.

As someone who went through the dark art of configuring SNMP exporter from
MIBs and what not, I think not having to run it should even be encouraged :)

On Thu, May 28, 2020 at 9:10 PM Julien Pivotto 
wrote:

> YES
>
> On 28 May 21:30, Julius Volz wrote:
> > Dear Prometheans,
> >
> > https://github.com/prometheus/docs/pull/1640 proposes to list an
> exporter
> > for Fortigate devices that uses a REST API. Brian's stance so far has
> been
> > to only add exporters for metrics that cannot be already produced by
> > another exporter on the list at
> > https://prometheus.io/docs/instrumenting/exporters/, with the intention
> of
> > focusing community efforts rather than spreading them over multiple
> > competing exporters for the same thing.
> >
> > Since the Fortigate device can also be monitored via SNMP, Brian's
> argument
> > is that the SNMP Exporter (https://github.com/prometheus/snmp_exporter)
> > already covers this use case and a more specialized REST-API-based
> exporter
> > for Fortigate should not be listed. On the other hand, many people feel
> > that SNMP is painful to work with, and monitoring via a REST API is much
> > preferrable. (Further, and not directly relevant to this vote, the
> > Fortigate REST API also reports some information that is not available
> via
> > SNMP (see
> > https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).
> >
> > In general I like the guideline of not adding too many competing
> exporters
> > for the same thing to our public integrations list, but I believe that it
> > should only be a guideline. I believe that SNMP is enough of an
> operational
> > pain that we should allow exceptions for more specific, non-SNMP-based
> > exporters like the linked one. It seems that the discussion has been had
> > and is laid out in the issue.
> >
> > I therefore call a vote for the following proposal:
> >
> > Allow adding exporters to
> > https://prometheus.io/docs/instrumenting/exporters/ although the
> devices or
> > applications that they export data for can already be monitored via SNMP
> > (and thus via the SNMP Exporter). This proposal does not affect other
> > criteria that we may use in deciding whether to list an exporter or not.
> >
> > The vote closes on 2020-06-04 20:30 UTC.
> >
> > Cheers,
> > Julius
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Prometheus Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to prometheus-developers+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YozJK6v%2B9HtYC_n1F7fMH_XPVJqd%2BtU_shAihc70jp%3Dn2g%40mail.gmail.com
> .
>
> --
> Julien Pivotto
> @roidelapluie
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/20200528201016.GA1187324%40oxygen
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAKQV3GGYjsEeEsr%3D0jfknQZmPdF%2B%2BgcaQpgxReVEz9CMAZcc-A%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Julien Pivotto]

YES

On 28 May 21:30, Julius Volz wrote:
> Dear Prometheans,
> 
> https://github.com/prometheus/docs/pull/1640 proposes to list an exporter
> for Fortigate devices that uses a REST API. Brian's stance so far has been
> to only add exporters for metrics that cannot be already produced by
> another exporter on the list at
> https://prometheus.io/docs/instrumenting/exporters/, with the intention of
> focusing community efforts rather than spreading them over multiple
> competing exporters for the same thing.
> 
> Since the Fortigate device can also be monitored via SNMP, Brian's argument
> is that the SNMP Exporter (https://github.com/prometheus/snmp_exporter)
> already covers this use case and a more specialized REST-API-based exporter
> for Fortigate should not be listed. On the other hand, many people feel
> that SNMP is painful to work with, and monitoring via a REST API is much
> preferrable. (Further, and not directly relevant to this vote, the
> Fortigate REST API also reports some information that is not available via
> SNMP (see
> https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).
> 
> In general I like the guideline of not adding too many competing exporters
> for the same thing to our public integrations list, but I believe that it
> should only be a guideline. I believe that SNMP is enough of an operational
> pain that we should allow exceptions for more specific, non-SNMP-based
> exporters like the linked one. It seems that the discussion has been had
> and is laid out in the issue.
> 
> I therefore call a vote for the following proposal:
> 
> Allow adding exporters to
> https://prometheus.io/docs/instrumenting/exporters/ although the devices or
> applications that they export data for can already be monitored via SNMP
> (and thus via the SNMP Exporter). This proposal does not affect other
> criteria that we may use in deciding whether to list an exporter or not.
> 
> The vote closes on 2020-06-04 20:30 UTC.
> 
> Cheers,
> Julius
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YozJK6v%2B9HtYC_n1F7fMH_XPVJqd%2BtU_shAihc70jp%3Dn2g%40mail.gmail.com.

-- 
Julien Pivotto
@roidelapluie

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/20200528201016.GA1187324%40oxygen.

Re: [prometheus-developers] Can CollectAndCompare validate range for non-deterministic values e.g. latency?

[Bartłomiej Płotka]

That is a very good question (:

I don't think the current API of client Golang
https://godoc.org/github.com/prometheus/client_golang/prometheus/testutil
package
allows this scenario. It might be good to add GH issue for client_golang
project to explore those possibilities,

In terms of potential API for such util functions, something that I would
recommend here is the e2e framework we use in Thanos like here:
https://github.com/thanos-io/thanos/blob/c733564d44745af1a023bfa5d51d6d205404dc82/test/e2e/compact_test.go#L556
This
is actually maintained in Cortex repository, and it's something we use,
maintain and recommend, especially if you want to test against container
environment.

There is also a possibility to pull out this code to operate on raw text
files, and put into client_golang, this API might work. Note that Peter
also is working on something even better: PromQL based unit test on metric
text file!  (: Quite
amazing stuff, something to consider as well.

Kind Regards,
Bartek


On Thu, 28 May 2020 at 19:59, 'Michael Rybak' via Prometheus Developers <
prometheus-developers@googlegroups.com> wrote:

> *TL;DR: I'm unit-testing Prometheus metrics: server's requests count and
> latencies. The server is written in Go. Latencies are non-determinstic and
> there seems to be no good way to fake clock in Prometheus or Go. Does
> Prometheus provide a method similar to CollectAndCompare that lets
> validating a value (e.g. latency) against a range, not exact expectation?
> If not, would it be a good feature to add to Prometheus? Alternatively, is
> there a way to fake clock in Prometheus, so
> e.g. InstrumentHandlerDuration would propagate the pre-defined fake
> duration? Or, is there a good way to fake clock in Go?*
>
> I'm measuring server's requests count (Counter) and latencies (Summary),
> and test both with unit tests. I observe the metrics via
> InstrumentHandlerCounter and InstrumentHandlerDuration respectively.
>
> For testing requests count, I hardcode the expectation in a string
> constant, and use CollectAndCompare to perform an exact match validation:
>
> // Make some test requests.
> ..
>
> // Validate them
> expectation := strings.NewReader(`
> # HELP my_metric_requests_total My help.
> # TYPE my_metric_requests_total counter
> my_metric_requests_total{code="200"} 2
> my_metric_requests_total{code="304"} 1
> my_metric_requests_total{code="502"} 1
> my_metric_requests_total{code="503"} 1
> `)
>
> this.Require().NoError(promtest.CollectAndCompare(myMetricRequestsTotal,
> expectation, "my_metric_requests_total"))
>
> I couldn't find a way to do the same for latencies, because they are
> non-deterministic. So instead of the one-liner check above I dig into the
> internals of the gathered metrics:
>
> // Make some test requests.
> hintPrefix := "My test."
> ...
>
> // Validate them
> type codeLabelPair string
> type scenarioExpectedSampleCountMap map[codeLabelPair]uint64
>
> expectedSampleCountMap := scenarioExpectedSampleCountMap{
> `name:"code" value:"200" `: 3,
> `name:"code" value:"304" `: 1,
> `name:"code" value:"502" `: 2,
> }
>
> reg := prometheus.NewPedanticRegistry()
> if err := reg.Register(promRequestsLatency); err != nil {
> this.T().Errorf(hintPrefix+" - registering collector failed: %s", err)
> }
>
> actualMetricFamilyArr, err := reg.Gather()
> if err != nil {
> this.T().Errorf(hintPrefix+" - gathering metrics failed: %s", err)
> }
>
> assert.Equal(this.T(), 1, len(actualMetricFamilyArr),
> hintPrefix+" expects exactly one metric family.")
>
> assert.Equal(this.T(), "request_latencies_in_seconds",
> *actualMetricFamilyArr[0].Name,
> hintPrefix+" expects the right metric name.")
>
> assert.Equal(this.T(), len(expectedSampleCountMap),
> len(actualMetricFamilyArr[0].Metric),
> hintPrefix+" expects the right amount of metrics collected and gathered.")
>
> for _, actualMetric := range actualMetricFamilyArr[0].Metric {
> // Expect the right sample count.
> code := actualMetric.Label[0].String()
> expectedSampleCount := expectedSampleCountMap[codeLabelPair(code)]
> actualSampleCount := actualMetric.Summary.GetSampleCount()
> assert.Equal(this.T(), expectedSampleCount, actualSampleCount,
> hintPrefix+" expects the right sample count for "+code)
>
> // Test quantiles.
> expectedQuantileKeys := []float64{0.5, 0.9, 0.99}
>
> // Expect the right number of quantiles.
> assert.Equal(this.T(), len(expectedQuantileKeys),
> len(actualMetric.Summary.Quantile), hintPrefix+" expects the right number
> of quantiles.")
>
> // Expect the right quantiles.
> // Expect positive quantile values, because latencies are non-zero.
> // Don't check the exact values, because latencies are non-deterministic.
> for i, quantile := range actualMetric.Summary.Quantile {
> assert.Equal(this.T(), expectedQuantileKeys[i], quantile.GetQuantile(),
> hintPrefix+" expects the right quantile.")
> assert.True(this.T(), quantile.GetValue() > .0, hintPrefix+" expects
> non-zero quanti

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Julien Pivotto]

YES


Should we recommend kelvin instead of celcius in histograms and
summaries as there would not be negative observations ?
https://github.com/prometheus/prometheus/issues/6669

On 28 May 20:52, Bjoern Rabenstein wrote:
> Dear Prometheans,
> 
> So far, we have recommended Celsius as the base unit for temperatures,
> despite Kelvin being the SI unit. That was well justified by the
> overwhelming majority of use cases, where Kelvin would be just
> weird. I'd really like to see more scientific usage of Prometheus, so
> I was never super happy with that recommendation, but since it was
> just a recommendation, I could live with it.
> 
> Now Matt Layher came up with another, more technical use case: color
> temperature. Here, using Celsius would be even weirder. So there is a
> case where you clearly do not want to follow the suggestion of the
> linter, which is more in line with typical Prometheus use cases than
> my arguably somewhat far fetched time series for low-temperature
> experiments.
> 
> Therefore, Matt suggested to make the metrics linter not complain
> about kelvin.
> 
> I think this is a clearly defined problem with clear arguments and a
> clear disagreement between Brian Brazil on the one side and Matt and
> myself on the other side. The appropriate amount of effort has been
> spent to find a consensus. All arguments can be found in
> https://github.com/prometheus/client_golang/pull/761 and
> https://github.com/prometheus/docs/pull/1648 .
> 
> I hereby call a vote for the following proposal:
> 
> Allow Kelvin as a base unit in certain cases and update our
> documented recommendation and the linter code accordingly.
> 
> 
> (The changes may take the form of the two PRs out there, but the vote
> in about the general idea above, not the implementation detail.)
> 
> 
> The vote closes on 2020-06-04 20:00 UTC.
> -- 
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/prometheus-developers/20200528185216.GK2326%40jahnn.

-- 
Julien Pivotto
@roidelapluie

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/20200528195925.GA1159444%40oxygen.

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Callum Styan]

YES

On Thu, May 28, 2020 at 11:52 AM Bjoern Rabenstein 
wrote:

> Dear Prometheans,
>
> So far, we have recommended Celsius as the base unit for temperatures,
> despite Kelvin being the SI unit. That was well justified by the
> overwhelming majority of use cases, where Kelvin would be just
> weird. I'd really like to see more scientific usage of Prometheus, so
> I was never super happy with that recommendation, but since it was
> just a recommendation, I could live with it.
>
> Now Matt Layher came up with another, more technical use case: color
> temperature. Here, using Celsius would be even weirder. So there is a
> case where you clearly do not want to follow the suggestion of the
> linter, which is more in line with typical Prometheus use cases than
> my arguably somewhat far fetched time series for low-temperature
> experiments.
>
> Therefore, Matt suggested to make the metrics linter not complain
> about kelvin.
>
> I think this is a clearly defined problem with clear arguments and a
> clear disagreement between Brian Brazil on the one side and Matt and
> myself on the other side. The appropriate amount of effort has been
> spent to find a consensus. All arguments can be found in
> https://github.com/prometheus/client_golang/pull/761 and
> https://github.com/prometheus/docs/pull/1648 .
>
> I hereby call a vote for the following proposal:
>
> Allow Kelvin as a base unit in certain cases and update our
> documented recommendation and the linter code accordingly.
>
>
> (The changes may take the form of the two PRs out there, but the vote
> in about the general idea above, not the implementation detail.)
>
>
> The vote closes on 2020-06-04 20:00 UTC.
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/20200528185216.GK2326%40jahnn
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAN2d5ORc0WoNd43Gp0VkJUMowuoJW4oC2FHGj%2B5o201CsC%3DpiA%40mail.gmail.com.

Re: [prometheus-developers] Re: [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Bartłomiej Płotka]

Sorry for the spam, but can we make sure to mention* what kind of vote is
it? (*majority/supermajority/yolo)

I personally don't have opinion on this topic, but don't want to block the
vote as well.

Kind Regards,
Bartek

On Thu, 28 May 2020 at 20:35, Julius Volz  wrote:

> YES
>
> On Thu, May 28, 2020 at 9:30 PM Julius Volz  wrote:
>
>> Dear Prometheans,
>>
>> https://github.com/prometheus/docs/pull/1640 proposes to list an
>> exporter for Fortigate devices that uses a REST API. Brian's stance so far
>> has been to only add exporters for metrics that cannot be already produced
>> by another exporter on the list at
>> https://prometheus.io/docs/instrumenting/exporters/, with the intention
>> of focusing community efforts rather than spreading them over multiple
>> competing exporters for the same thing.
>>
>> Since the Fortigate device can also be monitored via SNMP, Brian's
>> argument is that the SNMP Exporter (
>> https://github.com/prometheus/snmp_exporter) already covers this use
>> case and a more specialized REST-API-based exporter for Fortigate should
>> not be listed. On the other hand, many people feel that SNMP is painful to
>> work with, and monitoring via a REST API is much preferrable. (Further, and
>> not directly relevant to this vote, the Fortigate REST API also reports
>> some information that is not available via SNMP (see
>> https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).
>>
>> In general I like the guideline of not adding too many competing
>> exporters for the same thing to our public integrations list, but I believe
>> that it should only be a guideline. I believe that SNMP is enough of an
>> operational pain that we should allow exceptions for more specific,
>> non-SNMP-based exporters like the linked one. It seems that the discussion
>> has been had and is laid out in the issue.
>>
>> I therefore call a vote for the following proposal:
>>
>> Allow adding exporters to
>> https://prometheus.io/docs/instrumenting/exporters/ although the devices
>> or applications that they export data for can already be monitored via SNMP
>> (and thus via the SNMP Exporter). This proposal does not affect other
>> criteria that we may use in deciding whether to list an exporter or not.
>>
>> The vote closes on 2020-06-04 20:30 UTC.
>>
>> Cheers,
>> Julius
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowGqNyL7DavAaSuEE33DjFziiD6x%3Duc1EPUy6p1aJaH7Q%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAMssQwaDFY4jegQZf8GwAK5oZH05TyyzusdKwWp4GKfVLNqt6g%40mail.gmail.com.

[prometheus-developers] Re: [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Julius Volz]

YES

On Thu, May 28, 2020 at 9:30 PM Julius Volz  wrote:

> Dear Prometheans,
>
> https://github.com/prometheus/docs/pull/1640 proposes to list an exporter
> for Fortigate devices that uses a REST API. Brian's stance so far has been
> to only add exporters for metrics that cannot be already produced by
> another exporter on the list at
> https://prometheus.io/docs/instrumenting/exporters/, with the intention
> of focusing community efforts rather than spreading them over multiple
> competing exporters for the same thing.
>
> Since the Fortigate device can also be monitored via SNMP, Brian's
> argument is that the SNMP Exporter (
> https://github.com/prometheus/snmp_exporter) already covers this use case
> and a more specialized REST-API-based exporter for Fortigate should not be
> listed. On the other hand, many people feel that SNMP is painful to work
> with, and monitoring via a REST API is much preferrable. (Further, and not
> directly relevant to this vote, the Fortigate REST API also reports some
> information that is not available via SNMP (see
> https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).
>
> In general I like the guideline of not adding too many competing exporters
> for the same thing to our public integrations list, but I believe that it
> should only be a guideline. I believe that SNMP is enough of an operational
> pain that we should allow exceptions for more specific, non-SNMP-based
> exporters like the linked one. It seems that the discussion has been had
> and is laid out in the issue.
>
> I therefore call a vote for the following proposal:
>
> Allow adding exporters to
> https://prometheus.io/docs/instrumenting/exporters/ although the devices
> or applications that they export data for can already be monitored via SNMP
> (and thus via the SNMP Exporter). This proposal does not affect other
> criteria that we may use in deciding whether to list an exporter or not.
>
> The vote closes on 2020-06-04 20:30 UTC.
>
> Cheers,
> Julius
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowGqNyL7DavAaSuEE33DjFziiD6x%3Duc1EPUy6p1aJaH7Q%40mail.gmail.com.

[prometheus-developers] [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

[Julius Volz]

Dear Prometheans,

https://github.com/prometheus/docs/pull/1640 proposes to list an exporter
for Fortigate devices that uses a REST API. Brian's stance so far has been
to only add exporters for metrics that cannot be already produced by
another exporter on the list at
https://prometheus.io/docs/instrumenting/exporters/, with the intention of
focusing community efforts rather than spreading them over multiple
competing exporters for the same thing.

Since the Fortigate device can also be monitored via SNMP, Brian's argument
is that the SNMP Exporter (https://github.com/prometheus/snmp_exporter)
already covers this use case and a more specialized REST-API-based exporter
for Fortigate should not be listed. On the other hand, many people feel
that SNMP is painful to work with, and monitoring via a REST API is much
preferrable. (Further, and not directly relevant to this vote, the
Fortigate REST API also reports some information that is not available via
SNMP (see
https://github.com/prometheus/docs/pull/1640#issuecomment-633303249)).

In general I like the guideline of not adding too many competing exporters
for the same thing to our public integrations list, but I believe that it
should only be a guideline. I believe that SNMP is enough of an operational
pain that we should allow exceptions for more specific, non-SNMP-based
exporters like the linked one. It seems that the discussion has been had
and is laid out in the issue.

I therefore call a vote for the following proposal:

Allow adding exporters to
https://prometheus.io/docs/instrumenting/exporters/ although the devices or
applications that they export data for can already be monitored via SNMP
(and thus via the SNMP Exporter). This proposal does not affect other
criteria that we may use in deciding whether to list an exporter or not.

The vote closes on 2020-06-04 20:30 UTC.

Cheers,
Julius

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YozJK6v%2B9HtYC_n1F7fMH_XPVJqd%2BtU_shAihc70jp%3Dn2g%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Julius Volz]

YES

After reading the arguments, I agree that Kelvin / temperature is special
enough to warrant an exception.

Overall I think it's good that we have rules like "base units only", but
it's ok to have occasional exceptions if enough people think it's worth it.

On Thu, May 28, 2020 at 8:52 PM Bjoern Rabenstein 
wrote:

> Dear Prometheans,
>
> So far, we have recommended Celsius as the base unit for temperatures,
> despite Kelvin being the SI unit. That was well justified by the
> overwhelming majority of use cases, where Kelvin would be just
> weird. I'd really like to see more scientific usage of Prometheus, so
> I was never super happy with that recommendation, but since it was
> just a recommendation, I could live with it.
>
> Now Matt Layher came up with another, more technical use case: color
> temperature. Here, using Celsius would be even weirder. So there is a
> case where you clearly do not want to follow the suggestion of the
> linter, which is more in line with typical Prometheus use cases than
> my arguably somewhat far fetched time series for low-temperature
> experiments.
>
> Therefore, Matt suggested to make the metrics linter not complain
> about kelvin.
>
> I think this is a clearly defined problem with clear arguments and a
> clear disagreement between Brian Brazil on the one side and Matt and
> myself on the other side. The appropriate amount of effort has been
> spent to find a consensus. All arguments can be found in
> https://github.com/prometheus/client_golang/pull/761 and
> https://github.com/prometheus/docs/pull/1648 .
>
> I hereby call a vote for the following proposal:
>
> Allow Kelvin as a base unit in certain cases and update our
> documented recommendation and the linter code accordingly.
>
>
> (The changes may take the form of the two PRs out there, but the vote
> in about the general idea above, not the implementation detail.)
>
>
> The vote closes on 2020-06-04 20:00 UTC.
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/20200528185216.GK2326%40jahnn
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowrQGJt9GVs8VCPdJTOL8MbuRjM4zzT5skD%3DVzBiKJnkg%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Bjoern Rabenstein]

On 28.05.20 20:52, Bjoern Rabenstein wrote:
> 
> I hereby call a vote for the following proposal:
> 
> Allow Kelvin as a base unit in certain cases and update our
> documented recommendation and the linter code accordingly.

YES

-- 
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/20200528190131.GL2326%40jahnn.


signature.asc
Description: Digital signature

[prometheus-developers] Can CollectAndCompare validate range for non-deterministic values e.g. latency?

['Michael Rybak' via Prometheus Developers]

*TL;DR: I'm unit-testing Prometheus metrics: server's requests count and 
latencies. The server is written in Go. Latencies are non-determinstic and 
there seems to be no good way to fake clock in Prometheus or Go. Does 
Prometheus provide a method similar to CollectAndCompare that lets 
validating a value (e.g. latency) against a range, not exact expectation? 
If not, would it be a good feature to add to Prometheus? Alternatively, is 
there a way to fake clock in Prometheus, so 
e.g. InstrumentHandlerDuration would propagate the pre-defined fake 
duration? Or, is there a good way to fake clock in Go?*

I'm measuring server's requests count (Counter) and latencies (Summary), 
and test both with unit tests. I observe the metrics via 
InstrumentHandlerCounter and InstrumentHandlerDuration respectively.

For testing requests count, I hardcode the expectation in a string 
constant, and use CollectAndCompare to perform an exact match validation:

// Make some test requests.
..

// Validate them
expectation := strings.NewReader(`
# HELP my_metric_requests_total My help.
# TYPE my_metric_requests_total counter
my_metric_requests_total{code="200"} 2
my_metric_requests_total{code="304"} 1
my_metric_requests_total{code="502"} 1
my_metric_requests_total{code="503"} 1
`)

this.Require().NoError(promtest.CollectAndCompare(myMetricRequestsTotal, 
expectation, "my_metric_requests_total"))

I couldn't find a way to do the same for latencies, because they are 
non-deterministic. So instead of the one-liner check above I dig into the 
internals of the gathered metrics:

// Make some test requests. 
hintPrefix := "My test."
...

// Validate them
type codeLabelPair string
type scenarioExpectedSampleCountMap map[codeLabelPair]uint64

expectedSampleCountMap := scenarioExpectedSampleCountMap{
`name:"code" value:"200" `: 3,
`name:"code" value:"304" `: 1,
`name:"code" value:"502" `: 2,
}

reg := prometheus.NewPedanticRegistry()
if err := reg.Register(promRequestsLatency); err != nil {
this.T().Errorf(hintPrefix+" - registering collector failed: %s", err)
}

actualMetricFamilyArr, err := reg.Gather()
if err != nil {
this.T().Errorf(hintPrefix+" - gathering metrics failed: %s", err)
}

assert.Equal(this.T(), 1, len(actualMetricFamilyArr),
hintPrefix+" expects exactly one metric family.")

assert.Equal(this.T(), "request_latencies_in_seconds", 
*actualMetricFamilyArr[0].Name,
hintPrefix+" expects the right metric name.")

assert.Equal(this.T(), len(expectedSampleCountMap), 
len(actualMetricFamilyArr[0].Metric),
hintPrefix+" expects the right amount of metrics collected and gathered.")

for _, actualMetric := range actualMetricFamilyArr[0].Metric {
// Expect the right sample count.
code := actualMetric.Label[0].String()
expectedSampleCount := expectedSampleCountMap[codeLabelPair(code)]
actualSampleCount := actualMetric.Summary.GetSampleCount()
assert.Equal(this.T(), expectedSampleCount, actualSampleCount, hintPrefix+" 
expects the right sample count for "+code)

// Test quantiles.
expectedQuantileKeys := []float64{0.5, 0.9, 0.99}

// Expect the right number of quantiles.
assert.Equal(this.T(), len(expectedQuantileKeys), 
len(actualMetric.Summary.Quantile), hintPrefix+" expects the right number 
of quantiles.")

// Expect the right quantiles.
// Expect positive quantile values, because latencies are non-zero.
// Don't check the exact values, because latencies are non-deterministic.
for i, quantile := range actualMetric.Summary.Quantile {
assert.Equal(this.T(), expectedQuantileKeys[i], quantile.GetQuantile(), 
hintPrefix+" expects the right quantile.")
assert.True(this.T(), quantile.GetValue() > .0, hintPrefix+" expects 
non-zero quantile value (latency).")
}
}

This seems to be more complex than it should be. Is there a one-liner way, 
similar to the CollectAndCompare call I'm making above to validate requests 
count? 

Alternatively, is there a way to fake clock in Prometheus, so e.g. 
InstrumentHandlerDuration would propagate the pre-defined fake duration? 
Or, is there a good way to fake clock in Go? There is an option that 
doesn't look safe enough:

https://www.reddit.com/r/golang/comments/30try1/monkey_patching_in_go/
https://news.ycombinator.com/item?id=22442170.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/b440c496-cfb1-4b5f-8fb5-11ca47485a3cn%40googlegroups.com.

[prometheus-developers] Re: [VOTE] Allow Kelvin as temperature unit in some cases

[Matt Layher]

YES

As the original author of the linting code, I think this particular case is 
too nuanced to enforce a "must convert Kelvin to Celsius" recommendation 
for all cases in the linter.

On Thursday, May 28, 2020 at 2:52:19 PM UTC-4, Björn Rabenstein wrote:
>
> Dear Prometheans, 
>
> So far, we have recommended Celsius as the base unit for temperatures, 
> despite Kelvin being the SI unit. That was well justified by the 
> overwhelming majority of use cases, where Kelvin would be just 
> weird. I'd really like to see more scientific usage of Prometheus, so 
> I was never super happy with that recommendation, but since it was 
> just a recommendation, I could live with it. 
>
> Now Matt Layher came up with another, more technical use case: color 
> temperature. Here, using Celsius would be even weirder. So there is a 
> case where you clearly do not want to follow the suggestion of the 
> linter, which is more in line with typical Prometheus use cases than 
> my arguably somewhat far fetched time series for low-temperature 
> experiments. 
>
> Therefore, Matt suggested to make the metrics linter not complain 
> about kelvin. 
>
> I think this is a clearly defined problem with clear arguments and a 
> clear disagreement between Brian Brazil on the one side and Matt and 
> myself on the other side. The appropriate amount of effort has been 
> spent to find a consensus. All arguments can be found in 
> https://github.com/prometheus/client_golang/pull/761 and 
> https://github.com/prometheus/docs/pull/1648 . 
>
> I hereby call a vote for the following proposal: 
>
> Allow Kelvin as a base unit in certain cases and update our 
> documented recommendation and the linter code accordingly. 
>
>
> (The changes may take the form of the two PRs out there, but the vote 
> in about the general idea above, not the implementation detail.) 
>
>
> The vote closes on 2020-06-04 20:00 UTC. 
> -- 
> Björn Rabenstein 
> [PGP-ID] 0x851C3DA17D748D03 
> [email] bjo...@rabenste.in  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/4a05da5d-a40d-4f4a-9ba0-14d5c7eaae4c%40googlegroups.com.

[prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Bjoern Rabenstein]

Dear Prometheans,

So far, we have recommended Celsius as the base unit for temperatures,
despite Kelvin being the SI unit. That was well justified by the
overwhelming majority of use cases, where Kelvin would be just
weird. I'd really like to see more scientific usage of Prometheus, so
I was never super happy with that recommendation, but since it was
just a recommendation, I could live with it.

Now Matt Layher came up with another, more technical use case: color
temperature. Here, using Celsius would be even weirder. So there is a
case where you clearly do not want to follow the suggestion of the
linter, which is more in line with typical Prometheus use cases than
my arguably somewhat far fetched time series for low-temperature
experiments.

Therefore, Matt suggested to make the metrics linter not complain
about kelvin.

I think this is a clearly defined problem with clear arguments and a
clear disagreement between Brian Brazil on the one side and Matt and
myself on the other side. The appropriate amount of effort has been
spent to find a consensus. All arguments can be found in
https://github.com/prometheus/client_golang/pull/761 and
https://github.com/prometheus/docs/pull/1648 .

I hereby call a vote for the following proposal:

Allow Kelvin as a base unit in certain cases and update our
documented recommendation and the linter code accordingly.


(The changes may take the form of the two PRs out there, but the vote
in about the general idea above, not the implementation detail.)


The vote closes on 2020-06-04 20:00 UTC.
-- 
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/20200528185216.GK2326%40jahnn.

[prometheus-developers] Backfill Old Prometheus data from one prometheus server to another

[Vishwajeet Singh]

Hi Team,

We are running two prometheus servers with parallel insertions (remote 
write) to achieve HA. I want to backfill the prometheus data in case my one 
node goes down. Can u pls help me how to achieve this? Please let me know 
with any custom golang code or any other way.

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/c60ad946-9783-4135-aaaf-d09a2a33f0de%40googlegroups.com.

Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?

[Vishwajeet Singh]

  Hi Team,

We are running two prometheus servers with parallel insertions to
achieve HA. I want to backfill the prometheus data in case my one node goes
down. Can u pls help me how to achieve this? Please let me know with any
custom golang code or any other way.

On Mon, May 25, 2020 at 5:34 PM Richard Hartmann <
richih.mailingl...@gmail.com> wrote:

> Dear all,
>
> as most of you know, the Prometheus governance[1] has three levels of
> formalized decision making. In increasing order of strength and
> requirements, they are:
> * Consensus
> * Majority vote
> * Supermajority vote
>
>
> The consensus definition is taken from CouchDB[2] and goes deeply into
> its intention to be lightweight and easy to reverse. Yet, a careful
> and literal reading of it enshrines what is factually a veto
> mechanism. Vetos are easy to utter but hard to unblock short of voting
> or an in-between secondary consensus mechanism we have come to call
> "Call for Consensus" on the mailing lists.
>
> In practice, it sometimes feels as if consensus is heavier a process
> than outright voting, an order which goes against the initial
> intention behind our governance.
>
> Contrast this to the IETF definition[3] which is more
> formal, but explicitly acknowledges that "Rough consensus is when all
> issues are addressed, but not necessarily accommodated". IETF has
> decades of experience with highly contentious topics which are,
> sometimes, discussed by directly opposed parties. It's important to
> note that the IETF rough consensus mechanism presumes the existence of
> Chairs, but I think we would not need to rely on such heavyweight
> process.
>
> Personally, I am more used to the IETF definition and have not seen
> the CouchDB version seen wide adoption, which is part of the reason
> why I adopted rough IETF consensus for the Grafana governance[4]
> recently released.
>
> In order to make Prometheus move more quickly and more smoothly, I
> would like to suggest adoption the following change:
>
> https://github.com/prometheus/docs/commit/f7ee6ac5a9b841be6be25d92e2c403de15949491
>
>
> Best,
> Richard
>
> [1] https://prometheus.io/governance/
> [2] https://couchdb.apache.org/bylaws.html#lazy
> [3] https://tools.ietf.org/html/rfc7282
> [4] https://github.com/grafana/grafana/blob/master/GOVERNANCE.md
>
> --
> You received this message because you are subscribed to the Google Groups
> "Prometheus Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to prometheus-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CAD77%2BgRvwnU%2BdFRMQ2n%2Bqf6D0oyej-btzsQYh8LjBV9FJ1a78w%40mail.gmail.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAKVrrVkXUpXGGNZW0JyHPR%2BOEbHu7kNMSgNZgdB94qspPYFD5Q%40mail.gmail.com.