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 On Fri, May 29, 2020 at 3:01 PM Bjoern Rabenstein <[email protected]> wrote: > 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] [email protected] > > -- > 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/20200529150058.GS2326%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMV%3D_gZzt_69pmGOtSK1yTOm-YwXgSMCmLTnpb75Sr5Tb0%3Dykw%40mail.gmail.com.
