On 04 Jan 09:25, Willy Tarreau wrote:
> On Mon, Jan 04, 2021 at 08:58:05AM +0100, William Dauchy wrote:
> > On Tue, Dec 22, 2020 at 3:10 PM William Dauchy <wdau...@gmail.com> wrote:
> > > > But in addition, it only uses the field for prometheus and not
> > > > for the rest of the stats, making a special case in the stats for
> > > > prometheus, which I don't like much.
> > > > So given that the version and release dates were already present there,
> > > > why not just add a new compiler_version field, fill it with the missing
> > > > info so that the consumer has all 3 info available ?
> > >
> > > I understand your comment; however from prometheus point of view, it
> > > is not so nice:
> > > My patch was producing something like:
> > >
> > > # HELP haproxy_process_build_info HAProxy build info.
> > > # TYPE haproxy_process_build_info gauge
> > > haproxy_process_build_info{version="2.4-dev4-7a58a2-1",releasedate="2020/12/22",gccversion="10.2.1
> > > 20201207"} 1
> > >
> > > And you propose to have:
> > > haproxy_process_version{version="2.4-dev4-7a58a2-1"} 1
> > > haproxy_process_relase_date{releasedate="2020/12/22"} 1
> > > haproxy_process_compiler_version{gccversion="10.2.1 20201207"} 1
> > >
> > > I understand it creates two different ways to handle that information
> > > but from a prometheus point of view, this is not the recommended way
> > > to do those things. With our current implementation there is no easy
> > > way to gather those 3 values within a single metric.
> >
> > What do we conclude here? Christopher, any thoughts about it?
>
> Just a suggestion, couldn't we have the prometheus exporter simply build
> these elements by assembling them together ? We could possibly special-case
> a few entries (especially for the info part) but we should definitely avoid
> doing this too often, otherwise it will make it impossible to make prometheus
> users benefit from regular additions to the stats and we'll be back to the
> situation we used to be in a long time ago with the HTML stats page. Note,
> if what is needed is just to add multiple fields (e.g. an extra aggregate
> version field in the same spirit as /proc/version), that's certainly fine.
> I doubt anyone cares about the compiler version alone anyway, so we could
> have a "build_version" or whatever with the full string in the format you
> suggest.
>
> Just my two cents,
> Willy
> Good morning, As said before, from a Prometheus perspective the _build_info approach is indeed more common. I am questioning if the release date is really a useful label however. -- (o- Julien Pivotto //\ Open-Source Consultant V_/_ Inuits - https://www.inuits.eu
signature.asc
Description: PGP signature
