On Thu, 28 May 2020 at 20:30, Julius Volz <[email protected]> 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 [email protected]. > 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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLoAi36ffaSAjv71351n%2BAUofFVqrihYQ_ZN93KE-8%3D56A%40mail.gmail.com.
