[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

[Julius Volz]

YES

[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

--
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-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowGqNyL7DavAaSuEE33DjFziiD6x%3Duc1EPUy6p1aJaH7Q%40mail.gmail.com.

[Julien Pivotto]

YES

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

[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 :)

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200528201016.GA1187324%40oxygen.

[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

[Matt Layher]

YES

To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.

[Brian Brazil]

On Thu, 28 May 2020 at 20:30, Julius Volz <juliu...@gmail.com> 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 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-devel...@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.

--

Brian Brazil

www.robustperception.io

[Julien Pivotto]

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.

> > <https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YozJK6v%2B9HtYC_n1F7fMH_XPVJqd%2BtU_shAihc70jp%3Dn2g%40mail.gmail.com?utm_medium=email&utm_source=footer>
> > .
> >
>
>
> --
> 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-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLoAi36ffaSAjv71351n%2BAUofFVqrihYQ_ZN93KE-8%3D56A%40mail.gmail.com.

--
Julien Pivotto
@roidelapluie

[Richard Hartmann]

YES, based on technical merit.

Please see rough consensus thread for social considerations.

--

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

[Chris Marchbanks]

YES

--

[Ben Kochie]

YES

On Thu, May 28, 2020 at 9:30 PM Julius Volz <juliu...@gmail.com> wrote:

--

[Tom Wilkie]

YES

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CABbyFmr2e%3DuUhsjPCP6VBLnDUXWMNBv5V68Kou5PAXpKcE32QQ%40mail.gmail.com.

[Julius Volz]

On Thu, May 28, 2020 at 10:53 PM Brian Brazil <brian....@robustperception.io> wrote:

On Thu, 28 May 2020 at 20:30, Julius Volz <juliu...@gmail.com> 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.

That's good. And yeah, would be weird if we didn't list it, since it does a fundamentally different thing although it's also using ICMP.

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.

The current vote is specifically about SNMP, because it's super painful. There might be other cases where we disagree on when to add an exporter or not, but I have a feeling that everyone agrees on the general stance of not adding duplicate exporters with just minor differences, so I'm not worried about that.

 

 

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.

This is a matter of judgement where we might just disagree. I would still be in favor of adding the exporter even in an early state simply because it's so much easier to use than SNMP, and also because I trust Christian to extend it over time. It would also be possible to choose a middle way of asking the exporter's README.md to state something along the lines of "This exporter is in early development, if you want metrics X, Y, Z, please use the SNMP Exporter for now.".

 

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.

I would say a similar comment as above - your requirements for listing here would be stricter than mine. Maybe that is another thing we have to vote on at some point.

[Brian Brazil]

On Fri, 29 May 2020 at 11:24, Julius Volz <juliu...@gmail.com> wrote:

On Thu, May 28, 2020 at 10:53 PM Brian Brazil <brian....@robustperception.io> wrote:

On Thu, 28 May 2020 at 20:30, Julius Volz <juliu...@gmail.com> 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.

That's good. And yeah, would be weird if we didn't list it, since it does a fundamentally different thing although it's also using ICMP.

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.

The current vote is specifically about SNMP, because it's super painful. There might be other cases where we disagree on when to add an exporter or not, but I have a feeling that everyone agrees on the general stance of not adding duplicate exporters with just minor differences, so I'm not worried about that.

Some uses of SNMP with some devices is super painful. With some devices it works fine, and that includes full-on enterprise use cases. Naturally we only tend to hear from the former, so a blanket policy for an entire protocol could end up being counter-productive.

 

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.

This is a matter of judgement where we might just disagree. I would still be in favor of adding the exporter even in an early state simply because it's so much easier to use than SNMP, and also because I trust Christian to extend it over time.

I'm wary of an easy to use bar, as that is likely to be quite cheeseable. To borrow a term from another thread, many of the arguments presented for duplicate exporters in the past could be boiled down to that the existing exporter was "unappealing" in some way. On the other hand if an apparent duplicate has made a good honest attempt to engage with the existing exporter and can discuss the issues and tradeoffs they went through, I'm going to be more receptive to arguments that the exporter is doing something significant enough to warrant listing.

It would also be possible to choose a middle way of asking the exporter's README.md to state something along the lines of "This exporter is in early development, if you want metrics X, Y, Z, please use the SNMP Exporter for now.".

I see that as a separate thing, which I was going to consider anyway. That is something I've requested in the past where it made sense, for example the readme for the Kafka exporter points to the JMX exporter as the Kafka exporter is a kube-state-metrics thingy.

 

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.

I would say a similar comment as above - your requirements for listing here would be stricter than mine.

Note that this is my thought process because it is a duplicate, and because that's in line with the precedent (and I was not the only one involved in setting that particular precedent). I have previously accepted listings for exporters with fewer metrics, though such proposals are rare.

Maybe that is another thing we have to vote on at some point.

I'd much prefer that we have a discussion rather than a vote. A yes/no vote like this on such a specific question makes it hard to infer a spirit and intention which could then be applied to other cases.

Brian

 

 

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

--

Brian Brazil

www.robustperception.io

--

Brian Brazil

www.robustperception.io

[Bjoern Rabenstein]

On 28.05.20 21:30, Julius Volz wrote:
>
> 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.

YES

It would obviously be better if those exporter listing decisions would
"just work" with best judgement and we didn't need to vote about
individual guideline. However, the discussion in
https://github.com/prometheus/docs/pull/1640 circled back to the SNMP
Exporter argument multiple times. The single person on the one side of
the argument explained their concerns, they were considered, but
failed to convince. With the room leaning so obviously to the other
side, one might ask why that circling back had to happen. The vote can
help here to prune at least one branch of the meandering
discussion. In particular with the often used reasoning that "that's
how we did it before", it's good to know if perhaps "that's not how we
want to do it in the future".

Having said that, I do believe that we should have a more fundamental
discussion about revising "our" criteria of accepting exporter
listings. My impression is that the way it is done right now doesn't
represent our collective intentions very well. Even worse, I am fairly
certain that the process is partially defeating its purpose. In
particular, instead of encouraging the community to join efforts, we
are causing even more fragmentation. Which is really tragic, given how
much time and effort Brian invests in the review work. Kickstarting
such a discussion has been on my agenda for a long time, but given how
my past attempts to move the needle went, it appeared to be a quite
involved effort, for which I'm lacking the capacity. (Others told me
similar things, which reminds me of the "capitulation" topic in
RFC7282, where people cease to express their point of view because
"they don't have the energy to argue against it". Votes, like this
particular one, might then just be an attempt to get out of the many
branches and loops created by persistently upholding objections that
most of the room considers addressed already.)


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

[Stuart Clark]

Do people make use of the "other exporters list" on the wiki?

Would it make sense to make that a bit more known so there is another
less structured place to put things?

https://github.com/prometheus/prometheus/wiki/Default-port-allocations


--
Stuart Clark

[Brian Brazil]

It keeps on getting additions, so I can only presume so.

 

Would it make sense to make that a bit more known so there is another
less structured place to put things?

https://github.com/prometheus/prometheus/wiki/Default-port-allocations

It's already mentioned in the intro text of the exporter list for this reason, but we could always make it more prominent. 

--

Brian Brazil

www.robustperception.io

[Matthias Rampke]

YES

Looking beyond SNMP, I regularly encounter cases where it is technically possible to monitor something using the graphite or statsd exporters. Where this is painful I do guide users into a different integration that is more special-purpose.

My stance is that we should promote what works best, not the lowest number of somethings. There are cases where different options work best for different environments.

/MR

--
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-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200529150058.GS2326%40jahnn.

[Julien Pivotto]

Once we have those criterias, it means that we can have a list when you
create a PR doc:

- Documentation PR
- New instrumentation PR

Like here: https://github.com/prometheus/prometheus/issues/new/choose

And that the "intrumentation PR" would lead to a template with a few
questions:

- Is this exporter blah blah blah?
- ...

So that triaging could be even faster and people would also know our
criterias.

>
>
> --
> 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-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200529150058.GS2326%40jahnn.

--
Julien Pivotto
@roidelapluie

[Julius Volz]

Circling back on this vote long after its end date:

There have been 10 YES votes and no explicit NO votes, so the proposal has passed.

On Thu, May 28, 2020 at 9:30 PM Julius Volz <juliu...@gmail.com> wrote: