On 28 May 21:53, Brian Brazil wrote: > 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.
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.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. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200528210553.GA1258946%40oxygen.
