On Thu, 4 Jun 2020 at 19:01, Romain Le Godais <[email protected]> wrote:
> Thanks for your quick reply. > > Le jeudi 4 juin 2020 14:42:32 UTC+2, Brian Brazil a écrit : > >> Can you explain more about how it doesn't meet your needs, and if you >> tried to improve the existing listed library? >> >> > There are several reasons for which we have decided to develop our own > client: > > - the existing client seems to crash on debian 9, and when we first > experimented prometheus our workstations were on debian 9 (we now have > migrated to debian 10 and the library works fine on this version). When I > realized it worked fine on more recent versions, I've decided to not > investigate because clearly debian 9 is old. > - our software must support RedHat 7 because some of our client > servers are running on this distribution; the existing client does not > compile on this distribution because it uses atomic doubles for thread > safety, that is only supported from gcc 4.8 (and RHEL 7 has gcc 4.7). > > That's a fun one, is there a way to fallback to something else based on macros or similar? I've had similar issues over in Java. > > - the existing client has a dependency on microhttpd library, and > would have been a new dependency itself for us. We usually tend to avoid > having too much external dependencies for our programs. On the other hand, > we already have a HTTP library embeeded in our lib-common, so we preferred > reusing it. > - thanks to all the tools we have in our library (classes, string > manipulation, memory allocators, ...), we thought we could develop the > prometheus client in a more simple way than from scratch, and end up with a > library more simple to use > > I'd hope that the instrumentation bits of a client library would be independant of the rest and the exposition be replaceable, which does seem to be the case for the one that's currently listed. The only interesting dependency I see from a quick glance at the instrumentation is pthread, but I think that's still workable on Windows. Asking users to pull in a whole library suite plus its dependencies may be a bit much. > - (I think it really is). > > Yeah from the code examples the usage looks good, particularly given the constraints of C. Brian > > - > > As you can see, the reasons are very contextual to our case, and we have > nothing to blame about the existing library. > Plus ours is much more than just a simple prometheus client, that could be > annoying to be integrated in an existing codebase, but very convenient for > new projects. > > >> The current listed one appears to be actively maintained, and we try to >> avoid duplicates so that everyone is working towards one good library >> rather than continuously creating new integrations that lose implicit >> knowledge. >> > > Sure, I understand that! > > >> >> Brian >> > > Romain. > > -- > 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/71e5375a-8e92-4fbc-9730-dab4a66eb13ao%40googlegroups.com > <https://groups.google.com/d/msgid/prometheus-developers/71e5375a-8e92-4fbc-9730-dab4a66eb13ao%40googlegroups.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/CAHJKeLoWiYuxT%3DA2AT97Qmu9Rcuqcw7Y4Hh4d%3Dy%3De81A%3DxsBTw%40mail.gmail.com.
