Re: [prometheus-developers] Exemplar Query API query parameter

[Ben Ye]

Hi Julien,

Thanks for the reply. That makes sense to me and it is very natural to
implement it this way in Grafana.

I am working on adding a new promtool subcommand for querying exemplars
with a query flag. From the UX perspective, it is a little bit weird to let
users provide promql queries instead of matchers. It might cause some
confusion (at least to me).

Best regards,
Ben Ye

On Wed, Apr 28, 2021 at 6:55 PM Julien Pivotto 
wrote:

> On 28 Apr 11:55, Ben Ye wrote:
> > Hi Prometheus developers & maintainers,
> >
> > I am looking at the Exemplar API
> > <
> https://prometheus.io/docs/prometheus/latest/querying/api/#querying-exemplars>
> and
> > I have one question about the query parameter.
> >
> > Here query supports any promql expression. But from the code
> > <
> https://github.com/prometheus/prometheus/blob/main/web/api/v1/api.go#L493-L501>,
>
> > what we need is just label matchers to select series. Then why do we use
> > query as the parameter instead of using match[]?
> >
> > Best regards,
> > Ben Ye
>
> It seems that it was chosen so that it was easy to get the exemplars of
> a promql query without requiring the requester to analyze the query to
> extract the series from the query.
>
> >
> > --
> > 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-developers+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/027851f8-93e6-47c0-9ca0-f1923508d837n%40googlegroups.com
> .
>
>
> --
> Julien Pivotto
> @roidelapluie
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAAYGSaxW9GoRw0vt5X5k2TUsh%3DwZp%3D2N8-eZR%3DHL%3DAhJcAGX5g%40mail.gmail.com.

Re: [prometheus-developers] [python prometheus_client] is Gauge.set guaranteed to always cast as float given value?

[Jonathan Martin, MARSS]

Hi Chris,

Thanks a lot for the clarification!

As long as it is considered OK to give a boolean (whatever it becomes under
the hood), then I'm happy.
Indeed, adding a test case and official doc for using booleans makes total
sense and would avoid unexpected change in that area.

Best regards,

Jonathan



On Wed, Apr 28, 2021 at 9:46 PM Chris Marchbanks 
wrote:

