Add collector for database/sql#DBStats

[Mitsuo Heijo]

Hi Prometheus Developers.

I was guided here from https://github.com/prometheus/client_golang/pull/848

There are several agenda items.

1. Whether client_golang should include DBStatsCollector.

2. Should the metrics be prefixed with go_... ? While the database/sql package is Go-specific, those metrics aren't really coming from the Go runtime.

[Matthias Rampke]

Ah, even before following the link I had the same questions as Björn: Could this be a separate thing? Does it benefit significantly from being part of the standard client_golang, or could it just as well be something people pull in on demand?

I see at least two libraries that already do this, do we need a third? What is different about your approach?

/MR

--
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/ecb8b635-8e88-4cd2-880a-c1f00a76d41an%40googlegroups.com.

[Ben Kochie]

I like the idea of making client_golang have more "APM" like features. I'm not sure this would be something to enable by default, but having a central place for these things makes sense to me.

To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMV%3D_gbvhRNuKHBJC%2BqRMeT-vWZUsfYoUj%2BM_xdPDN%3Dcoob-%3DA%40mail.gmail.com.

[Julien Pivotto]

I find what we do with Java quite nice:

https://github.com/prometheus/client_java

Unfortunately for golang, it will be more difficult for at least 2
releases, the time for go mod lazy loading to come and make its youth
sicknesses. let's not forget client_golang is one of the most used
go libraries out there.

On 23 Mar 13:57, Ben Kochie wrote:
> I like the idea of making client_golang have more "APM" like features. I'm
> not sure this would be something to enable by default, but having a central
> place for these things makes sense to me.
>
>
>
> On Tue, Mar 23, 2021 at 11:24 AM Matthias Rampke <matt...@prometheus.io>
> wrote:
>
> > Ah, even before following the link I had the same questions as Björn:
> > Could this be a separate thing? Does it benefit significantly from being
> > part of the standard client_golang, or could it just as well be something
> > people pull in on demand?
> >

> > I see at least two <https://github.com/krpn/go-sql-db-stats> libraries
> > <https://github.com/dlmiddlecote/sqlstats> that already do this, do we

> > need a third? What is different about your approach?
> >
> > /MR
> >
> > On Mon, Mar 22, 2021 at 11:06 AM Mitsuo Heijo <mitsuo...@gmail.com>
> > wrote:
> >
> >> Hi Prometheus Developers.
> >>
> >> I was guided here from
> >> https://github.com/prometheus/client_golang/pull/848
> >>
> >> There are several agenda items.
> >>
> >> 1. Whether client_golang should include DBStatsCollector.
> >> 2. Should the metrics be prefixed with go_... ? While the database/sql
> >> package is Go-specific, those metrics aren't really coming from the Go
> >> runtime.
> >>
> >> --
> >> 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/ecb8b635-8e88-4cd2-880a-c1f00a76d41an%40googlegroups.com

> >> <https://groups.google.com/d/msgid/prometheus-developers/ecb8b635-8e88-4cd2-880a-c1f00a76d41an%40googlegroups.com?utm_medium=email&utm_source=footer>
> >> .

> >>
> > --
> > 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/CAMV%3D_gbvhRNuKHBJC%2BqRMeT-vWZUsfYoUj%2BM_xdPDN%3Dcoob-%3DA%40mail.gmail.com
> > <https://groups.google.com/d/msgid/prometheus-developers/CAMV%3D_gbvhRNuKHBJC%2BqRMeT-vWZUsfYoUj%2BM_xdPDN%3Dcoob-%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> > .

> >
>
> --
> 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/CABbyFmot-EQziwcepriON4ATxQaY5nHR7vboq%3DYZtX780oi8pw%40mail.gmail.com.

--
Julien Pivotto
@roidelapluie

[Bjoern Rabenstein]

On 23.03.21 14:31, Julien Pivotto wrote:
>
> I find what we do with Java quite nice:
>
> https://github.com/prometheus/client_java

Could you be more specific what you are referring to?

> Unfortunately for golang, it will be more difficult for at least 2
> releases, the time for go mod lazy loading to come and make its youth
> sicknesses. let's not forget client_golang is one of the most used
> go libraries out there.

Is this meant as a concern that adding more collectors will blow up
the number of Go modules involved?

In case of the proposed collector for the database/sql, there won't be
any new dependencies, so that wouldn't be a concern.

Or am I reading you wrong here?


In any case, I get the following from the responses so far:

- Yes, it would be fine to have more collectors for more or less
standardized things in client_golang. We do have something similar
in client_java already.

- We could put those into a `collectors` package or similar. I
actually wanted to do that for the existing collectors, but I
couldn't move most of them with the current package layout as that
would create circular dependencies. So we could also put them into
the normal `client_golang/prometheus` package, given that we have
already four other `New...Collector` constructors. Please discuss!
(o:

- For the SQL collector specifically, whoever implements it should
look through the three known implementations so far (and perhaps
find out if there are even more) and distill the best design and
feature set out of them. (Note that we might also just want to add a
collector for core features and point power users to a more specific
implementation, cf. how `NewBuildInfoCollector` points to
https://github.com/povilasv/prommod .)

--
Björn Rabenstein
[PGP-ID] 0x851C3DA17D748D03
[email] bjo...@rabenste.in

[Julien Pivotto]

On 23 Mar 20:45, Bjoern Rabenstein wrote:
> On 23.03.21 14:31, Julien Pivotto wrote:
> >
> > I find what we do with Java quite nice:
> >
> > https://github.com/prometheus/client_java
>
> Could you be more specific what you are referring to?

Client java has helpers/examples for jetty, log4j, guava, logback, dropwizard,
caffeine, spring_web, vertx..

>
> > Unfortunately for golang, it will be more difficult for at least 2
> > releases, the time for go mod lazy loading to come and make its youth
> > sicknesses. let's not forget client_golang is one of the most used
> > go libraries out there.
>
> Is this meant as a concern that adding more collectors will blow up
> the number of Go modules involved?
>
> In case of the proposed collector for the database/sql, there won't be
> any new dependencies, so that wouldn't be a concern.

I am thinking at the "have more APM" thing, where would add more
framework/interfaces out of the box.

>
> Or am I reading you wrong here?
>
>
> In any case, I get the following from the responses so far:
>
> - Yes, it would be fine to have more collectors for more or less
> standardized things in client_golang. We do have something similar
> in client_java already.
>
> - We could put those into a `collectors` package or similar. I
> actually wanted to do that for the existing collectors, but I
> couldn't move most of them with the current package layout as that
> would create circular dependencies. So we could also put them into
> the normal `client_golang/prometheus` package, given that we have
> already four other `New...Collector` constructors. Please discuss!
> (o:
>
> - For the SQL collector specifically, whoever implements it should
> look through the three known implementations so far (and perhaps
> find out if there are even more) and distill the best design and
> feature set out of them. (Note that we might also just want to add a
> collector for core features and point power users to a more specific
> implementation, cf. how `NewBuildInfoCollector` points to
> https://github.com/povilasv/prommod .)
>
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>

> --
> 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/20210323194554.GV2773%40jahnn.

--
Julien Pivotto
@roidelapluie