New prometheus third party C client library

[Romain Le Godais]

Hi everyone!

(this message was originally posted in prometheus-users but had no answer, so I take my chance here).

I work in a software company that develops applications exclusively in C language, and we recently have decided to start using Prometheus as a monitoring system. We first have experimented the concept using the C third party client library that is referenced on the client libraries documentation page, but it was not exactly fitting our needs and we have finally decided to develop our own.

My company develops and uses a general purpose C library (for linux only), called lib-common, that provides most of the basic tools a C programmer can expect (string manipulation, containers, memory allocators, asynchronous event loop, HTTP client/server, RPC communication channels, program argument parser, log files management, ...), and it is now an open-source project. So we naturally have decided to add our prometheus client in it :-).

Here are some links to the project:

• the github project: https://github.com/Intersec/lib-common#lib-common
• the header of the prometheus-client part of the library: https://github.com/Intersec/lib-common/blob/master/src/prometheus-client.h
• the documentation of the prometheus client: https://intersec.github.io/lib-common/lib-common/base/prometheus-client.html
• the source code of an example program using the prometheus client : https://github.com/Intersec/lib-common/blob/master/examples/ex-prometheus-client.c
  

If you think it could useful to the community, we would love to be referenced as an unofficial third-party client library on the dedicated page.
And if not, depending on what's missing we could maybe fill the gap, just tell me.

Have a nice day,
Romain Le Godais.

[Brian Brazil]

On Thu, 4 Jun 2020 at 13:29, Romain Le Godais <lpz.s...@gmail.com> wrote:

Hi everyone!

(this message was originally posted in prometheus-users but had no answer, so I take my chance here).

I work in a software company that develops applications exclusively in C language, and we recently have decided to start using Prometheus as a monitoring system. We first have experimented the concept using the C third party client library that is referenced on the client libraries documentation page, but it was not exactly fitting our needs and we have finally decided to develop our own.

Can you explain more about how it doesn't meet your needs, and if you tried to improve the existing listed library?

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. 

Brian

 

My company develops and uses a general purpose C library (for linux only), called lib-common, that provides most of the basic tools a C programmer can expect (string manipulation, containers, memory allocators, asynchronous event loop, HTTP client/server, RPC communication channels, program argument parser, log files management, ...), and it is now an open-source project. So we naturally have decided to add our prometheus client in it :-).

Here are some links to the project:

• the github project: https://github.com/Intersec/lib-common#lib-common
• the header of the prometheus-client part of the library: https://github.com/Intersec/lib-common/blob/master/src/prometheus-client.h
• the documentation of the prometheus client: https://intersec.github.io/lib-common/lib-common/base/prometheus-client.html
• the source code of an example program using the prometheus client : https://github.com/Intersec/lib-common/blob/master/examples/ex-prometheus-client.c
  

If you think it could useful to the community, we would love to be referenced as an unofficial third-party client library on the dedicated page.
And if not, depending on what's missing we could maybe fill the gap, just tell me.

Have a nice day,
Romain Le Godais.

--
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-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/2cf2703c-25cd-489a-a843-1c3e5da58088%40googlegroups.com.

--

Brian Brazil

www.robustperception.io

[Romain Le Godais]

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).
• 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 think it really is).
  

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.

[Brian Brazil]

On Thu, 4 Jun 2020 at 19:01, Romain Le Godais <lpz.s...@gmail.com> 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 prometheus-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/71e5375a-8e92-4fbc-9730-dab4a66eb13ao%40googlegroups.com.

--

Brian Brazil

www.robustperception.io

[Christian Hoffmann]

On 6/4/20 9:11 PM, Brian Brazil wrote:
> * 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.

There are at least standard ways to get access to more recent gcc
versions with official support (RHSCL aka Red Hat Software Collections).
CentOS also supports them:
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/

This basically works by installing another toolchain to a specific
location (/opt) and sourcing a file or using a provided wrapper with
environment variables (PATH, LD_LIBRARY_PATH, etc.) in order to switch
to the newer version.

Not exactly straight-forward, but it works and should only be necessary
during build, I guess.


Kind regards,
Christian

[Romain Le Godais]

Le jeudi 4 juin 2020 21:12:06 UTC+2, Brian Brazil a écrit :

• 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.

AFAICT there is no way of bypassing this limitation. And I really don't think hiding locks behind atomic macros would be a good idea, even if it was possible haha.
The only way is to install a more recent version of gcc as suggested by Christian.
And I know nothing about Java, so I can't help sorry ;-).

• 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.

Both parts are separated indeed, but we did not even have the idea to try that (regarding the other aspects).

Asking users to pull in a whole library suite plus its dependencies may be a bit much.

Indeed, if you already have a project and want to add prometheus metrics in it afterwards, the lib-common is not adapted (and it could be really complicated to use anyway, we have to work on that).
But in the case "I want to start a new C project for Linux from scratch and I would need to expose prometheus metrics in it", it is interresting I guess.

• (I think it really is).
  

Yeah from the code examples the usage looks good, particularly given the constraints of C.

Glad to hear that!

Brian

Romain.