> Hi Jonathan,
>
> As it stands I would say that is an implementation detail that could
> change, for example we might treat integers differently from floats in the
> future. That is just the status quo, and if the community would like to see
> this as the official behavior we could add a test case for setting values
> to booleans. OpenMetrics even specifies that booleans must be represented
> as 0/1 so I think there is a reasonable case to make it official.
>
> Chris
>
> On Wed, Apr 28, 2021 at 4:16 AM Jonathan Martin 
> wrote:
>
>> Hi there,
>>
>> I have a question relative to Gauge and booleans, if you don't mind.
>>
>> I'm considering to use a gauge to reflect the evolution of a boolean
>> value.
>>
>> Knowing that the set method of a Gauge cast the given value as a float, I
>> could call directly my_gauge.set(my_bool_value), and have it set to 0.0 or
>> 1.0.
>>
>> So the question here is: Is the casting as float part of the API design,
>> or simply an implementation detail which may change?
>>
>> If we have no guarantee that this cast will remain, then the call to set
>> needs to be protected by my_gauge.set(float(my_bool_value)), but it is a
>> pity to call it twice...
>>
>> It's a nice built in capability, so if it is going to last, I may argue
>> that it would be worth mentioning it explicitly somewhere, either in the
>> doc of the *set* function or the documentation of the Gauge (
>> https://github.com/prometheus/client_python#gauge).
>>
>> Thanks in advance!
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/prometheus-developers/ffcee28e-d367-4897-8b30-ff5a1e28daean%40googlegroups.com
>> 
>> .
>>
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAFiVW2E0ayndmk%3DUmRit76dbb-DMnVQUmoWz-F%2B_gpKzBwJ17Q%40mail.gmail.com.

Re: [prometheus-developers] Migrating away from github.com/gogo/protobuf

[Austin Cawley-Edwards]

Looks like Thanos is having a similar discussion internally:
https://github.com/thanos-io/thanos/pull/4086#discussion_r617274400

On Wed, Apr 28, 2021 at 1:19 PM Austin Cawley-Edwards <
austin.caw...@gmail.com> wrote:

> Here's also some nice history on how Protobuf in Go has changed:
> https://github.com/protocolbuffers/protobuf-go#historical-legacy
>
> And just for clarification, I'm recommending we switch to
> google.golang.org/protobuf (which is now the official implementation),
> sorry for the confusion/typo with golang/protobuf
> .
>
> On Wed, Apr 28, 2021 at 12:39 PM Austin Cawley-Edwards <
> austin.caw...@gmail.com> wrote:
>
>> This surprised me a little, and sounds awesome - but I can't find any
>>> more information about it.  Does v1.4.0 generate code for the serialisation
>>> / deserialisation function or still rely on Golang reflection?  Does it
>>> allow for the neat tricks to get rid of pointers and all the allocations?
>>> Anything I can read about this would be super useful.
>>
>>
>> Hmm, I'm not sure on all the specifics, but here's what I've found so far:
>> * Golang reflection has largely been replaced by the protoreflect
>> 
>> package (which *does not *use Golang reflection under the hood)
>> * SerDe uses the protoreflect package via dedicated modules for different
>> formats (json
>> ,
>> text
>> ,
>> wire
>> 
>> )
>> * Not sure about the specific tricks/ if the overuse of pointers +
>> allocations are still present, but there is now a first-class lib for
>> creating compiler plugins
>>  that
>> might be what you're looking for? Looks like there are many plugins that
>> use it already, judging by the imports
>> 
>>
>> Off the top of my head, I would think checking in with the Cortex and
>>> Thanos projects is probably a good idea ...
>>>
>>
>> +1 sounds good! Are there specific people I should ping on this list? Or
>> open up issues in their repos? You mentioned there are others for Cortex @
>> tom.wil...@gmail.com?
>>
>> On Wed, Apr 28, 2021 at 8:05 AM Tom Wilkie  wrote:
>>
>>> > Along with that, many of the performance boosts that are provided by
>>> gogo have been addressed in the official Go lib, golang/protobuf
>>> , as of v1.4.0
>>> .
>>>
>>> This surprised me a little, and sounds awesome - but I can't find any
>>> more information about it.  Does v1.4.0 generate code for the serialisation
>>> / deserialisation function or still rely on Golang reflection?  Does it
>>> allow for the neat tricks to get rid of pointers and all the allocations?
>>> Anything I can read about this would be super useful.
>>>
>>> > Off the top of my head, I would think checking in with the Cortex and
>>> Thanos projects is probably a good idea, I know both have a good amount of
>>> optimizations optimizing allocations, so it would be good to check that
>>> these would still be possible.
>>>
>>> From a Cortex PoV, we have copies of these protos so I don't think this
>>> would be too much of a problem, but I'd defer to people who know better
>>> than me.
>>>
>>> Cheers
>>>
>>> Tom
>>>
>>> On Wed, Apr 28, 2021 at 10:07 AM Frederic Branczyk 
>>> wrote:
>>>
 I'd be very happy with this. One consideration that we should take
 (certainly not blocking this but should keep in mind) is how this would
 affect immediate downstream users. Off the top of my head, I would think
 checking in with the Cortex and Thanos projects is probably a good idea, I
 know both have a good amount of optimizations optimizing allocations, so it
 would be good to check that these would still be possible.

 On Tue, 27 Apr 2021 at 22:51, Austin Cawley-Edwards <
 austin.caw...@gmail.com> wrote:

>
> Hi all,
>
> The protobuf library used in Prometheus, gogo/protobuf
> , is no longer actively maintained
> (activity largely stopped pre-2020, looking for new ownership
> ). Along with that, many
> of the performance boosts that are provided by gogo have been addressed in
> the official Go lib, golang/protobuf
> , as of v1.4.0
> .
>
> Many projects that used gogo/protobuf have since switched to the
> official lib (ex: Istio ,
> Envoyproxy ),
> largely 

Re: [prometheus-developers] [python prometheus_client] is Gauge.set guaranteed to always cast as float given value?

[Chris Marchbanks]

Hi Jonathan,

As it stands I would say that is an implementation detail that could
change, for example we might treat integers differently from floats in the
future. That is just the status quo, and if the community would like to see
this as the official behavior we could add a test case for setting values
to booleans. OpenMetrics even specifies that booleans must be represented
as 0/1 so I think there is a reasonable case to make it official.

Chris

On Wed, Apr 28, 2021 at 4:16 AM Jonathan Martin 
wrote:

> Hi there,
>
> I have a question relative to Gauge and booleans, if you don't mind.
>
> I'm considering to use a gauge to reflect the evolution of a boolean value.
>
> Knowing that the set method of a Gauge cast the given value as a float, I
> could call directly my_gauge.set(my_bool_value), and have it set to 0.0 or
> 1.0.
>
> So the question here is: Is the casting as float part of the API design,
> or simply an implementation detail which may change?
>
> If we have no guarantee that this cast will remain, then the call to set
> needs to be protected by my_gauge.set(float(my_bool_value)), but it is a
> pity to call it twice...
>
> It's a nice built in capability, so if it is going to last, I may argue
> that it would be worth mentioning it explicitly somewhere, either in the
> doc of the *set* function or the documentation of the Gauge (
> https://github.com/prometheus/client_python#gauge).
>
> Thanks in advance!
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/ffcee28e-d367-4897-8b30-ff5a1e28daean%40googlegroups.com
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CANVFovVD7FhvAHdu74%2BG00CBZJO-NpRU%3DmkTDYSwb%2B2VPQ-e8w%40mail.gmail.com.

[prometheus-developers] Exemplar Query API query parameter

[Ben Ye]

Hi Prometheus developers & maintainers,

I am looking at the Exemplar API 
 
and 
I have one question about the query parameter.

Here query supports any promql expression. But from the code 
,
 
what we need is just label matchers to select series. Then why do we use 
query as the parameter instead of using match[]?

Best regards,
Ben Ye

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/027851f8-93e6-47c0-9ca0-f1923508d837n%40googlegroups.com.

Re: [prometheus-developers] Migrating away from github.com/gogo/protobuf

[Austin Cawley-Edwards]

Here's also some nice history on how Protobuf in Go has changed:
https://github.com/protocolbuffers/protobuf-go#historical-legacy

And just for clarification, I'm recommending we switch to
google.golang.org/protobuf (which is now the official implementation),
sorry for the confusion/typo with golang/protobuf
.

On Wed, Apr 28, 2021 at 12:39 PM Austin Cawley-Edwards <
austin.caw...@gmail.com> wrote:

> This surprised me a little, and sounds awesome - but I can't find any more
>> information about it.  Does v1.4.0 generate code for the serialisation /
>> deserialisation function or still rely on Golang reflection?  Does it allow
>> for the neat tricks to get rid of pointers and all the allocations?
>> Anything I can read about this would be super useful.
>
>
> Hmm, I'm not sure on all the specifics, but here's what I've found so far:
> * Golang reflection has largely been replaced by the protoreflect
> 
> package (which *does not *use Golang reflection under the hood)
> * SerDe uses the protoreflect package via dedicated modules for different
> formats (json
> ,
> text
> ,
> wire
> 
> )
> * Not sure about the specific tricks/ if the overuse of pointers +
> allocations are still present, but there is now a first-class lib for
> creating compiler plugins
>  that
> might be what you're looking for? Looks like there are many plugins that
> use it already, judging by the imports
> 
>
> Off the top of my head, I would think checking in with the Cortex and
>> Thanos projects is probably a good idea ...
>>
>
> +1 sounds good! Are there specific people I should ping on this list? Or
> open up issues in their repos? You mentioned there are others for Cortex @
> tom.wil...@gmail.com?
>
> On Wed, Apr 28, 2021 at 8:05 AM Tom Wilkie  wrote:
>
>> > Along with that, many of the performance boosts that are provided by
>> gogo have been addressed in the official Go lib, golang/protobuf
>> , as of v1.4.0
>> .
>>
>> This surprised me a little, and sounds awesome - but I can't find any
>> more information about it.  Does v1.4.0 generate code for the serialisation
>> / deserialisation function or still rely on Golang reflection?  Does it
>> allow for the neat tricks to get rid of pointers and all the allocations?
>> Anything I can read about this would be super useful.
>>
>> > Off the top of my head, I would think checking in with the Cortex and
>> Thanos projects is probably a good idea, I know both have a good amount of
>> optimizations optimizing allocations, so it would be good to check that
>> these would still be possible.
>>
>> From a Cortex PoV, we have copies of these protos so I don't think this
>> would be too much of a problem, but I'd defer to people who know better
>> than me.
>>
>> Cheers
>>
>> Tom
>>
>> On Wed, Apr 28, 2021 at 10:07 AM Frederic Branczyk 
>> wrote:
>>
>>> I'd be very happy with this. One consideration that we should take
>>> (certainly not blocking this but should keep in mind) is how this would
>>> affect immediate downstream users. Off the top of my head, I would think
>>> checking in with the Cortex and Thanos projects is probably a good idea, I
>>> know both have a good amount of optimizations optimizing allocations, so it
>>> would be good to check that these would still be possible.
>>>
>>> On Tue, 27 Apr 2021 at 22:51, Austin Cawley-Edwards <
>>> austin.caw...@gmail.com> wrote:
>>>

 Hi all,

 The protobuf library used in Prometheus, gogo/protobuf
 , is no longer actively maintained
 (activity largely stopped pre-2020, looking for new ownership
 ). Along with that, many
 of the performance boosts that are provided by gogo have been addressed in
 the official Go lib, golang/protobuf
 , as of v1.4.0
 .

 Many projects that used gogo/protobuf have since switched to the
 official lib (ex: Istio ,
 Envoyproxy ),
 largely for eco-system compatibility reasons now that performance is not a
 factor. The gogo-compiled protobufs are not compatible with any
 golang-compiled protobufs, and vice-versa. This makes consuming external
 protobuf APIs impossible unless they also maintain a gogo version, which is
 not common.

 I'm 

Re: [prometheus-developers] Migrating away from github.com/gogo/protobuf

[Austin Cawley-Edwards]

>
> This surprised me a little, and sounds awesome - but I can't find any more
> information about it.  Does v1.4.0 generate code for the serialisation /
> deserialisation function or still rely on Golang reflection?  Does it allow
> for the neat tricks to get rid of pointers and all the allocations?
> Anything I can read about this would be super useful.


Hmm, I'm not sure on all the specifics, but here's what I've found so far:
* Golang reflection has largely been replaced by the protoreflect

package (which *does not *use Golang reflection under the hood)
* SerDe uses the protoreflect package via dedicated modules for different
formats (json
,
text
,
wire
)
* Not sure about the specific tricks/ if the overuse of pointers +
allocations are still present, but there is now a first-class lib for
creating compiler plugins
 that
might be what you're looking for? Looks like there are many plugins that
use it already, judging by the imports


Off the top of my head, I would think checking in with the Cortex and
> Thanos projects is probably a good idea ...
>

+1 sounds good! Are there specific people I should ping on this list? Or
open up issues in their repos? You mentioned there are others for Cortex @
tom.wil...@gmail.com?

On Wed, Apr 28, 2021 at 8:05 AM Tom Wilkie  wrote:

> > Along with that, many of the performance boosts that are provided by
> gogo have been addressed in the official Go lib, golang/protobuf
> , as of v1.4.0
> .
>
> This surprised me a little, and sounds awesome - but I can't find any more
> information about it.  Does v1.4.0 generate code for the serialisation /
> deserialisation function or still rely on Golang reflection?  Does it allow
> for the neat tricks to get rid of pointers and all the allocations?
> Anything I can read about this would be super useful.
>
> > Off the top of my head, I would think checking in with the Cortex and
> Thanos projects is probably a good idea, I know both have a good amount of
> optimizations optimizing allocations, so it would be good to check that
> these would still be possible.
>
> From a Cortex PoV, we have copies of these protos so I don't think this
> would be too much of a problem, but I'd defer to people who know better
> than me.
>
> Cheers
>
> Tom
>
> On Wed, Apr 28, 2021 at 10:07 AM Frederic Branczyk 
> wrote:
>
>> I'd be very happy with this. One consideration that we should take
>> (certainly not blocking this but should keep in mind) is how this would
>> affect immediate downstream users. Off the top of my head, I would think
>> checking in with the Cortex and Thanos projects is probably a good idea, I
>> know both have a good amount of optimizations optimizing allocations, so it
>> would be good to check that these would still be possible.
>>
>> On Tue, 27 Apr 2021 at 22:51, Austin Cawley-Edwards <
>> austin.caw...@gmail.com> wrote:
>>
>>>
>>> Hi all,
>>>
>>> The protobuf library used in Prometheus, gogo/protobuf
>>> , is no longer actively maintained
>>> (activity largely stopped pre-2020, looking for new ownership
>>> ). Along with that, many
>>> of the performance boosts that are provided by gogo have been addressed in
>>> the official Go lib, golang/protobuf
>>> , as of v1.4.0
>>> .
>>>
>>> Many projects that used gogo/protobuf have since switched to the
>>> official lib (ex: Istio ,
>>> Envoyproxy ),
>>> largely for eco-system compatibility reasons now that performance is not a
>>> factor. The gogo-compiled protobufs are not compatible with any
>>> golang-compiled protobufs, and vice-versa. This makes consuming external
>>> protobuf APIs impossible unless they also maintain a gogo version, which is
>>> not common.
>>>
>>> I'm wondering if anyone has done work in this area recently, and if the
>>> community agrees it's a net benefit switching to the official
>>> golang/protobuf implementation.
>>>
>>> *What this would mean for Prometheus*
>>>
>>> Looking at the history of protobuf in Prometheus, it seems like both
>>> golang/protobuf and gogo/protobuf were until the end of 2017, when it then
>>> made sense to consolidate onto gogo (#3346
>>> ) (#3394
>>> ).
>>>
>>> As 

[prometheus-developers] Announcing the Prometheus April 2021 dev summit

[Julien Pivotto]

Hello o/

Tomorrow we will have our April 2021 dev summit, at 2pm UTC.

You can find the google meet link in our public calendar:
https://prometheus.io/community/

What are the Prometheus dev summits?

The Prometheus dev summits are monthly virtual events where the
Prometheus developers community discusses Prometheus development.

The scope is wider than just the "prometheus server", we also discuss
other projects under the Prometheus org and the ecosystem in general.

They are open and everyone is welcome to participate.

The CNCF code of conduct applies:
https://github.com/cncf/foundation/blob/master/code-of-conduct.md

Note: the dev summits are also recorded and publicly viewable afterwards.

-- 
Julien Pivotto
@roidelapluie

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/20210428090855.GA177351%40oxygen.

Re: [prometheus-developers] Migrating away from github.com/gogo/protobuf

[Frederic Branczyk]

I'd be very happy with this. One consideration that we should take
(certainly not blocking this but should keep in mind) is how this would
affect immediate downstream users. Off the top of my head, I would think
checking in with the Cortex and Thanos projects is probably a good idea, I
know both have a good amount of optimizations optimizing allocations, so it
would be good to check that these would still be possible.

On Tue, 27 Apr 2021 at 22:51, Austin Cawley-Edwards 
wrote:

>
> Hi all,
>
> The protobuf library used in Prometheus, gogo/protobuf
> , is no longer actively maintained
> (activity largely stopped pre-2020, looking for new ownership
> ). Along with that, many of
> the performance boosts that are provided by gogo have been addressed in the
> official Go lib, golang/protobuf , as
> of v1.4.0 .
>
> Many projects that used gogo/protobuf have since switched to the official
> lib (ex: Istio , Envoyproxy
> ), largely for
> eco-system compatibility reasons now that performance is not a factor. The
> gogo-compiled protobufs are not compatible with any golang-compiled
> protobufs, and vice-versa. This makes consuming external protobuf APIs
> impossible unless they also maintain a gogo version, which is not common.
>
> I'm wondering if anyone has done work in this area recently, and if the
> community agrees it's a net benefit switching to the official
> golang/protobuf implementation.
>
> *What this would mean for Prometheus*
>
> Looking at the history of protobuf in Prometheus, it seems like both
> golang/protobuf and gogo/protobuf were until the end of 2017, when it then
> made sense to consolidate onto gogo (#3346
> ) (#3394
> ).
>
> As noted in the above issues, the official golang/protobuf package is
> still present in vendored files, so it is just the Prometheus protos that
> would need to be updated. The build procedures (mainly scripts/genproto.sh
> )
> have not changed much since the 2017 shift, so the work would be mainly
> adjusting this back to use golang/protobuf and recompiling the `prompb`
> package.
>
> Does anyone know of other necessary changes/ complications that I'm
> missing?
>
> Thanks all for your time,
> Austin
>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/38caa51d-e88a-489b-a045-54144cd1a03fn%40googlegroups.com
> 
> .
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAOs1Umy%2BhjN10r9q_MOwZ2wHL-0MEDZWw_2SCUPW%2B%3D8xpKvdQw%40mail.gmail.com.