On Fri, 29 May 2020 at 11:24, Julius Volz <julius.v...@gmail.com> wrote:
> On Thu, May 28, 2020 at 10:53 PM Brian Brazil < > brian.bra...@robustperception.io> wrote: > >> On Thu, 28 May 2020 at 20:30, Julius Volz <julius.v...@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-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 >>> <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 >> > -- 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/CAHJKeLr_xwhQAXif7gbYMbhkCujUSxmWDJf%2BHh8JgzukNxjKwA%40mail.gmail.com.
