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