Re: [prometheus-developers] Prometheus Pushgateway TTL

[Bjoern Rabenstein]

On 12.07.23 10:10, E wrote:
> I think optional TTL per time series is a good idea. It might have several
> use cases, it doesn't break anything, and it shouldn't be too hard to make.
> So why not?

Because all the use cases discussed so far have turned out to be
anti-patterns we don't want to support. This topic was brought up
multiple times at dev-summits etc., and the outcome was always the
same.

> I might have used this feature to trigger short-lived alerts with arbitrary
> text in a label, something I wouldn't do without TTL because it would
> require a cleanup.

I don't quite understand that use case, but feel free to flesh it out
a bit more and propose it as a topic for the dev-summit by adding it
to the agenda:
https://docs.google.com/document/d/11LC3wJcVk00l8w5P3oLQ-m3Y37iom6INAMEu2ZAGIIE/edit?pli=1
 

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

Re: [prometheus-developers] Prometheus Pushgateway TTL

[Bjoern Rabenstein]

On 11.07.23 15:23, 'Braden Schaeffer' via Prometheus Developers wrote:
> They could live for 5s or 1 hour.

The whole idea of a Prometheus counter doesn't really make sense for a
job that lives for just 5s, if you are scraping every 15s or every
minute or so.

And a job that lives for 1 hour should be scraped directly.

So in the first case, using a counter doesn't make sense, and in the
second case using the Pushgateway doesn't make sense.

> Does it really matter what you send to pushgateway?  It supports
> counters so why not push them?

We could be stricter and just reject counters being pushed to the
Pushgateway, but that would be a breaking change. Historically, the
metric type information in Prometheus was (and to a good part still
is) some kind of "weak typing", so no hard restrictions were imposed
(you can apply `rate` to a gauge or `delta` to a counter without
Prometheus complaining about it).

Also, it feels natural to count "records backed up by the daily
database back up job" in a counter and push it to the
Pushgateway. However, when it arrives on your Prometheus server, it
doesn't really behave as a counter. Summing those values up across
instances is really painful with PromQL, and the reason for that is
that we are essentially handling events here, for which Prometheus as
a whole wasn't really designed.

If you really have to use Prometheus for that case, the "least bad"
solutions I know of is statsd with the statsd-exporter (
https://github.com/prometheus/statsd_exporter ) or the
prom-aggregation-gateway
( https://github.com/zapier/prom-aggregation-gateway ).

A TTL doesn't really address the fundamental problem. It might enable
a very brittle solution that is worse than the solution that are
already available.

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

Re: [prometheus-developers] Prometheus Pushgateway TTL

[E]

I think optional TTL per time series is a good idea. It might have 
several use cases, it doesn't break anything, and it shouldn't be too 
hard to make. So why not?
I might have used this feature to trigger short-lived alerts with 
arbitrary text in a label, something I wouldn't do without TTL because 
it would require a cleanup.


--
Best regards,
Evgeniy Yunkin

On 11/07/2023 22:23, 'Braden Schaeffer' via Prometheus Developers wrote:
They could live for 5s or 1 hour.  Does it really matter what you send 
to pushgateway? It supports counters so why not push them?


A TTL is all we need here.

On Sat, Jul 1, 2023 at 5:32 PM Bjoern Rabenstein  
wrote:


On 29.06.23 08:47, 'Braden Schaeffer' via Prometheus Developers wrote:
> It's the same as calculating the total incoming request rate of
N pods in a
> deployment: sum(rate(grpc_request_count{service=foo}[5m]))

🤔 I'm surprised that you seem to push a counter metric to the
Pushgateway.

I would say the intended use case for the Pushgateway is that a
batch job pushes its metrics upon completion. That means you only ever
have one value of those metrics, so a `rate` on those would always
result in zero.

Are you perhaps pushing multiple times during the runtime of your
batch jobs? That would be weird indeed for a PGW use case. Why don't
you just scrape your jobs normally then?

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAKG2A1cBTOk_wrJi%2B2uO_2y6LKG0t0AMpMptBCdM6yTR_cTDxg%40mail.gmail.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/12953903-7092-2b9c-d26f-7baf5b2c5c90%40gmail.com.

Re: [prometheus-developers] Prometheus Pushgateway TTL

['Braden Schaeffer' via Prometheus Developers]

They could live for 5s or 1 hour.  Does it really matter what you send to
pushgateway? It supports counters so why not push them?

A TTL is all we need here.

On Sat, Jul 1, 2023 at 5:32 PM Bjoern Rabenstein  wrote:

> On 29.06.23 08:47, 'Braden Schaeffer' via Prometheus Developers wrote:
> > It's the same as calculating the total incoming request rate of N pods
> in a
> > deployment: sum(rate(grpc_request_count{service=foo}[5m]))
>
> 🤔 I'm surprised that you seem to push a counter metric to the
> Pushgateway.
>
> I would say the intended use case for the Pushgateway is that a
> batch job pushes its metrics upon completion. That means you only ever
> have one value of those metrics, so a `rate` on those would always
> result in zero.
>
> Are you perhaps pushing multiple times during the runtime of your
> batch jobs? That would be weird indeed for a PGW use case. Why don't
> you just scrape your jobs normally then?
>
> --
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAKG2A1cBTOk_wrJi%2B2uO_2y6LKG0t0AMpMptBCdM6yTR_cTDxg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Pushgateway TTL

[Bjoern Rabenstein]

On 29.06.23 08:47, 'Braden Schaeffer' via Prometheus Developers wrote:
> It's the same as calculating the total incoming request rate of N pods in a
> deployment: sum(rate(grpc_request_count{service=foo}[5m]))

🤔 I'm surprised that you seem to push a counter metric to the
Pushgateway.

I would say the intended use case for the Pushgateway is that a
batch job pushes its metrics upon completion. That means you only ever
have one value of those metrics, so a `rate` on those would always
result in zero.

Are you perhaps pushing multiple times during the runtime of your
batch jobs? That would be weird indeed for a PGW use case. Why don't
you just scrape your jobs normally then?

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

Re: [prometheus-developers] Prometheus Pushgateway TTL

['Braden Schaeffer' via Prometheus Developers]

It's the same as calculating the total incoming request rate of N pods in a
deployment: sum(rate(grpc_request_count{service=foo}[5m]))

For our use case, we have N kubernetes jobs being spun up pushing many
metrics, like grpc_request_count, to pushgateway. If I want to know the
rate of outgoing requests, I have to have unique labels on the metric for
prometheus to accurately calculate the request rate of the service as a
whole. Without them they just overwrite each other. For pushgateway,
though, those unique ids are never GCd like they are in prometheus.

So, every day a service creating 2 pods every 5 minutes and writing just a
single grpc_request_count metric with 20 label values to pushgateway will
have a cardinality of (2 pod ids * 288 times a day * 20 grpc_request_count
labels). That's a cardinality of 11k series per day for that one
metric from that one service that will not be GC'd by pushgateway until I
restart it.

On Thu, Jun 29, 2023 at 7:03 AM Bjoern Rabenstein 
wrote:

> On 14.06.23 13:10, 'Braden Schaeffer' via Prometheus Developers wrote:
> >
> > The most basic example, two batch jobs that produce the same metrics
> (grpc
> > or http metrics). This is not just `last_completed_at` or something as I
> > have seen before where its the same metric being updated over and over
> > agin. You have to include a label that identifies these jobs as
> different
> > so that metrics like gRPC request rates can be calculated correctly. In
> the
> > kubernetes world this usually means pod ID. Simple enough until you have
> > 1000s of these pod IDs compounded by other labels.
>
> I don't fully understand what you are trying to do. Could you explain
> what metrics you are pushing exactly, and what PromQL expressions you
> are using to "correctly calculate a gRPC request rate"?
>
> --
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAKG2A1cgwqxMQxVYKkBK6r3crFDOh3iZckCbMhuYUBSbLwwVwg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Pushgateway TTL

[Bjoern Rabenstein]

On 14.06.23 13:10, 'Braden Schaeffer' via Prometheus Developers wrote:
> 
> The most basic example, two batch jobs that produce the same metrics (grpc 
> or http metrics). This is not just `last_completed_at` or something as I 
> have seen before where its the same metric being updated over and over 
> agin. You have to include a label that identifies these jobs as different 
> so that metrics like gRPC request rates can be calculated correctly. In the 
> kubernetes world this usually means pod ID. Simple enough until you have 
> 1000s of these pod IDs compounded by other labels.

I don't fully understand what you are trying to do. Could you explain
what metrics you are pushing exactly, and what PromQL expressions you
are using to "correctly calculate a gRPC request rate"?

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/ZJ1k6tQ/nrX8cgP%2B%40mail.rabenste.in.

Re: [prometheus-developers] Prometheus Agent as Sidecar with Prometheus-Operator

[Arthur Silva Sens]

Oof, just noticed that the images do not load in some email clients 😬

The proposal can also be seen at this Pull Request
,
with the images :)

Em sex., 14 de abr. de 2023 às 10:00, Arthur Silva Sens <
arthursens2...@gmail.com> escreveu:

> Hi everybody, I'm Arthur from the Prometheus-Operator team.
>
> We've recently added support for running Prometheus in Agent mode with
> Prometheus-Operator and we've started to brainstorm new Deployment Patterns
> that could be explored with the Agent, e.g. as Daemonsets or Sidecars.
>
> At this point in time, I'm drafting how things could look like if
> Prometheus Agent is run as Pod sidecars, and would love to know the opinion
> of the community about it. I'm particularly interested to know if there is
> an appetite from the community for such a deployment pattern and if you
> find new failure modes with that approach.
>
> Here is the proposal:
>
> Agent Deployment Pattern: Sidecar Injection
>
>
> 
> Summary
>
> With Prometheus-Operator finally supporting running Prometheus in Agent
> mode, we can start thinking about different deployment patterns that can be
> explored with this minimal container. This document aims to continue the
> work started by this document
> ,
> focusing on exploring how Prometheus-Operator can leverage deploying
> PrometheusAgents as sidecars running alongside pods that a user wants to
> monitor.
>
> 
> Background
>
> By the time this document was written, Prometheus-Operator can deploy
> Prometheus in Agent mode, but only using a pattern similar to the original
> implementation of Prometheus Server: using StatefulSets. The original
> design document
> 
>  for
> Prometheus Agent already mentions that different deployment patterns are
> desired, however, for the sake of speeding up the initial implementation it
> was decided to re-use the logic and start with the Agent running as
> StatefulSets.
>
> Also for the sake of speeding up implementation, this document won't focus
> on several new Deployment patterns, but only one: Sidecar Injection.
>
> Looking at the traditional deployment model, we have a single Prometheus
> (or an HA setup) per cluster or namespace, responsible for scraping all
> containers under their scope. Prometheus operator relies on ServiceMonitor
> , PodMonitor, and Probe CRs to configure Prometheus, which will
> eventually use Kubernetes service-discovery to find endpoints that need to
> be scraped.
>
> Depending on the Cluster's scale and how often Prometheus hits Kubernetes
> API, Prometheus service discovery can increase the load on the API
> significantly and affect the overall functionality of said cluster.
>
> Another problem is that one or more containers can be updated to a
> problematic version that causes a Cardinality Spike
> .
> Depending on the proportion of the spike, it is possible that a container
> could single-handedly crash the monitoring system of the whole cluster.
>
> [image: Traditional Deployment Pattern]
> 
> .
>
> 
> Proposal
>
> This document proposes a new deployment model where Prometheus-Operator
> injects Prometheus agents as a sidecar container (and Prometheus config
> reloader) to pods that needs to be scrapped. With a sidecar, we tackle both
> problems mentioned above:
>
>
>- Load on Kubernetes API won't exist since it's not needed anymore.
>Prometheus will scrape containers from the same pod through their shared
>network interface and scrape configuration can be declared via pod
>annotations.
>- A sudden cardinality spike will not affect the whole monitoring
>system. In a worst-case scenario, it will fail a single pod.
>
> A common pattern used with Prometheus's Kubernetes service discovery is
> the usage of annotation to declaratively tell Prometheus which endpoints
> need to be scraped
> 

Re: [prometheus-developers] Prometheus client_model protobuf question

[Bjoern Rabenstein]

On 04.11.22 22:16, 'Fabian Stäber' via Prometheus Developers wrote:
> 
> Now, I'm not sure how to set the MetricFamily.name field for Counter
> metrics.
> 
> Should I use the name including the "_total" suffix here or without the
> "_total" suffix?

Short answer: Include the _total suffix.

Longer answer: OpenMetrics mandates to remove the _total suffix in the
metric family. That's a breaking change from the original Prometheus
format, both text and protobuf. (Which implies that you need to remove
the suffix when implementing the OpenMetrics protobuf format.) While
the change makes sense from a certain consistency perspective, I
personally think it's not worth the breakage it causes in many cases
(among them the collision of two standard Go metrics exposed by
prometheus/client_golang). It is one of a number of adoption hurdles,
and I would love to see this decision revisited.

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

Re: [prometheus-developers] Prometheus Alert-Generator Compliance testing for Thanos

['Jean-Philippe Quéméner' via Prometheus Developers]

Update on the alert generator compliance:

Some vendors cannot expose some of the APIs required by the Prometheus 
alert generator compliance test suite.

*We modified the test suite so it can be run by vendors themselves and 
submit results to Prometheus/CNCF. *CNCF will contractually protect against 
submitting wrong results on purpose.

If there are any questions, please feel free to ask in this thread.

Thanks,
Jean-Philippe Quéméner (johnny)

On Wednesday, March 2, 2022 at 1:22:02 PM UTC+1 bwpl...@gmail.com wrote:

> Thanks!
>
> Noted, added issue for this 
> https://github.com/thanos-io/thanos/issues/5203
>
> Kind Regards,
> Bartek Płotka (@bwplotka)
>
>
> On Wed, Mar 2, 2022 at 9:32 AM Ganesh Vernekar  wrote:
>
>> Hello Thanos team,
>>
>> I hope this email finds you well.
>>
>> As a part of Prometheus conformance program 
>> , we had floated a doc 
>> on "Prometheus Alert-Generator Compliance" many months ago and had 
>> finalized the specification for that (see here 
>> 
>> ).
>>
>> The test suite to test the specification is now ready and instructions on 
>> how to run the test suite are present here 
>> 
>> .
>>
>> If you wish Thanos to be compliant with Prometheus Alert-Generator, 
>> please test your software with the above test suite and report back the 
>> results by replying to this thread (results being the entire log output of 
>> the test run).
>>
>> If you do need any additional help from the test suite (for example 
>> setting custom headers to some requests), please let me know and I will add 
>> those abilities to the test suite.
>>
>> Going forward, we would like to automate this process. We ask you to add 
>> your test-suite config template by opening a PR against 
>> prometheus/compliance  and 
>> create test-thanos.yaml in the alert_generator directory. See 
>> test-.*.yaml files here 
>>  for 
>> example. Please also add instructions on how to set up as comments in the 
>> same file.
>>
>> If you face issues in running the test suite or understanding any error 
>> messages, I am happy to answer your queries.
>>
>> We plan to publish the results during the third week of May 2022 (during 
>> KubeCon EU).
>>
>> Thanks,
>> Ganesh (codesome)
>> Prometheus team
>>
>> -- 
>> 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/CAERru7OSTOMVKgT%2BgPnjTuRLXfynmuWtdoA%3DMN8KhNvoY0b10w%40mail.gmail.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/7b6f3259-1cfb-4aff-934f-1fb1d27c4907n%40googlegroups.com.

Re: [prometheus-developers] Prometheus Alert-Generator Compliance testing for Thanos

[Bartłomiej Płotka]

Thanks!

Noted, added issue for this https://github.com/thanos-io/thanos/issues/5203

Kind Regards,
Bartek Płotka (@bwplotka)


On Wed, Mar 2, 2022 at 9:32 AM Ganesh Vernekar  wrote:

> Hello Thanos team,
>
> I hope this email finds you well.
>
> As a part of Prometheus conformance program
> , we had floated a doc on
> "Prometheus Alert-Generator Compliance" many months ago and had finalized
> the specification for that (see here
> 
> ).
>
> The test suite to test the specification is now ready and instructions on
> how to run the test suite are present here
> 
> .
>
> If you wish Thanos to be compliant with Prometheus Alert-Generator, please
> test your software with the above test suite and report back the results by
> replying to this thread (results being the entire log output of the test
> run).
>
> If you do need any additional help from the test suite (for example
> setting custom headers to some requests), please let me know and I will add
> those abilities to the test suite.
>
> Going forward, we would like to automate this process. We ask you to add
> your test-suite config template by opening a PR against
> prometheus/compliance  and
> create test-thanos.yaml in the alert_generator directory. See test-.*.yaml
>  files here
>  for
> example. Please also add instructions on how to set up as comments in the
> same file.
>
> If you face issues in running the test suite or understanding any error
> messages, I am happy to answer your queries.
>
> We plan to publish the results during the third week of May 2022 (during
> KubeCon EU).
>
> Thanks,
> Ganesh (codesome)
> Prometheus team
>
> --
> 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/CAERru7OSTOMVKgT%2BgPnjTuRLXfynmuWtdoA%3DMN8KhNvoY0b10w%40mail.gmail.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/CAMssQwbYu02q8C5iXXQ9z22-RVDn8%2BCiapsGDG-YMutOEQcU1Q%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Storage Working Group

[Bartłomiej Płotka]

Hi All

This is a kind reminder about our bi-weekly Prometheus Storage Working 
Group meeting we have on Tuesdays 9AM UTC (in an hour today!)

If you have any topics to discuss around Prometheus storage, scrape 
performance, TSDB or remote write/read, feel free to put an item on our 
agenda 
https://docs.google.com/document/d/1HWL-NIfog3_pFxUny0kAHeoxd0grnqhCBcHVPZN4y3Y/edit

See you! 🤗

Kind Regards,
Bartek Plotka (@bwplotka):

On Thursday, September 10, 2020 at 7:24:47 PM UTC+2 callu...@gmail.com 
wrote:

> I'd be interested in joining but the earliest I could do is around 1400 
> GMT (I'm GMT-7 currently). If I'm the only one who can't make the time 
> you're proposing then that's okay, it's hard to schedule things at times 
> that both Ganesh and I can attend :)
>
> On Mon, Sep 7, 2020 at 7:06 AM Manish G  wrote:
>
>> I am keen to be part of the initiative, but am relatively new to 
>> prometheus.
>>
>> With regards
>>
>> On Mon, Sep 7, 2020 at 4:28 PM fbra...@gmail.com  
>> wrote:
>>
>>> Hello Prometheans,
>>>
>>> There have been various ideas around potentially improving parts of 
>>> Prometheus' TSDB. I would like to start a working group that meets 
>>> regularly around these topics and compares notes, researches, and 
>>> experiments with potential improvements and hopefully ultimately develop 
>>> designs to be proposed as improvements to Prometheus.
>>>
>>> I've been talking to Ganesh about this topic a bit and we've put 
>>> together a small starting document to kick this off: 
>>> https://docs.google.com/document/d/1HWL-NIfog3_pFxUny0kAHeoxd0grnqhCBcHVPZN4y3Y/edit?usp=sharing
>>>
>>> The idea, for now, is to meet at a biweekly cadence at 9 AM GMT for 30 
>>> minutes, a link to the meeting is in the above document. (this works for 
>>> Ganesh and me, we're open to rescheduling this and or extending this if 
>>> needed)
>>>
>>> The first meeting for this is scheduled for the 22nd of September. There 
>>> will be meeting notes, so if you're just interested in the results read 
>>> those, if you're interested in contributing to these topics join us! :)
>>>
>>> Best regards,
>>> Frederic
>>>
>>> -- 
>>> 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/ab025c6f-c37d-44e0-8dba-455ac9c1fadfn%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-devel...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/prometheus-developers/CAOFd6ii279fV0XBxU5H0Ra4h3iuNmkxFt1QYY_%3D96kGnaOxKBQ%40mail.gmail.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/691c26bf-bc83-4c9a-bae5-60e54ccde428n%40googlegroups.com.

Re: [prometheus-developers] Prometheus scraping at metric-endpoint

[Prince]

Thank you. 
So for a for each unique label value there will be a unique time-series

On Thursday, September 9, 2021 at 3:57:48 PM UTC+5:30 Stuart Clark wrote:

> On 2021-09-09 11:06, Prince wrote:
> > Hi everyone,
> > Can anyone please let me know, Is it possible to collect multiple
> > gauge values for a single time series at the metric end-point?
> > For eg: the text-format exposition
> > 
> > my_metric{lname:"abc"} 1.5 2.5
> > ** here metric name is: my_metric
> > label name is: lname
> > label value is: abc
> > First gauge value: 1.5
> > Second gauge value: 2.5
> > 
>
> Each metric has exactly one value, so if you are wanting to store 
> multiple values that would be multiple metrics, each with a unique name.
>
> So for example my_metric_temperature_degrees & my_metric_height_meters
>
> -- 
> Stuart Clark
>

-- 
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/4e696a99-9c83-4598-b2e6-178f57305cf0n%40googlegroups.com.

Re: [prometheus-developers] Prometheus scraping at metric-endpoint

[Stuart Clark]

On 2021-09-09 11:06, Prince wrote:

Hi everyone,
Can anyone please let me know, Is it possible to collect multiple
gauge values for a single time series at the metric end-point?
For eg: the text-format exposition

my_metric{lname:"abc"} 1.5 2.5
** here metric name is: my_metric
 label name is: lname
 label value is:  abc
First gauge value: 1.5
Second gauge value: 2.5



Each metric has exactly one value, so if you are wanting to store 
multiple values that would be multiple metrics, each with a unique name.


So for example my_metric_temperature_degrees & my_metric_height_meters

--
Stuart Clark

--
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/4235167312193c2bc8a7aedf0c99d7a2%40Jahingo.com.

Re: [prometheus-developers] Prometheus Developers

[Ben Kochie]

This is not a development topic. Please use our support community.

https://prometheus.io/community/

On Thu, Jun 24, 2021 at 1:29 PM Mithun Batabyal 
wrote:

> Hi Team,
>
> im using Prometheus and grafana  as part of monitoring and deployed
> through helm charts.
>
> currently we have default data retention for Prometheus data to 15 days.
> How to increase this limit to 30days?
> Please guide me.
>
> Thanks and Regards,
> Mithun Batabyal
>
> --
> 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/1ec4204d-99e3-4d1b-8cfb-d749ba568706n%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/CABbyFmqJ_fy-6%2B5xf61VGHODEb8gZ4CgHX_b8vTfhxZq-z%2Br5Q%40mail.gmail.com.

Re: [prometheus-developers] Prometheus bug triage

[Tobias Schmidt]

Thank you Julien for all your great work on Prometheus!

On Wed, May 26, 2021 at 11:05 AM Julien Pivotto 
wrote:

> Hello,
>
> Starting next Tuesday June 1st 4.00pm UTC, and every 2 weeks, I will run
> a public Prometheus bug triage meeting.
>
> For one hour, I will go after every issue / pull request recently
> introduced, making sure everyone gets a reply and issues are tagged
> properly. While I try to answer to issues as they come, sometimes I miss
> some of them. This meeting is here for that specific followup.
>
> Everyone interested in Prometheus development is welcome to join. Note:
> the triage will happen even if no one joins me.
>
>
> As a reminder, this is just one extra place to discuss Prometheus
> development. If you are seeking help, our Monday contributor hours are
> here for you. If you want to discuss the Prometheus project future, we
> have a monthly developer summit (next dev summit is tomorrow).
>
> The dates / times are available in the community calendar:
> https://prometheus.io/community
>
> Regards,
>
>
> --
> 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/20210526090517.GA121661%40oxygen
> .
>

-- 
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/CAChBsdDOyBWw76Y0eWXH6xx6sooEQbWyCUG6WLj%3D2YkeQuDSNg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Dynamic Exporter

['Evelyn Pereira Souza' via Prometheus Developers]

On 25.05.21 08:49, 'Christian' via Prometheus Developers wrote:

well. this is embarrassing :-)
I was not aware of "textfile collector" existing already.


that's no problem at all. You had a lot of fun developing and learned a 
lot. The open source world lives from choice


best regards
Evelyn

--
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/bc9e4290-d64f-faee-f543-60c948c94fb0%40disroot.org.


OpenPGP_0x61776FA8E38403FB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [prometheus-developers] Prometheus Dynamic Exporter

['Christian' via Prometheus Developers]

Hi Colin,

well. this is embarrassing :-)
I was not aware of "textfile collector" existing already.

Today I've just added a ttl feature to ensure a broken batch job will not 
produce the same metrics forever. Dont know if the Textfile Collector has 
something similar.

Apart from that - you're right. It does basically the same thing.
The SSL encrytpion and basic auth would be a benefit.

Christian

cdo...@cloudflare.com schrieb am Dienstag, 25. Mai 2021 um 02:12:25 UTC+2:

> Cool project! Out of interest, what would you say are the benefits of this 
> over something like the Node Exporter Textfile Collector (
> https://github.com/prometheus/node_exporter#textfile-collector), or the 
> Prometheus Push Gateway?
>
> - Colin
>
> On Tue, May 25, 2021 at 3:37 AM 'Christian' via Prometheus Developers <
> prometheus...@googlegroups.com> wrote:
>
>> Hi guys,
>>
>> I just want to introduce my new dynamic Prometheus custom metric exporter.
>>
>> It's capable of reading custom metrics from simple textfiles and then 
>> instantly serve them via https and basic auth.
>>
>> Would be happy if somebody finds it useful.
>>
>> Check it out on https://github.com/hoggle64/prometheus_dynamic_exporter.
>>
>> Cheers,
>>
>> Christian 
>>
>> -- 
>> 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/17a9c30b-f9cb-4b44-8981-ff4954fdcc8an%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/3712984c-240c-481d-b5ad-59716920c7bbn%40googlegroups.com.

Re: [prometheus-developers] Prometheus Dynamic Exporter

['Colin Douch' via Prometheus Developers]

Cool project! Out of interest, what would you say are the benefits of this
over something like the Node Exporter Textfile Collector (
https://github.com/prometheus/node_exporter#textfile-collector), or the
Prometheus Push Gateway?

- Colin

On Tue, May 25, 2021 at 3:37 AM 'Christian' via Prometheus Developers <
prometheus-developers@googlegroups.com> wrote:

> Hi guys,
>
> I just want to introduce my new dynamic Prometheus custom metric exporter.
>
> It's capable of reading custom metrics from simple textfiles and then
> instantly serve them via https and basic auth.
>
> Would be happy if somebody finds it useful.
>
> Check it out on https://github.com/hoggle64/prometheus_dynamic_exporter.
>
> Cheers,
>
> Christian
>
> --
> 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/17a9c30b-f9cb-4b44-8981-ff4954fdcc8an%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/CANvZgGxvLdLq3vQyDGtdYqPDUKfboXKv9mLv8fi%2BmDfw-MBurQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Richard Hartmann]

On Thu, Apr 15, 2021 at 4:16 PM Mat Arye  wrote:

> Would there be interest in a remote_read compliance test as well? If so, my 
> team would be happy to write it and contribute, but only if people think it's 
> useful (and it's not already being worked on by others).

Yes, absolutely!

-- 
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/CAD77%2BgT-abowWJBH%2Bt_gAHeLajgr9uUf2pEx_GE7210PLbfxuQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Julius Volz]

Yeah! While it's not as high priority because fewer people implement and
use it, it would still be great to have :)

On Thu, Apr 15, 2021, 16:16 Mat Arye  wrote:

> Thanks to Tom and Julius for the work!
>
> Would there be interest in a remote_read compliance test as well? If so,
> my team would be happy to write it and contribute, but only if people think
> it's useful (and it's not already being worked on by others).
>
>
>
> On Thu, Apr 15, 2021 at 4:58 AM Julius Volz  wrote:
>
>> Great, PromLabs is donating its PromQL compliance tester to this effort
>> as well: https://github.com/prometheus/compliance/pull/7
>>
>> On Wed, Apr 14, 2021 at 1:33 PM Tom Wilkie  wrote:
>>
>>> SGTM, I've moved it to https://github.com/prometheus/compliance (and
>>> moved all the remote_write code to a subdirectory).
>>>
>>> Cheers
>>>
>>> Tom
>>>
>>> On Wed, Apr 14, 2021 at 4:34 AM Callum Styan 
>>> wrote:
>>>
 Repo in prometheus org makes the most sense to me as well.

 On Tue, Apr 13, 2021 at 3:04 PM Julien Pivotto <
 roidelapl...@prometheus.io> wrote:

> I am in favour of a repo in the prometheus org.
>
> On 13 Apr 22:08, Julius Volz wrote:
> > Nope, they are run as a binary that takes flags, a config, and
> outputs JSON
> > / TEXT / TSV / CSV for consumption by humans / website code / etc.
> >
> >
> https://github.com/promlabs/promql-compliance-tester/blob/master/cmd/promql-compliance-tester/main.go
> >
> > On Tue, Apr 13, 2021 at 9:50 PM Tom Wilkie 
> wrote:
> >
> > > Yeah I’m fine with either - but would probably prefer a single big
> repo.
> > > Are your PromQl tests golang unit tests by any chance?
> > >
> > > On Tue, 13 Apr 2021 at 20:36, Julius Volz 
> wrote:
> > >
> > >> I'm fine with the main org too. Then there's just the question of
> whether
> > >> we have one big compatibility repo for remote_write / PromQL /
> etc., or one
> > >> for each tested interface. There's definitely pros + cons for each
> > >> approach, but I'd ultimately be fine with either I think.
> > >>
> > >> On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie 
> wrote:
> > >>
> > >>> I only suggested the -community org so its not in my personal
> org, to
> > >>> encourage contributions from the wider community.  I would be
> happy to move
> > >>> it to the main prometheus org.
> > >>>
> > >>> As a monorepo guy, I'm less keen on a proliferation of many orgs
> so less
> > >>> keen on a dedicated prometheus-compatibility org...  but could
> be convinced.
> > >>>
> > >>> Cheers
> > >>>
> > >>> Tom
> > >>>
> > >>> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
> > >>> richih.mailingl...@gmail.com> wrote:
> > >>>
> >  On Tue, Apr 13, 2021 at 2:16 PM Julius Volz <
> julius.v...@gmail.com>
> >  wrote:
> > 
> >  > Great! I think as we start taking compatibility more
> seriously, we
> >  could even create a home for remote_write / PromQL / ...
> compatibility
> >  tests in either the main Prometheus org, or in a dedicated
> "Prometheus
> >  Compatibility Project" org?
> > 
> >  I strongly believe that the best place for tests we consider
> official
> >  is the main Prometheus org, as long as the main author is fine
> with
> >  moving them. I do not have strong opinions about the specific
> repo
> >  they live 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-developers+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoztaOmqH_wBsF%2BJue9BywkfdO3otQEOxbWVW-P-VeMb6w%40mail.gmail.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/20210413220449.GA1265218%40oxygen
> .
>
 --
>> 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/CA%2BT6YoxY10RLegTv-va-su1RKbc9TEh%2By0VCSntF_%2BjKSp2AtA%40mail.gmail.com
>> 

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Mat Arye]

Thanks to Tom and Julius for the work!

Would there be interest in a remote_read compliance test as well? If so, my
team would be happy to write it and contribute, but only if people think
it's useful (and it's not already being worked on by others).



On Thu, Apr 15, 2021 at 4:58 AM Julius Volz  wrote:

> Great, PromLabs is donating its PromQL compliance tester to this effort as
> well: https://github.com/prometheus/compliance/pull/7
>
> On Wed, Apr 14, 2021 at 1:33 PM Tom Wilkie  wrote:
>
>> SGTM, I've moved it to https://github.com/prometheus/compliance (and
>> moved all the remote_write code to a subdirectory).
>>
>> Cheers
>>
>> Tom
>>
>> On Wed, Apr 14, 2021 at 4:34 AM Callum Styan 
>> wrote:
>>
>>> Repo in prometheus org makes the most sense to me as well.
>>>
>>> On Tue, Apr 13, 2021 at 3:04 PM Julien Pivotto <
>>> roidelapl...@prometheus.io> wrote:
>>>
 I am in favour of a repo in the prometheus org.

 On 13 Apr 22:08, Julius Volz wrote:
 > Nope, they are run as a binary that takes flags, a config, and
 outputs JSON
 > / TEXT / TSV / CSV for consumption by humans / website code / etc.
 >
 >
 https://github.com/promlabs/promql-compliance-tester/blob/master/cmd/promql-compliance-tester/main.go
 >
 > On Tue, Apr 13, 2021 at 9:50 PM Tom Wilkie 
 wrote:
 >
 > > Yeah I’m fine with either - but would probably prefer a single big
 repo.
 > > Are your PromQl tests golang unit tests by any chance?
 > >
 > > On Tue, 13 Apr 2021 at 20:36, Julius Volz 
 wrote:
 > >
 > >> I'm fine with the main org too. Then there's just the question of
 whether
 > >> we have one big compatibility repo for remote_write / PromQL /
 etc., or one
 > >> for each tested interface. There's definitely pros + cons for each
 > >> approach, but I'd ultimately be fine with either I think.
 > >>
 > >> On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie 
 wrote:
 > >>
 > >>> I only suggested the -community org so its not in my personal
 org, to
 > >>> encourage contributions from the wider community.  I would be
 happy to move
 > >>> it to the main prometheus org.
 > >>>
 > >>> As a monorepo guy, I'm less keen on a proliferation of many orgs
 so less
 > >>> keen on a dedicated prometheus-compatibility org...  but could be
 convinced.
 > >>>
 > >>> Cheers
 > >>>
 > >>> Tom
 > >>>
 > >>> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
 > >>> richih.mailingl...@gmail.com> wrote:
 > >>>
 >  On Tue, Apr 13, 2021 at 2:16 PM Julius Volz <
 julius.v...@gmail.com>
 >  wrote:
 > 
 >  > Great! I think as we start taking compatibility more
 seriously, we
 >  could even create a home for remote_write / PromQL / ...
 compatibility
 >  tests in either the main Prometheus org, or in a dedicated
 "Prometheus
 >  Compatibility Project" org?
 > 
 >  I strongly believe that the best place for tests we consider
 official
 >  is the main Prometheus org, as long as the main author is fine
 with
 >  moving them. I do not have strong opinions about the specific
 repo
 >  they live 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-developers+unsubscr...@googlegroups.com.
 > To view this discussion on the web visit
 https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoztaOmqH_wBsF%2BJue9BywkfdO3otQEOxbWVW-P-VeMb6w%40mail.gmail.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/20210413220449.GA1265218%40oxygen
 .

>>> --
> 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/CA%2BT6YoxY10RLegTv-va-su1RKbc9TEh%2By0VCSntF_%2BjKSp2AtA%40mail.gmail.com
> 
> .
>


-- 
Mat Arye, Promscale  Team Lead
See what we're working on (feedback welcome!): tsdb.c

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Julius Volz]

Great, PromLabs is donating its PromQL compliance tester to this effort as
well: https://github.com/prometheus/compliance/pull/7

On Wed, Apr 14, 2021 at 1:33 PM Tom Wilkie  wrote:

> SGTM, I've moved it to https://github.com/prometheus/compliance (and
> moved all the remote_write code to a subdirectory).
>
> Cheers
>
> Tom
>
> On Wed, Apr 14, 2021 at 4:34 AM Callum Styan 
> wrote:
>
>> Repo in prometheus org makes the most sense to me as well.
>>
>> On Tue, Apr 13, 2021 at 3:04 PM Julien Pivotto <
>> roidelapl...@prometheus.io> wrote:
>>
>>> I am in favour of a repo in the prometheus org.
>>>
>>> On 13 Apr 22:08, Julius Volz wrote:
>>> > Nope, they are run as a binary that takes flags, a config, and outputs
>>> JSON
>>> > / TEXT / TSV / CSV for consumption by humans / website code / etc.
>>> >
>>> >
>>> https://github.com/promlabs/promql-compliance-tester/blob/master/cmd/promql-compliance-tester/main.go
>>> >
>>> > On Tue, Apr 13, 2021 at 9:50 PM Tom Wilkie 
>>> wrote:
>>> >
>>> > > Yeah I’m fine with either - but would probably prefer a single big
>>> repo.
>>> > > Are your PromQl tests golang unit tests by any chance?
>>> > >
>>> > > On Tue, 13 Apr 2021 at 20:36, Julius Volz 
>>> wrote:
>>> > >
>>> > >> I'm fine with the main org too. Then there's just the question of
>>> whether
>>> > >> we have one big compatibility repo for remote_write / PromQL /
>>> etc., or one
>>> > >> for each tested interface. There's definitely pros + cons for each
>>> > >> approach, but I'd ultimately be fine with either I think.
>>> > >>
>>> > >> On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie 
>>> wrote:
>>> > >>
>>> > >>> I only suggested the -community org so its not in my personal org,
>>> to
>>> > >>> encourage contributions from the wider community.  I would be
>>> happy to move
>>> > >>> it to the main prometheus org.
>>> > >>>
>>> > >>> As a monorepo guy, I'm less keen on a proliferation of many orgs
>>> so less
>>> > >>> keen on a dedicated prometheus-compatibility org...  but could be
>>> convinced.
>>> > >>>
>>> > >>> Cheers
>>> > >>>
>>> > >>> Tom
>>> > >>>
>>> > >>> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
>>> > >>> richih.mailingl...@gmail.com> wrote:
>>> > >>>
>>> >  On Tue, Apr 13, 2021 at 2:16 PM Julius Volz <
>>> julius.v...@gmail.com>
>>> >  wrote:
>>> > 
>>> >  > Great! I think as we start taking compatibility more seriously,
>>> we
>>> >  could even create a home for remote_write / PromQL / ...
>>> compatibility
>>> >  tests in either the main Prometheus org, or in a dedicated
>>> "Prometheus
>>> >  Compatibility Project" org?
>>> > 
>>> >  I strongly believe that the best place for tests we consider
>>> official
>>> >  is the main Prometheus org, as long as the main author is fine
>>> with
>>> >  moving them. I do not have strong opinions about the specific repo
>>> >  they live 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-developers+unsubscr...@googlegroups.com.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoztaOmqH_wBsF%2BJue9BywkfdO3otQEOxbWVW-P-VeMb6w%40mail.gmail.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/20210413220449.GA1265218%40oxygen
>>> .
>>>
>>

-- 
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/CA%2BT6YoxY10RLegTv-va-su1RKbc9TEh%2By0VCSntF_%2BjKSp2AtA%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Bartłomiej Płotka]

Sounds good, thanks Tom for this work!

Kind Regards,
Bartek Płotka (@bwplotka)


On Wed, Apr 14, 2021 at 1:33 PM Tom Wilkie  wrote:

> SGTM, I've moved it to https://github.com/prometheus/compliance (and
> moved all the remote_write code to a subdirectory).
>
> Cheers
>
> Tom
>
> On Wed, Apr 14, 2021 at 4:34 AM Callum Styan 
> wrote:
>
>> Repo in prometheus org makes the most sense to me as well.
>>
>> On Tue, Apr 13, 2021 at 3:04 PM Julien Pivotto <
>> roidelapl...@prometheus.io> wrote:
>>
>>> I am in favour of a repo in the prometheus org.
>>>
>>> On 13 Apr 22:08, Julius Volz wrote:
>>> > Nope, they are run as a binary that takes flags, a config, and outputs
>>> JSON
>>> > / TEXT / TSV / CSV for consumption by humans / website code / etc.
>>> >
>>> >
>>> https://github.com/promlabs/promql-compliance-tester/blob/master/cmd/promql-compliance-tester/main.go
>>> >
>>> > On Tue, Apr 13, 2021 at 9:50 PM Tom Wilkie 
>>> wrote:
>>> >
>>> > > Yeah I’m fine with either - but would probably prefer a single big
>>> repo.
>>> > > Are your PromQl tests golang unit tests by any chance?
>>> > >
>>> > > On Tue, 13 Apr 2021 at 20:36, Julius Volz 
>>> wrote:
>>> > >
>>> > >> I'm fine with the main org too. Then there's just the question of
>>> whether
>>> > >> we have one big compatibility repo for remote_write / PromQL /
>>> etc., or one
>>> > >> for each tested interface. There's definitely pros + cons for each
>>> > >> approach, but I'd ultimately be fine with either I think.
>>> > >>
>>> > >> On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie 
>>> wrote:
>>> > >>
>>> > >>> I only suggested the -community org so its not in my personal org,
>>> to
>>> > >>> encourage contributions from the wider community.  I would be
>>> happy to move
>>> > >>> it to the main prometheus org.
>>> > >>>
>>> > >>> As a monorepo guy, I'm less keen on a proliferation of many orgs
>>> so less
>>> > >>> keen on a dedicated prometheus-compatibility org...  but could be
>>> convinced.
>>> > >>>
>>> > >>> Cheers
>>> > >>>
>>> > >>> Tom
>>> > >>>
>>> > >>> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
>>> > >>> richih.mailingl...@gmail.com> wrote:
>>> > >>>
>>> >  On Tue, Apr 13, 2021 at 2:16 PM Julius Volz <
>>> julius.v...@gmail.com>
>>> >  wrote:
>>> > 
>>> >  > Great! I think as we start taking compatibility more seriously,
>>> we
>>> >  could even create a home for remote_write / PromQL / ...
>>> compatibility
>>> >  tests in either the main Prometheus org, or in a dedicated
>>> "Prometheus
>>> >  Compatibility Project" org?
>>> > 
>>> >  I strongly believe that the best place for tests we consider
>>> official
>>> >  is the main Prometheus org, as long as the main author is fine
>>> with
>>> >  moving them. I do not have strong opinions about the specific repo
>>> >  they live 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-developers+unsubscr...@googlegroups.com.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoztaOmqH_wBsF%2BJue9BywkfdO3otQEOxbWVW-P-VeMb6w%40mail.gmail.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/20210413220449.GA1265218%40oxygen
>>> .
>>>
>> --
> 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/CAB58Z13WA9ayf7hK6FQmY%2Bmq%3DfqNMNm%2BA%3DkbNkSmRQPccBRmtA%40mail.gmail.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/CAMssQwYxDRnTV9eqyYJU8vVoO0m-0ncpQ3DeLTRFctppPQ85qA%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Tom Wilkie]

SGTM, I've moved it to https://github.com/prometheus/compliance (and moved
all the remote_write code to a subdirectory).

Cheers

Tom

On Wed, Apr 14, 2021 at 4:34 AM Callum Styan  wrote:

> Repo in prometheus org makes the most sense to me as well.
>
> On Tue, Apr 13, 2021 at 3:04 PM Julien Pivotto 
> wrote:
>
>> I am in favour of a repo in the prometheus org.
>>
>> On 13 Apr 22:08, Julius Volz wrote:
>> > Nope, they are run as a binary that takes flags, a config, and outputs
>> JSON
>> > / TEXT / TSV / CSV for consumption by humans / website code / etc.
>> >
>> >
>> https://github.com/promlabs/promql-compliance-tester/blob/master/cmd/promql-compliance-tester/main.go
>> >
>> > On Tue, Apr 13, 2021 at 9:50 PM Tom Wilkie 
>> wrote:
>> >
>> > > Yeah I’m fine with either - but would probably prefer a single big
>> repo.
>> > > Are your PromQl tests golang unit tests by any chance?
>> > >
>> > > On Tue, 13 Apr 2021 at 20:36, Julius Volz 
>> wrote:
>> > >
>> > >> I'm fine with the main org too. Then there's just the question of
>> whether
>> > >> we have one big compatibility repo for remote_write / PromQL / etc.,
>> or one
>> > >> for each tested interface. There's definitely pros + cons for each
>> > >> approach, but I'd ultimately be fine with either I think.
>> > >>
>> > >> On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie 
>> wrote:
>> > >>
>> > >>> I only suggested the -community org so its not in my personal org,
>> to
>> > >>> encourage contributions from the wider community.  I would be happy
>> to move
>> > >>> it to the main prometheus org.
>> > >>>
>> > >>> As a monorepo guy, I'm less keen on a proliferation of many orgs so
>> less
>> > >>> keen on a dedicated prometheus-compatibility org...  but could be
>> convinced.
>> > >>>
>> > >>> Cheers
>> > >>>
>> > >>> Tom
>> > >>>
>> > >>> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
>> > >>> richih.mailingl...@gmail.com> wrote:
>> > >>>
>> >  On Tue, Apr 13, 2021 at 2:16 PM Julius Volz > >
>> >  wrote:
>> > 
>> >  > Great! I think as we start taking compatibility more seriously,
>> we
>> >  could even create a home for remote_write / PromQL / ...
>> compatibility
>> >  tests in either the main Prometheus org, or in a dedicated
>> "Prometheus
>> >  Compatibility Project" org?
>> > 
>> >  I strongly believe that the best place for tests we consider
>> official
>> >  is the main Prometheus org, as long as the main author is fine with
>> >  moving them. I do not have strong opinions about the specific repo
>> >  they live 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-developers+unsubscr...@googlegroups.com.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoztaOmqH_wBsF%2BJue9BywkfdO3otQEOxbWVW-P-VeMb6w%40mail.gmail.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/20210413220449.GA1265218%40oxygen
>> .
>>
>

-- 
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/CAB58Z13WA9ayf7hK6FQmY%2Bmq%3DfqNMNm%2BA%3DkbNkSmRQPccBRmtA%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Callum Styan]

Repo in prometheus org makes the most sense to me as well.

On Tue, Apr 13, 2021 at 3:04 PM Julien Pivotto 
wrote:

> I am in favour of a repo in the prometheus org.
>
> On 13 Apr 22:08, Julius Volz wrote:
> > Nope, they are run as a binary that takes flags, a config, and outputs
> JSON
> > / TEXT / TSV / CSV for consumption by humans / website code / etc.
> >
> >
> https://github.com/promlabs/promql-compliance-tester/blob/master/cmd/promql-compliance-tester/main.go
> >
> > On Tue, Apr 13, 2021 at 9:50 PM Tom Wilkie  wrote:
> >
> > > Yeah I’m fine with either - but would probably prefer a single big
> repo.
> > > Are your PromQl tests golang unit tests by any chance?
> > >
> > > On Tue, 13 Apr 2021 at 20:36, Julius Volz 
> wrote:
> > >
> > >> I'm fine with the main org too. Then there's just the question of
> whether
> > >> we have one big compatibility repo for remote_write / PromQL / etc.,
> or one
> > >> for each tested interface. There's definitely pros + cons for each
> > >> approach, but I'd ultimately be fine with either I think.
> > >>
> > >> On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie 
> wrote:
> > >>
> > >>> I only suggested the -community org so its not in my personal org, to
> > >>> encourage contributions from the wider community.  I would be happy
> to move
> > >>> it to the main prometheus org.
> > >>>
> > >>> As a monorepo guy, I'm less keen on a proliferation of many orgs so
> less
> > >>> keen on a dedicated prometheus-compatibility org...  but could be
> convinced.
> > >>>
> > >>> Cheers
> > >>>
> > >>> Tom
> > >>>
> > >>> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
> > >>> richih.mailingl...@gmail.com> wrote:
> > >>>
> >  On Tue, Apr 13, 2021 at 2:16 PM Julius Volz 
> >  wrote:
> > 
> >  > Great! I think as we start taking compatibility more seriously, we
> >  could even create a home for remote_write / PromQL / ...
> compatibility
> >  tests in either the main Prometheus org, or in a dedicated
> "Prometheus
> >  Compatibility Project" org?
> > 
> >  I strongly believe that the best place for tests we consider
> official
> >  is the main Prometheus org, as long as the main author is fine with
> >  moving them. I do not have strong opinions about the specific repo
> >  they live 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-developers+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoztaOmqH_wBsF%2BJue9BywkfdO3otQEOxbWVW-P-VeMb6w%40mail.gmail.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/20210413220449.GA1265218%40oxygen
> .
>

-- 
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/CAN2d5OSDYAWmmFgtaDhBXDKdhHqZ52CELMfgwKubAogdCygfRw%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Julien Pivotto]

I am in favour of a repo in the prometheus org.

On 13 Apr 22:08, Julius Volz wrote:
> Nope, they are run as a binary that takes flags, a config, and outputs JSON
> / TEXT / TSV / CSV for consumption by humans / website code / etc.
> 
> https://github.com/promlabs/promql-compliance-tester/blob/master/cmd/promql-compliance-tester/main.go
> 
> On Tue, Apr 13, 2021 at 9:50 PM Tom Wilkie  wrote:
> 
> > Yeah I’m fine with either - but would probably prefer a single big repo.
> > Are your PromQl tests golang unit tests by any chance?
> >
> > On Tue, 13 Apr 2021 at 20:36, Julius Volz  wrote:
> >
> >> I'm fine with the main org too. Then there's just the question of whether
> >> we have one big compatibility repo for remote_write / PromQL / etc., or one
> >> for each tested interface. There's definitely pros + cons for each
> >> approach, but I'd ultimately be fine with either I think.
> >>
> >> On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie  wrote:
> >>
> >>> I only suggested the -community org so its not in my personal org, to
> >>> encourage contributions from the wider community.  I would be happy to 
> >>> move
> >>> it to the main prometheus org.
> >>>
> >>> As a monorepo guy, I'm less keen on a proliferation of many orgs so less
> >>> keen on a dedicated prometheus-compatibility org...  but could be 
> >>> convinced.
> >>>
> >>> Cheers
> >>>
> >>> Tom
> >>>
> >>> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
> >>> richih.mailingl...@gmail.com> wrote:
> >>>
>  On Tue, Apr 13, 2021 at 2:16 PM Julius Volz 
>  wrote:
> 
>  > Great! I think as we start taking compatibility more seriously, we
>  could even create a home for remote_write / PromQL / ... compatibility
>  tests in either the main Prometheus org, or in a dedicated "Prometheus
>  Compatibility Project" org?
> 
>  I strongly believe that the best place for tests we consider official
>  is the main Prometheus org, as long as the main author is fine with
>  moving them. I do not have strong opinions about the specific repo
>  they live 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoztaOmqH_wBsF%2BJue9BywkfdO3otQEOxbWVW-P-VeMb6w%40mail.gmail.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/20210413220449.GA1265218%40oxygen.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Julius Volz]

Nope, they are run as a binary that takes flags, a config, and outputs JSON
/ TEXT / TSV / CSV for consumption by humans / website code / etc.

https://github.com/promlabs/promql-compliance-tester/blob/master/cmd/promql-compliance-tester/main.go

On Tue, Apr 13, 2021 at 9:50 PM Tom Wilkie  wrote:

> Yeah I’m fine with either - but would probably prefer a single big repo.
> Are your PromQl tests golang unit tests by any chance?
>
> On Tue, 13 Apr 2021 at 20:36, Julius Volz  wrote:
>
>> I'm fine with the main org too. Then there's just the question of whether
>> we have one big compatibility repo for remote_write / PromQL / etc., or one
>> for each tested interface. There's definitely pros + cons for each
>> approach, but I'd ultimately be fine with either I think.
>>
>> On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie  wrote:
>>
>>> I only suggested the -community org so its not in my personal org, to
>>> encourage contributions from the wider community.  I would be happy to move
>>> it to the main prometheus org.
>>>
>>> As a monorepo guy, I'm less keen on a proliferation of many orgs so less
>>> keen on a dedicated prometheus-compatibility org...  but could be convinced.
>>>
>>> Cheers
>>>
>>> Tom
>>>
>>> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
>>> richih.mailingl...@gmail.com> wrote:
>>>
 On Tue, Apr 13, 2021 at 2:16 PM Julius Volz 
 wrote:

 > Great! I think as we start taking compatibility more seriously, we
 could even create a home for remote_write / PromQL / ... compatibility
 tests in either the main Prometheus org, or in a dedicated "Prometheus
 Compatibility Project" org?

 I strongly believe that the best place for tests we consider official
 is the main Prometheus org, as long as the main author is fine with
 moving them. I do not have strong opinions about the specific repo
 they live 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoztaOmqH_wBsF%2BJue9BywkfdO3otQEOxbWVW-P-VeMb6w%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Tom Wilkie]

Yeah I’m fine with either - but would probably prefer a single big repo.
Are your PromQl tests golang unit tests by any chance?

On Tue, 13 Apr 2021 at 20:36, Julius Volz  wrote:

> I'm fine with the main org too. Then there's just the question of whether
> we have one big compatibility repo for remote_write / PromQL / etc., or one
> for each tested interface. There's definitely pros + cons for each
> approach, but I'd ultimately be fine with either I think.
>
> On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie  wrote:
>
>> I only suggested the -community org so its not in my personal org, to
>> encourage contributions from the wider community.  I would be happy to move
>> it to the main prometheus org.
>>
>> As a monorepo guy, I'm less keen on a proliferation of many orgs so less
>> keen on a dedicated prometheus-compatibility org...  but could be convinced.
>>
>> Cheers
>>
>> Tom
>>
>> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
>> richih.mailingl...@gmail.com> wrote:
>>
>>> On Tue, Apr 13, 2021 at 2:16 PM Julius Volz 
>>> wrote:
>>>
>>> > Great! I think as we start taking compatibility more seriously, we
>>> could even create a home for remote_write / PromQL / ... compatibility
>>> tests in either the main Prometheus org, or in a dedicated "Prometheus
>>> Compatibility Project" org?
>>>
>>> I strongly believe that the best place for tests we consider official
>>> is the main Prometheus org, as long as the main author is fine with
>>> moving them. I do not have strong opinions about the specific repo
>>> they live 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAB58Z11dDoV2oR3MUZfQBHuQScixAVJHK__GOcFC-ZNEAU%2BuNQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Julius Volz]

I'm fine with the main org too. Then there's just the question of whether
we have one big compatibility repo for remote_write / PromQL / etc., or one
for each tested interface. There's definitely pros + cons for each
approach, but I'd ultimately be fine with either I think.

On Tue, Apr 13, 2021 at 6:11 PM Tom Wilkie  wrote:

> I only suggested the -community org so its not in my personal org, to
> encourage contributions from the wider community.  I would be happy to move
> it to the main prometheus org.
>
> As a monorepo guy, I'm less keen on a proliferation of many orgs so less
> keen on a dedicated prometheus-compatibility org...  but could be convinced.
>
> Cheers
>
> Tom
>
> On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
> richih.mailingl...@gmail.com> wrote:
>
>> On Tue, Apr 13, 2021 at 2:16 PM Julius Volz 
>> wrote:
>>
>> > Great! I think as we start taking compatibility more seriously, we
>> could even create a home for remote_write / PromQL / ... compatibility
>> tests in either the main Prometheus org, or in a dedicated "Prometheus
>> Compatibility Project" org?
>>
>> I strongly believe that the best place for tests we consider official
>> is the main Prometheus org, as long as the main author is fine with
>> moving them. I do not have strong opinions about the specific repo
>> they live 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoyHbL48Wu3RCJ2FYzJH%3DmnQq6ByUBL5MxTShXGiohKjgQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Tom Wilkie]

I only suggested the -community org so its not in my personal org, to
encourage contributions from the wider community.  I would be happy to move
it to the main prometheus org.

As a monorepo guy, I'm less keen on a proliferation of many orgs so less
keen on a dedicated prometheus-compatibility org...  but could be convinced.

Cheers

Tom

On Tue, Apr 13, 2021 at 1:48 PM Richard Hartmann <
richih.mailingl...@gmail.com> wrote:

> On Tue, Apr 13, 2021 at 2:16 PM Julius Volz  wrote:
>
> > Great! I think as we start taking compatibility more seriously, we could
> even create a home for remote_write / PromQL / ... compatibility tests in
> either the main Prometheus org, or in a dedicated "Prometheus Compatibility
> Project" org?
>
> I strongly believe that the best place for tests we consider official
> is the main Prometheus org, as long as the main author is fine with
> moving them. I do not have strong opinions about the specific repo
> they live 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAB58Z13mXy9Rrr79b1iFk0onw0dObTgtDUjuGpNnmx%2B2F0SntA%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Richard Hartmann]

On Tue, Apr 13, 2021 at 2:16 PM Julius Volz  wrote:

> Great! I think as we start taking compatibility more seriously, we could even 
> create a home for remote_write / PromQL / ... compatibility tests in either 
> the main Prometheus org, or in a dedicated "Prometheus Compatibility Project" 
> org?

I strongly believe that the best place for tests we consider official
is the main Prometheus org, as long as the main author is fine with
moving them. I do not have strong opinions about the specific repo
they live 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAD77%2BgSzAKnrJYmCg_g_%3DG1U6i4F5BHNE2QFcvDs9QUppV1CGw%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Remote Write "compliance suite"

[Julius Volz]

Great! I think as we start taking compatibility more seriously, we could
even create a home for remote_write / PromQL / ... compatibility tests in
either the main Prometheus org, or in a dedicated "Prometheus Compatibility
Project" org?

On Tue, Apr 13, 2021 at 2:12 PM Tom Wilkie  wrote:

> Hello Prometheans!
>
> In preparation for my PromCon talk, I build a little test suite the checks
> various Prometheus Remote Write compatible "agents":
>
> https://github.com/tomwilkie/remote-write-compliance
>
> There are ~13 pretty simple tests, and each one exports some metrics,
> forks off the "agent" configured to scrape those metrics and send remote
> write requests back to the test, and then validates the results
> it receives.  Its still a WIP but there are a few interesting results
> (including a bug in the Grafana Agent! that has already been fixed...)
>
> I guess I'm sending this email both as an FYI, to see if anyone has any
> questions, and to see what people think of transferring this to the
> prometheus-community github org?
>
> Cheers
>
> Tom
>
> --- FAIL: TestRemoteWrite/vmagent (0.00s)
>
> --- FAIL: TestRemoteWrite/vmagent/Invalid (10.21s)
>
> --- PASS: TestRemoteWrite/vmagent/Histogram (10.21s)
>
> --- FAIL: TestRemoteWrite/vmagent/NameLabel (10.21s)
>
> --- PASS: TestRemoteWrite/vmagent/SortedLabels (10.25s)
>
> --- PASS: TestRemoteWrite/vmagent/Counter (10.25s)
>
> --- PASS: TestRemoteWrite/vmagent/Gauge (10.25s)
>
> --- PASS: TestRemoteWrite/vmagent/InstanceLabel (10.27s)
>
> --- PASS: TestRemoteWrite/vmagent/Up (10.32s)
>
> --- PASS: TestRemoteWrite/vmagent/EmptyLabels (10.18s)
>
> --- FAIL: TestRemoteWrite/vmagent/Staleness (10.27s)
>
> --- PASS: TestRemoteWrite/vmagent/Timestamp (10.27s)
>
> --- FAIL: TestRemoteWrite/vmagent/RepeatedLabels (10.30s)
>
> --- PASS: TestRemoteWrite/vmagent/JobLabel (10.32s)
>
> --- PASS: TestRemoteWrite/prometheus (0.00s)
>
> --- PASS: TestRemoteWrite/prometheus/Timestamp (10.14s)
>
> --- PASS: TestRemoteWrite/prometheus/NameLabel (10.14s)
>
> --- PASS: TestRemoteWrite/prometheus/Counter (10.14s)
>
> --- PASS: TestRemoteWrite/prometheus/EmptyLabels (10.14s)
>
> --- PASS: TestRemoteWrite/prometheus/Staleness (10.14s)
>
> --- PASS: TestRemoteWrite/prometheus/InstanceLabel (10.14s)
>
> --- PASS: TestRemoteWrite/prometheus/RepeatedLabels (10.14s)
>
> --- PASS: TestRemoteWrite/prometheus/SortedLabels (10.17s)
>
> --- PASS: TestRemoteWrite/prometheus/Gauge (10.07s)
>
> --- PASS: TestRemoteWrite/prometheus/JobLabel (10.07s)
>
> --- PASS: TestRemoteWrite/prometheus/Up (10.07s)
>
> --- PASS: TestRemoteWrite/prometheus/Invalid (10.08s)
>
> --- PASS: TestRemoteWrite/prometheus/Histogram (10.08s)
>
> --- FAIL: TestRemoteWrite/otelcollector (0.00s)
>
> --- PASS: TestRemoteWrite/otelcollector/Timestamp (10.02s)
>
> --- FAIL: TestRemoteWrite/otelcollector/NameLabel (10.02s)
>
> --- PASS: TestRemoteWrite/otelcollector/EmptyLabels (10.02s)
>
> --- FAIL: TestRemoteWrite/otelcollector/Staleness (10.02s)
>
> --- FAIL: TestRemoteWrite/otelcollector/Up (10.02s)
>
> --- FAIL: TestRemoteWrite/otelcollector/InstanceLabel (10.03s)
>
> --- FAIL: TestRemoteWrite/otelcollector/Counter (10.03s)
>
> --- FAIL: TestRemoteWrite/otelcollector/RepeatedLabels (10.04s)
>
> --- PASS: TestRemoteWrite/otelcollector/Gauge (10.03s)
>
> --- PASS: TestRemoteWrite/otelcollector/SortedLabels (10.03s)
>
> --- FAIL: TestRemoteWrite/otelcollector/Invalid (10.03s)
>
> --- FAIL: TestRemoteWrite/otelcollector/JobLabel (10.03s)
>
> --- FAIL: TestRemoteWrite/otelcollector/Histogram (10.03s)
>
> --- FAIL: TestRemoteWrite/telegraf (0.00s)
>
> --- PASS: TestRemoteWrite/telegraf/Counter (10.03s)
>
> --- FAIL: TestRemoteWrite/telegraf/RepeatedLabels (10.03s)
>
> --- PASS: TestRemoteWrite/telegraf/SortedLabels (10.03s)
>
> --- FAIL: TestRemoteWrite/telegraf/EmptyLabels (10.03s)
>
> --- PASS: TestRemoteWrite/telegraf/Timestamp (10.03s)
>
> --- FAIL: TestRemoteWrite/telegraf/Staleness (10.03s)
>
> --- PASS: TestRemoteWrite/telegraf/Histogram (10.03s)
>
> --- FAIL: TestRemoteWrite/telegraf/NameLabel (10.03s)
>
> --- PASS: TestRemoteWrite/telegraf/JobLabel (10.03s)
>
> --- FAIL: TestRemoteWrite/telegraf/InstanceLabel (10.03s)
>
> --- FAIL: TestRemoteWrite/telegraf/Up (10.03s)
>
> --- PASS: TestRemoteWrite/telegraf/Gauge (10.03s)
>
> --- FAIL: TestRemoteWrite/telegraf/Invalid (10.03s)
>
> --- PASS: TestRemoteWrite/grafana (0.00s)
>
> --- PASS: TestRemoteWrite/grafana/Histogram (10.17s)
>
> --- PASS: TestRemoteWrite/grafana/InstanceLabel (10.17s)
>
> --- PASS: TestRemoteWrite/gra

Re: [prometheus-developers] Prometheus builds: Try Earthly?

[Vlad A. Ionescu]

👍

On Fri, Mar 19, 2021 at 1:41 AM Ben Kochie  wrote:

> Sorry, but this doesn't seem like any real improvement over the tooling we
> already have. We're already CI vendor portable. We converted from Travis to
> Circle long ago, our build steps just aren't that complicated. Everything
> is in a standardized Makefile system. Adding more abstraction wrappers
> isn't an improvement over GNU make.
>
> On Fri, Mar 19, 2021 at 2:21 AM Vlad A. Ionescu  wrote:
>
>> Hi Bjoern,
>>
>> Thanks for the pointers! I don’t think Earthly needs to necessarily
>> replace promu. Or at least not entirely, and not all at the same time.
>> Conceivably, it’s possible to set up Earthly to work kinda like a
>> pass-through for the promu commands.
>>
>> I’m not familiar with the challenges of the Prometheus build, so I’ll try
>> to list a few *possible* benefits. I’m shooting in the dark here -
>> emphasis on “possible” :-)
>>
>>- In general, build scripts not captured by promu run containerized
>>when ran through Earthly. This helps with keeping everything reproducible.
>>(Earthly can also run things natively
>>,
>>if that is needed - but it’s not the default). If promu is ran in Earthly,
>>then it can optionally run containerized, eliminating any
>>environment-specific variance.
>>- Changes to the CI scripts can be tested locally, thus helping with
>>the iteration speed when changing the build in any way.
>>- Integration tests for client libraries can execute in a
>>containerized environment. This helps with putting together the right
>>language-specific dependencies, and also possibly set up matrix testing, 
>> to
>>test against multiple versions of the client’s language. Such tests can
>>execute isolated from one-another and in parallel.
>>- For setups where many languages and repos interact with each other,
>>Earthly has very powerful cross-repo import mechanisms if needed to bring
>>everything together for integration testing. For example, if another
>>project needs promu, it can be as easy as something like COPY
>>github.com/prometheus/promu+promu/promu ./. You can also control
>>versioning, tags, branches, etc. through build args.
>>- Multi-platform support allows testing against other architectures
>>(e.g. arm64). In Earthly, this works really well via QEMU under the hood.
>>- If migrating from one CI vendor to another, migrating to Earthly
>>first helps abstract away the CI. This helps reduce CI vendor lock-in, in
>>case Circle decides to do what Travis did.
>>- Compute intensive steps (if there are any) can be cached and not
>>repeated if the inputs have not changed. In Earthly, this can work with a 
>> remote
>>cache  too.
>>
>> If any of this seems interesting, I’d be happy to put together a demo PR
>> to POC a particular benefit. Also open to hearing of any specific
>> challenges the community has with the build.
>>
>> Cheers,
>> Vlad.
>>
>> On Thu, Mar 18, 2021 at 8:43 AM Bjoern Rabenstein 
>> wrote:
>>
>>> On 17.03.21 11:43, Vlad A. Ionescu wrote:
>>> >
>>> > Not sure if this is the right place for this question. Wondering if
>>> anyone
>>> > is interested in trying https://github.com/earthly/earthly for the
>>> > Prometheus build.
>>> >
>>> > Earthly could help with reproducing CI failures locally (via
>>> containers)
>>> > and for performing multiple isolated integration tests in parallel.
>>> >
>>> > It works well on top of Circle CI.
>>>
>>> The Prometheus project has its own organically grown build system, see
>>> https://github.com/prometheus/promu , and rather elaborate CircleCI
>>> setup. Not saying that's a perfect solution, but any new solution
>>> needs to meet that bar, plus justify the effort and friction of
>>> changing by some added relevant value.
>>>
>>> From that perspective, perhaps the first step should be to clarify
>>> what would improve and what would change, and then convince
>>> stakeholders that they actually want and need the improvements.
>>>
>>> --
>>> 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-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/prometheus-developers/CAO_OUmMq9h4HAWxqOCnoWQjM5Eqb753iEpL%2B%3D%3DATfmx6mdHzBQ%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Prometheus Developers" group.
To unsubscribe from

Re: [prometheus-developers] Prometheus builds: Try Earthly?

[Ben Kochie]

Sorry, but this doesn't seem like any real improvement over the tooling we
already have. We're already CI vendor portable. We converted from Travis to
Circle long ago, our build steps just aren't that complicated. Everything
is in a standardized Makefile system. Adding more abstraction wrappers
isn't an improvement over GNU make.

On Fri, Mar 19, 2021 at 2:21 AM Vlad A. Ionescu  wrote:

> Hi Bjoern,
>
> Thanks for the pointers! I don’t think Earthly needs to necessarily
> replace promu. Or at least not entirely, and not all at the same time.
> Conceivably, it’s possible to set up Earthly to work kinda like a
> pass-through for the promu commands.
>
> I’m not familiar with the challenges of the Prometheus build, so I’ll try
> to list a few *possible* benefits. I’m shooting in the dark here -
> emphasis on “possible” :-)
>
>- In general, build scripts not captured by promu run containerized
>when ran through Earthly. This helps with keeping everything reproducible.
>(Earthly can also run things natively
>,
>if that is needed - but it’s not the default). If promu is ran in Earthly,
>then it can optionally run containerized, eliminating any
>environment-specific variance.
>- Changes to the CI scripts can be tested locally, thus helping with
>the iteration speed when changing the build in any way.
>- Integration tests for client libraries can execute in a
>containerized environment. This helps with putting together the right
>language-specific dependencies, and also possibly set up matrix testing, to
>test against multiple versions of the client’s language. Such tests can
>execute isolated from one-another and in parallel.
>- For setups where many languages and repos interact with each other,
>Earthly has very powerful cross-repo import mechanisms if needed to bring
>everything together for integration testing. For example, if another
>project needs promu, it can be as easy as something like COPY
>github.com/prometheus/promu+promu/promu ./. You can also control
>versioning, tags, branches, etc. through build args.
>- Multi-platform support allows testing against other architectures
>(e.g. arm64). In Earthly, this works really well via QEMU under the hood.
>- If migrating from one CI vendor to another, migrating to Earthly
>first helps abstract away the CI. This helps reduce CI vendor lock-in, in
>case Circle decides to do what Travis did.
>- Compute intensive steps (if there are any) can be cached and not
>repeated if the inputs have not changed. In Earthly, this can work with a 
> remote
>cache  too.
>
> If any of this seems interesting, I’d be happy to put together a demo PR
> to POC a particular benefit. Also open to hearing of any specific
> challenges the community has with the build.
>
> Cheers,
> Vlad.
>
> On Thu, Mar 18, 2021 at 8:43 AM Bjoern Rabenstein 
> wrote:
>
>> On 17.03.21 11:43, Vlad A. Ionescu wrote:
>> >
>> > Not sure if this is the right place for this question. Wondering if
>> anyone
>> > is interested in trying https://github.com/earthly/earthly for the
>> > Prometheus build.
>> >
>> > Earthly could help with reproducing CI failures locally (via containers)
>> > and for performing multiple isolated integration tests in parallel.
>> >
>> > It works well on top of Circle CI.
>>
>> The Prometheus project has its own organically grown build system, see
>> https://github.com/prometheus/promu , and rather elaborate CircleCI
>> setup. Not saying that's a perfect solution, but any new solution
>> needs to meet that bar, plus justify the effort and friction of
>> changing by some added relevant value.
>>
>> From that perspective, perhaps the first step should be to clarify
>> what would improve and what would change, and then convince
>> stakeholders that they actually want and need the improvements.
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CAO_OUmMq9h4HAWxqOCnoWQjM5Eqb753iEpL%2B%3D%3DATfmx6mdHzBQ%40mail.gmail.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://

Re: [prometheus-developers] Prometheus builds: Try Earthly?

[Vlad A. Ionescu]

Hi Bjoern,

Thanks for the pointers! I don’t think Earthly needs to necessarily replace
promu. Or at least not entirely, and not all at the same time. Conceivably,
it’s possible to set up Earthly to work kinda like a pass-through for the
promu commands.

I’m not familiar with the challenges of the Prometheus build, so I’ll try
to list a few *possible* benefits. I’m shooting in the dark here - emphasis
on “possible” :-)

   - In general, build scripts not captured by promu run containerized when
   ran through Earthly. This helps with keeping everything reproducible.
   (Earthly can also run things natively
   , if
   that is needed - but it’s not the default). If promu is ran in Earthly,
   then it can optionally run containerized, eliminating any
   environment-specific variance.
   - Changes to the CI scripts can be tested locally, thus helping with the
   iteration speed when changing the build in any way.
   - Integration tests for client libraries can execute in a containerized
   environment. This helps with putting together the right language-specific
   dependencies, and also possibly set up matrix testing, to test against
   multiple versions of the client’s language. Such tests can execute isolated
   from one-another and in parallel.
   - For setups where many languages and repos interact with each other,
   Earthly has very powerful cross-repo import mechanisms if needed to bring
   everything together for integration testing. For example, if another
   project needs promu, it can be as easy as something like COPY
   github.com/prometheus/promu+promu/promu ./. You can also control
   versioning, tags, branches, etc. through build args.
   - Multi-platform support allows testing against other architectures
   (e.g. arm64). In Earthly, this works really well via QEMU under the hood.
   - If migrating from one CI vendor to another, migrating to Earthly first
   helps abstract away the CI. This helps reduce CI vendor lock-in, in case
   Circle decides to do what Travis did.
   - Compute intensive steps (if there are any) can be cached and not
   repeated if the inputs have not changed. In Earthly, this can work
with a remote
   cache  too.

If any of this seems interesting, I’d be happy to put together a demo PR to
POC a particular benefit. Also open to hearing of any specific challenges
the community has with the build.

Cheers,
Vlad.

On Thu, Mar 18, 2021 at 8:43 AM Bjoern Rabenstein 
wrote:

> On 17.03.21 11:43, Vlad A. Ionescu wrote:
> >
> > Not sure if this is the right place for this question. Wondering if
> anyone
> > is interested in trying https://github.com/earthly/earthly for the
> > Prometheus build.
> >
> > Earthly could help with reproducing CI failures locally (via containers)
> > and for performing multiple isolated integration tests in parallel.
> >
> > It works well on top of Circle CI.
>
> The Prometheus project has its own organically grown build system, see
> https://github.com/prometheus/promu , and rather elaborate CircleCI
> setup. Not saying that's a perfect solution, but any new solution
> needs to meet that bar, plus justify the effort and friction of
> changing by some added relevant value.
>
> From that perspective, perhaps the first step should be to clarify
> what would improve and what would change, and then convince
> stakeholders that they actually want and need the improvements.
>
> --
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAO_OUmMq9h4HAWxqOCnoWQjM5Eqb753iEpL%2B%3D%3DATfmx6mdHzBQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus builds: Try Earthly?

[Bjoern Rabenstein]

On 17.03.21 11:43, Vlad A. Ionescu wrote:
> 
> Not sure if this is the right place for this question. Wondering if anyone
> is interested in trying https://github.com/earthly/earthly for the
> Prometheus build.
> 
> Earthly could help with reproducing CI failures locally (via containers)
> and for performing multiple isolated integration tests in parallel.
> 
> It works well on top of Circle CI.

The Prometheus project has its own organically grown build system, see
https://github.com/prometheus/promu , and rather elaborate CircleCI
setup. Not saying that's a perfect solution, but any new solution
needs to meet that bar, plus justify the effort and friction of
changing by some added relevant value.

>From that perspective, perhaps the first step should be to clarify
what would improve and what would change, and then convince
stakeholders that they actually want and need the improvements.

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

Re: [prometheus-developers] Prometheus integration with RESt API

[Julien Pivotto]

On 02 Feb 23:10, Stuart Clark wrote:
> On 02/02/2021 15:45, s.saurab...@gmail.com wrote:
> > 
> > Hi Everyone ...
> > 
> > Is it possible to integrate target device whose REST API is exposed with
> > prometheus ??? Pls suggest options if possible.
> > 
> Are you meaning that you are wanting to fetch metrics from this REST API?
> 
> If so, this is where an exporter would be used. In whichever language you
> choose and the appropriate Prometheus client library you can call your API
> to fetch the metrics and then reply to Prometheus. You would then be able to
> scrape those metrics.

Hello,

If you do no own the API, the json_exporter might also help:

https://github.com/prometheus-community/json_exporter

Regards,

> 
> -- 
> Stuart Clark
> 
> -- 
> 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/53edf054-ea50-9125-c6eb-6e96140f497f%40Jahingo.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/20210203222834.GA1600032%40oxygen.

Re: [prometheus-developers] Prometheus integration with RESt API

[Stuart Clark]

On 02/02/2021 15:45, s.saurab...@gmail.com wrote:


Hi Everyone ...

Is it possible to integrate target device whose REST API is exposed 
with prometheus ??? Pls suggest options if possible.



Are you meaning that you are wanting to fetch metrics from this REST API?

If so, this is where an exporter would be used. In whichever language 
you choose and the appropriate Prometheus client library you can call 
your API to fetch the metrics and then reply to Prometheus. You would 
then be able to scrape those metrics.


--
Stuart Clark

--
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/53edf054-ea50-9125-c6eb-6e96140f497f%40Jahingo.com.

Re: [prometheus-developers] Prometheus

[Tobias Schmidt]

Dear Brian,

Thank you so much for all your guidance, contributions and work you have
done! I still remember when Julius announced to me so many years ago that
there is the first external non-SoundCloud developer with an interest in
the project. And you didn't just show an interest in using the - still very
limited - system we had back then, you immediately provided a very clear
vision and guidance. Without all your thoughts and public work you and your
company have done Prometheus would not be what it is today.

I wish you all the best for the future!
Tobi

On Thu, Jan 28, 2021 at 11:22 AM Brian Brazil <
brian.bra...@robustperception.io> wrote:

> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
> commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on
> other things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/CAChBsdC7hzMvca%3DwikPBmsfpkj1gEAdWm2gsCgGOGk-RtPmdkg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Mat Arye]

Thank you Brian! You've obviously done a lot for the Prometheus project
itself. What may be less known, is all the effort you've put in to make it
welcoming to outside projects like ours.

I cannot tell you how appreciative  we are that you looked at our design
docs and answered our questions. That's part of what makes Prometheus such
a giant in the open-source world, and why so many other projects have been
able to develop around it. Thank you - again.



On Thu, Jan 28, 2021 at 5:22 AM Brian Brazil <
brian.bra...@robustperception.io> wrote:

> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
> commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on
> other things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.com
> 
> .
>


-- 
Mat Arye, Promscale  Team Lead

-- 
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/CADsUR0C8PO8tt%3D279UtBwjCFy7Rstj9eSuXmk4%2BJ5vV3KsvbMw%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Hrishikesh Barman]

Thankyou Brian for everything, all the best for your upcoming journey :)


Best

On Thu, Jan 28, 2021, 3:52 PM Brian Brazil 
wrote:

> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
> commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on
> other things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/CA%2BWE-n_DjKji4SAmCS%3DZqmHMtf_sshzqgHHL8heK0mnOV2hyXA%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Bartłomiej Płotka]

Thank You so much Brian for your effort and passion for this project and
Ecosystem. You have been an amazing help and great inspiration for all of
us on many aspects. I learned from you many things: design patterns, Go,
performance, indexing, SRE and more.

Hope you don't mind me asking for review/suggestions and advice from time
to time! (:

Kind Regards,
Bartek Płotka (@bwplotka)


On Fri, 29 Jan 2021 at 13:11, Ritesh Shrivastav 
wrote:

> Thank you for all the work you've done on Prometheus. All the best for
> your next endeavors!
>
> --
> Best,
> Ritesh Shrivastav
> LinkedIn , Twitter
> , Web
> 
>
> On Thu, Jan 28, 2021 at 3:52 PM Brian Brazil <
> brian.bra...@robustperception.io> wrote:
>
>> Hi all,
>>
>> I first got involved in Prometheus back in 2014 when I was looking for a
>> monitoring system, and nothing that was out there seemed to quite cut it.
>> Since then I've worked across and helped expand the ecosystem. I've
>> reviewed
>> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
>> commits
>> myself. I've created exporters and client libraries, wrote extensive
>> docs, and made
>> a multitude of improvements to Prometheus from performance to features.
>>
>> All of this takes a non-trivial amount of my time, and there's more to
>> life
>> than maintaining open source projects. Accordingly I have decided to step
>> back
>> and resign from prometheus-team, in order to focus my efforts more on
>> other things
>> including Robust Perception.
>> I will of course still be part of the ecosystem, helping out fixing bugs,
>> answering
>> questions, and so on. While I look forward to reducing my workload, I
>> know Prometheus
>> will remain in good hands.
>>
>> Yours,
>> --
>> Brian Brazil
>> www.robustperception.io
>>
>> --
>> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/CAOc9pBmPGCVM6t6%2BMvsUVC2uroykqDDtyn_D4TAF6rurpg2tzg%40mail.gmail.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/CAMssQwYyWjakWd4xDHerzONmvozPQSZMgSrByEvtgQ8r8P-hpQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Ritesh Shrivastav]

Thank you for all the work you've done on Prometheus. All the best for your
next endeavors!

-- 
Best,
Ritesh Shrivastav
LinkedIn , Twitter
, Web


On Thu, Jan 28, 2021 at 3:52 PM Brian Brazil <
brian.bra...@robustperception.io> wrote:

> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
> commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on
> other things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/CAOc9pBmPGCVM6t6%2BMvsUVC2uroykqDDtyn_D4TAF6rurpg2tzg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Ben Kochie]

Thanks Brian!

We wouldn't have Prometheus as it is today without you.

On Thu, Jan 28, 2021 at 11:22 AM Brian Brazil <
brian.bra...@robustperception.io> wrote:

> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
> commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on
> other things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/CABbyFmqW4rMNGigNAb7iQ2-Eu-srmZVGZtxWU3dXJmsc5HJvtw%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Simon Pasquier]

thanks.Add(1000.0)

Brian, many many thanks for your dedication and patience. Without your
involvement, Prometheus wouldn't be where it stands now. This is an
amazing feat that you can be proud of.
Personally I've learned a lot from you and I'll keep being inspired by
your thorough reviews.
Wish you all the best for the future, I'm sure our paths will cross again :)
Simon

Le jeu. 28 janv. 2021 à 11:22, Brian Brazil
 a écrit :
>
> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867 commits
> myself. I've created exporters and client libraries, wrote extensive docs, 
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step back
> and resign from prometheus-team, in order to focus my efforts more on other 
> things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs, 
> answering
> questions, and so on. While I look forward to reducing my workload, I know 
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/CAPrrXecSZ6nB9%2BU5RMgxShmWfjQfX79Lc0HvoR5DQGVep5r7Dw%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Julius Volz]

Hi Brian,

Thank you so much for the herculean work you did to push Prometheus forward
and to guide the project over the many years. All the best for your next
endeavors!

Regards,
Julius

On Thu, Jan 28, 2021 at 11:22 AM Brian Brazil <
brian.bra...@robustperception.io> wrote:

> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
> commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on
> other things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.com
> 
> .
>


-- 
Julius Volz
PromLabs - promlabs.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/CAObpH5xQxOjcLU8rz-LzezHruHNNLET4wFtqcFkpGe3eTa1PeQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Chris Marchbanks]

Thank you Brian for everything you have contributed over the years! Your
dedication to the project was impressive, and I appreciate everything I
have learned from my interactions with you.

I wish you success on your current and future projects,
Chris

On Thu, Jan 28, 2021 at 3:22 AM Brian Brazil <
brian.bra...@robustperception.io> wrote:

> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
> commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on
> other things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/CANVFovWGoLodTPbkF2GoAT_G_gaZGtXm8ECEbfae6_gqN3Peog%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Stuart Clark]

On 28/01/2021 10:21, Brian Brazil wrote:

Hi all,

I first got involved in Prometheus back in 2014 when I was looking for a
monitoring system, and nothing that was out there seemed to quite cut it.
Since then I've worked across and helped expand the ecosystem. I've 
reviewed
and merged 2542 PRs, in addition to creating 670 PRs containing 1867 
commits
myself. I've created exporters and client libraries, wrote extensive 
docs, and made

a multitude of improvements to Prometheus from performance to features.

All of this takes a non-trivial amount of my time, and there's more to 
life
than maintaining open source projects. Accordingly I have decided to 
step back
and resign from prometheus-team, in order to focus my efforts more on 
other things

including Robust Perception.
I will of course still be part of the ecosystem, helping out fixing 
bugs, answering
questions, and so on. While I look forward to reducing my workload, I 
know Prometheus

will remain in good hands.


I'd like to echo the comments from all the people who have themselves 
done so much for Prometheus. You have helped in so many ways and in my 
mind are one of the faces I picture when thinking of Prometheus. You 
will be missed, but I look forward to seeing you around once travel is 
legal again.


--
Stuart Clark

--
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/7d02cf4a-85b7-0bda-0cd9-a8f87cb4c902%40Jahingo.com.

Re: [prometheus-developers] Prometheus

[Benjamin Ridley]

Brian, your efforts with Prometheus have been a paragon of open source
maintainership. Your presence will be greatly missed, and of course thank
you for all your hard work.

Cheers,
Ben

On Thu, 28 Jan 2021, 9:22 pm Brian Brazil, 
wrote:

> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
> commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on
> other things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/CABaapwK%2B6wJekkjuVw6rTS_jc5vUm9Kg9dDUHJtK42j97U%2Bddg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Goutham Veeramachaneni]

Dear Brian,

Thank you for all the work you've done on Prometheus but also all the 
personal impact you've had on me. You've helped me understand Prometheus, 
with reviews and in general all the times we've interacted. But beyond 
that, I've learnt a lot from you and you've inspired me many times!

I wish you all the best in your endeavors and hopefully we'll work together 
again.

Thanks again <3
Goutham.

On Thursday, January 28, 2021 at 1:09:01 PM UTC+1 Richard Hartmann wrote:

> Dear Brian,
>
>
> it's hard to overstate the impact you have made on Prometheus and its
> ecosystem over the years.
>
>
> Thank you.
>
> Thank you for your tireless work.
>
> Thank you for your dedication to the project.
>
>
> I look forward to sharing a beer, or ten, with you; and maybe tricking
> you into singing,
> best,
> Richard
>

-- 
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/11e24405-ecc4-455b-bc9f-81d2b5ab21c6n%40googlegroups.com.

Re: [prometheus-developers] Prometheus

[Richard Hartmann]

Dear Brian,


it's hard to overstate the impact you have made on Prometheus and its
ecosystem over the years.


Thank you.

Thank you for your tireless work.

Thank you for your dedication to the project.


I look forward to sharing a beer, or ten, with you; and maybe tricking
you into singing,
best,
Richard

-- 
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/CAD77%2BgSmiP9wp29xSL3zaO8O%3DHHNME8DGiyeyVUPu0QtgRKOXQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus

[Julien Pivotto]

Thank you Brian for everything!

On 28 Jan 10:21, Brian Brazil wrote:
> Hi all,
> 
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867 commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
> 
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on other
> things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
> 
> Yours,
> -- 
> Brian Brazil
> www.robustperception.io
> 
> -- 
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/20210128113839.GA354583%40oxygen.

Re: [prometheus-developers] Prometheus

[NeT MonK]

Thank you Brian, for all you did and the great work you achieved.


On Thu, Jan 28, 2021 at 11:22 AM Brian Brazil <
brian.bra...@robustperception.io> wrote:

> Hi all,
>
> I first got involved in Prometheus back in 2014 when I was looking for a
> monitoring system, and nothing that was out there seemed to quite cut it.
> Since then I've worked across and helped expand the ecosystem. I've
> reviewed
> and merged 2542 PRs, in addition to creating 670 PRs containing 1867
> commits
> myself. I've created exporters and client libraries, wrote extensive docs,
> and made
> a multitude of improvements to Prometheus from performance to features.
>
> All of this takes a non-trivial amount of my time, and there's more to life
> than maintaining open source projects. Accordingly I have decided to step
> back
> and resign from prometheus-team, in order to focus my efforts more on
> other things
> including Robust Perception.
> I will of course still be part of the ecosystem, helping out fixing bugs,
> answering
> questions, and so on. While I look forward to reducing my workload, I know
> Prometheus
> will remain in good hands.
>
> Yours,
> --
> Brian Brazil
> www.robustperception.io
>
> --
> 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/CAHJKeLrqLd5BYVZKvrW-A7MW%3DZksB9qP4Lk%3Dt2BLK-CcVok%2BrA%40mail.gmail.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/CAP%3DC6_uoGW0z%2B2uAy3Chjb5u7i%2BMmGzEnhgCSEcXs-KQ5uMTVQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus ecosystem certification

['Evelyn Pereira Souza' via Prometheus Developers]

On 19.11.20 21:07, Julius Volz wrote:

Hi,


Hi Julius

(please keep me CC-ed in addition to the list, otherwise I won't notice 
replies, thus sorry for the late reply)


Yeah, we had a call, and we will look for a number of subject matter 
experts both within the Prometheus Team and externally who are 
interested in joining the effort. We need to first put together a 
blueprint of what the certification should cover (like the outline you 
see at 
https://training.linuxfoundation.org/certification/linux-foundation-certified-sysadmin-lfcs/ 
 
under "Domains and Competencies"), and then as a second stage, come up 
with detailed certification question items for a multiple-choice exam 
that will be administered by the Linux Foundation.


1 month later do you have a draft version of the objectives? Can I apply 
for training budget 2021 already (Prometheus certification) in my company?


Regarding the tracks, it's up to us in a lot of ways, but it seems like 
we will build a single certification first to trial the demand, and we 
still have to determine how to draw the line between user, admin, and 
developer, because those roles often overlap in the Prometheus use case. 
If you have opinions on that, do let us know!


I only hope there is "please write an exporter in GO" type questions ;-)


Regards,
Julius


best regards
Evelyn

--
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/796d68b2-320a-df47-2beb-c74a127e13e7%40disroot.org.


OpenPGP_0x61776FA8E38403FB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [prometheus-developers] Prometheus ecosystem certification

[Julius Volz]

Hi,

(please keep me CC-ed in addition to the list, otherwise I won't notice
replies, thus sorry for the late reply)

Yeah, we had a call, and we will look for a number of subject matter
experts both within the Prometheus Team and externally who are interested
in joining the effort. We need to first put together a blueprint of what
the certification should cover (like the outline you see at
https://training.linuxfoundation.org/certification/linux-foundation-certified-sysadmin-lfcs/
under "Domains and Competencies"), and then as a second stage, come up with
detailed certification question items for a multiple-choice exam that will
be administered by the Linux Foundation.

Regarding the tracks, it's up to us in a lot of ways, but it seems like we
will build a single certification first to trial the demand, and we still
have to determine how to draw the line between user, admin, and
developer, because those roles often overlap in the Prometheus use case. If
you have opinions on that, do let us know!

Regards,
Julius

On Tue, Nov 17, 2020 at 1:23 PM 'Evelyn Pereira Souza' via Prometheus
Developers  wrote:

> On 12.11.20 15:28, Julius Volz wrote:
> > Yes we started, but will have a more detailed discussion with the Linux
> > Foundation on Monday. So far it sounds like a realistic expectation of
> > having a certification process in place is around half a year or so.
>
> Hi Julius
>
> thanks.
>
> are there any news from the Linux Foundation or further details? Will
> there be a separate Ops and Dev track?
>
> regards
> Evelyn
>
> --
> 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/08f4548c-00db-6d97-277e-48d5c7faf5bc%40disroot.org
> .
>


-- 
Julius Volz
PromLabs - promlabs.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/CAObpH5x6h3vYXYHSPMhr4f5TVfOs%2BvXiuehF0twLvaXMuj4qzg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus ecosystem certification

['Evelyn Pereira Souza' via Prometheus Developers]

On 12.11.20 15:28, Julius Volz wrote:
Yes we started, but will have a more detailed discussion with the Linux 
Foundation on Monday. So far it sounds like a realistic expectation of 
having a certification process in place is around half a year or so.


Hi Julius

thanks.

are there any news from the Linux Foundation or further details? Will 
there be a separate Ops and Dev track?


regards
Evelyn

--
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/08f4548c-00db-6d97-277e-48d5c7faf5bc%40disroot.org.


OpenPGP_0x61776FA8E38403FB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [prometheus-developers] Prometheus ecosystem certification

[Julius Volz]

On Wed, Nov 11, 2020 at 4:14 PM 'Evelyn Pereira Souza' via Prometheus
Developers  wrote:

> On 04.11.20 20:08, Julius Volz wrote:
> > It's hard to put an ETA on it currently. We are interested, but still
> > evaluating who will do this, and when. Let me try and get back to you in
> > a couple of days or so.
>
> Did you discuss?
>

Yes we started, but will have a more detailed discussion with the Linux
Foundation on Monday. So far it sounds like a realistic expectation of
having a certification process in place is around half a year or so.

-- 
Julius Volz
PromLabs - promlabs.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/CAObpH5xnqmsG-5e9TC3_Y-0tZ4XekdgGqGDk7kXJ5_K0DuGKjg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus ecosystem certification

['Evelyn Pereira Souza' via Prometheus Developers]

On 04.11.20 20:08, Julius Volz wrote:
It's hard to put an ETA on it currently. We are interested, but still 
evaluating who will do this, and when. Let me try and get back to you in 
a couple of days or so.


Did you discuss?

--
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/a5545646-5c86-8d46-4f38-5a3a1c35fd84%40disroot.org.


OpenPGP_0x61776FA8E38403FB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [prometheus-developers] Prometheus ecosystem certification

[Harry Perks]

I'd be very interested in courses for both admins and developers. The main 
driver being to establish a common framework / baseline understanding 
around Prometheus training, similar to the Kubernetes certifications. At 
Sysdig we have internal Prometheus training focused on developers that I'd 
love to build out further. 

On Wednesday, November 4, 2020 at 11:08:32 AM UTC-8 juliu...@promlabs.com 
wrote:

> Hi Evelyn,
>
> No worries, yeah, we understand it can be important for organizations' 
> requirements and people's CVs, even if a non-certified training can teach 
> the same knowledge.
>
> It's hard to put an ETA on it currently. We are interested, but still 
> evaluating who will do this, and when. Let me try and get back to you in a 
> couple of days or so.
>
> Regards,
> Julius
>
> On Wed, Nov 4, 2020 at 7:54 PM Evelyn Pereira Souza  
> wrote:
>
>> On 04.11.20 15:57, Julius Volz wrote:
>> > Hi Evelyn,
>>
>> Hi Julius
>>
>> > We discussed exactly this a couple of weeks ago with the CNCF, and 
>> we're 
>> > generally very interested in it. The Prometheus OSS project would have 
>> > to define standard certification criteria, and then companies (like 
>> > PromLabs, Robust Perception, or others) could offer training material 
>> > and administer the certification tests. We just haven't gotten around 
>> to 
>> > it yet, as there is always a lot to do. But I'll check in again with 
>> > people about it, and hopefully at some point we will manage to 
>> > build such a certification.
>>
>> Very good news. I'm glad to hear it. Very glad that you developers 
>> support this. Many developers don't like certifications. What do you 
>> think is the time horizon when appropriate training will be available?
>>
>> > Regards,
>> > Julius
>>
>> regards
>> Evelyn
>>
>
>
> -- 
> Julius Volz
> PromLabs - promlabs.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/81a37b64-c4cb-412a-a67c-707be23bd802n%40googlegroups.com.

Re: [prometheus-developers] Prometheus ecosystem certification

[Julius Volz]

Hi Evelyn,

No worries, yeah, we understand it can be important for organizations'
requirements and people's CVs, even if a non-certified training can teach
the same knowledge.

It's hard to put an ETA on it currently. We are interested, but still
evaluating who will do this, and when. Let me try and get back to you in a
couple of days or so.

Regards,
Julius

On Wed, Nov 4, 2020 at 7:54 PM Evelyn Pereira Souza 
wrote:

> On 04.11.20 15:57, Julius Volz wrote:
> > Hi Evelyn,
>
> Hi Julius
>
> > We discussed exactly this a couple of weeks ago with the CNCF, and we're
> > generally very interested in it. The Prometheus OSS project would have
> > to define standard certification criteria, and then companies (like
> > PromLabs, Robust Perception, or others) could offer training material
> > and administer the certification tests. We just haven't gotten around to
> > it yet, as there is always a lot to do. But I'll check in again with
> > people about it, and hopefully at some point we will manage to
> > build such a certification.
>
> Very good news. I'm glad to hear it. Very glad that you developers
> support this. Many developers don't like certifications. What do you
> think is the time horizon when appropriate training will be available?
>
> > Regards,
> > Julius
>
> regards
> Evelyn
>


-- 
Julius Volz
PromLabs - promlabs.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/CAObpH5wLo4aG_WUhsc-rA%3D07arf17nj3ipENics9fdQV-2YN%2Bg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus ecosystem certification

['Evelyn Pereira Souza' via Prometheus Developers]

On 04.11.20 15:57, Julius Volz wrote:

Hi Evelyn,


Hi Julius

We discussed exactly this a couple of weeks ago with the CNCF, and we're 
generally very interested in it. The Prometheus OSS project would have 
to define standard certification criteria, and then companies (like 
PromLabs, Robust Perception, or others) could offer training material 
and administer the certification tests. We just haven't gotten around to 
it yet, as there is always a lot to do. But I'll check in again with 
people about it, and hopefully at some point we will manage to 
build such a certification.


Very good news. I'm glad to hear it. Very glad that you developers 
support this. Many developers don't like certifications. What do you 
think is the time horizon when appropriate training will be available?



Regards,
Julius


regards
Evelyn

--
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/ca3969be-06e9-0908-0069-9e2658cf9797%40disroot.org.


OpenPGP_0x61776FA8E38403FB.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [prometheus-developers] Prometheus ecosystem certification

[Julius Volz]

Hi Evelyn,

We discussed exactly this a couple of weeks ago with the CNCF, and we're
generally very interested in it. The Prometheus OSS project would have to
define standard certification criteria, and then companies (like PromLabs,
Robust Perception, or others) could offer training material and administer
the certification tests. We just haven't gotten around to it yet, as there
is always a lot to do. But I'll check in again with people about it, and
hopefully at some point we will manage to build such a certification.

Regards,
Julius

On Wed, Nov 4, 2020 at 1:34 PM 'Evelyn Pereira Souza' via Prometheus
Developers  wrote:

> Hi
>
> Prometheus is also under the roof of CNCF. For Kubernetes there are
> several prestigious certifications. Nice is that there are separate
> courses for admins and developers.
>
> Is something like this planned for Prometheus? Has something like this
> already been discussed?
>
> I would be very happy if I could take an exam for Prometheus. I am sure
> it will be very good for the resume.
>
> Evelyn
>
> --
> 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/598b9b4e-823c-42be-9cfd-5a4eff010169%40disroot.org
> .
>


-- 
Julius Volz
PromLabs - promlabs.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/CAObpH5yJs5%2BMCSTe1Gy0%3DOeSgco82UAi3JR7OwF-DVqOQ9V%3DkA%40mail.gmail.com.

Re: [prometheus-developers] Prometheus virtual dev summit 2020 3 meeting notes are now public

[Brian Brazil]

On Fri, 30 Oct 2020 at 13:15, Arthur Silva Sens 
wrote:

> Hi Richard,
>
> Thanks for letting this public! I was reading through the document and one
> thing came up to my mind. About Exemplars:
> CONSENSUS:  In-memory storage is acceptable for a first iteration.
>
> Exemplars will be kept in-memory? I imagine that this will have a big
> impact if we expose a huge amount of exemplars, right? When instrumenting
> my app, should I do sampling with exemplars?
>

The plan for this stage is to have an in-memory ring buffer, so the storage
space is bounded and also configurable. You shouldn't change anything about
how you use examplars in your app for this.

Brian


>
> Kind regards,
> Arthur
>
> Em sex., 30 de out. de 2020 às 06:08, Richard Hartmann <
> richih.mailingl...@gmail.com> escreveu:
>
>> Dear all,
>>
>> please see
>> https://docs.google.com/document/d/18Jbl5LC_FPLqCqU12qY8XpjVMJLCtGt-ykbyAhYXcIc
>>
>> Best,
>> Richard
>>
>> --
>> 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/CAD77%2BgTQOgcbzhfzv_9UxdXCE1gPfUZTChY_LQsxaYS8_%3DrsXg%40mail.gmail.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/CAJqZosz30Jbt_dXJPL0j-6a0zMN_z-uRe9bCy6%3D%2B62v3S6uqWw%40mail.gmail.com
> 
> .
>


-- 
Brian Brazil
www.robustperception.io

-- 
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/CAHJKeLr2PNx2XhgkkSA6ZZ-MFsHqOhP-LFdCGY7qUvntiZaoLw%40mail.gmail.com.

Re: [prometheus-developers] Prometheus virtual dev summit 2020 3 meeting notes are now public

[Arthur Silva Sens]

Hi Richard,

Thanks for letting this public! I was reading through the document and one
thing came up to my mind. About Exemplars:
CONSENSUS:  In-memory storage is acceptable for a first iteration.

Exemplars will be kept in-memory? I imagine that this will have a big
impact if we expose a huge amount of exemplars, right? When instrumenting
my app, should I do sampling with exemplars?

Kind regards,
Arthur

Em sex., 30 de out. de 2020 às 06:08, Richard Hartmann <
richih.mailingl...@gmail.com> escreveu:

> Dear all,
>
> please see
> https://docs.google.com/document/d/18Jbl5LC_FPLqCqU12qY8XpjVMJLCtGt-ykbyAhYXcIc
>
> Best,
> Richard
>
> --
> 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/CAD77%2BgTQOgcbzhfzv_9UxdXCE1gPfUZTChY_LQsxaYS8_%3DrsXg%40mail.gmail.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/CAJqZosz30Jbt_dXJPL0j-6a0zMN_z-uRe9bCy6%3D%2B62v3S6uqWw%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Persistence Volume(Kubernetes)

[Tim Schwenke]

I can recommend you to run Cadvisor. This will give you a whole set of CPU 
metrics that enable you to have a more detailed insight. You will probably 
notice that the memory cache is the one that just keeps increasing, 
especially after a bunch of queries. 

prabin...@gmail.com schrieb am Donnerstag, 24. September 2020 um 09:46:07 
UTC+2:

> Thanks for your reply
> Is there any way to know the maximum persistence volume , as we need to 
> fix a resource quota for prometheus in kubernetes.
>
> On Wednesday, 23 September 2020 at 20:27:50 UTC+5:30 bjo...@rabenste.in 
> wrote:
>
>> On 21.09.20 00:27, prabin...@gmail.com wrote: 
>> > Memory Consumed by prometheus is keep on increasing day by day . Though 
>> Number 
>> > of Targets are same. 
>>
>> Yes, Prometheus uses as much RAM as possible for mmap'ing, making your 
>> queries faster. 
>>
>> > What is is the persistence volume of prometheus , or how we can 
>> evaluate the 
>> > same and limit our memory consumtion. 
>>
>> You don't have to. When the OS needs the RAM, it will simply take it 
>> away from Prometheus. 
>>
>> There is a certain amount of memory that Prometheus needs to exist. If 
>> you don't have enough for that, it will OOM. 
>>
>> You can look at 
>>
>> https://www.robustperception.io/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestion
>>  
>> , although a lot has been optimized over the last 1.5 years since that 
>> article was published. 
>>
>> -- 
>> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/4bbb539a-b1bb-431c-b5de-22dbcebb9450n%40googlegroups.com.

Re: [prometheus-developers] Prometheus Persistence Volume(Kubernetes)

[prabin...@gmail.com]

Thanks for your reply
Is there any way to know the maximum persistence volume , as we need to fix 
a resource quota for prometheus in kubernetes.

On Wednesday, 23 September 2020 at 20:27:50 UTC+5:30 bjo...@rabenste.in 
wrote:

> On 21.09.20 00:27, prabin...@gmail.com wrote:
> > Memory Consumed by prometheus is keep on increasing day by day . Though 
> Number
> > of Targets are same.
>
> Yes, Prometheus uses as much RAM as possible for mmap'ing, making your
> queries faster.
>
> > What is is the persistence volume of prometheus , or how we can evaluate 
> the
> > same and limit our memory consumtion.
>
> You don't have to. When the OS needs the RAM, it will simply take it
> away from Prometheus.
>
> There is a certain amount of memory that Prometheus needs to exist. If
> you don't have enough for that, it will OOM.
>
> You can look at
>
> https://www.robustperception.io/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestion
> , although a lot has been optimized over the last 1.5 years since that
> article was published.
>
> -- 
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/76d58060-eca8-45bb-970d-f9d7588d124bn%40googlegroups.com.

Re: [prometheus-developers] Prometheus Persistence Volume(Kubernetes)

[Bjoern Rabenstein]

On 21.09.20 00:27, prabin...@gmail.com wrote:
> Memory Consumed by prometheus is keep on increasing day by day . Though Number
> of  Targets are same.

Yes, Prometheus uses as much RAM as possible for mmap'ing, making your
queries faster.

> What is is the persistence volume of prometheus , or how we can evaluate the
> same and limit our memory consumtion.

You don't have to. When the OS needs the RAM, it will simply take it
away from Prometheus.

There is a certain amount of memory that Prometheus needs to exist. If
you don't have enough for that, it will OOM.

You can look at
https://www.robustperception.io/how-much-ram-does-prometheus-2-x-need-for-cardinality-and-ingestion
, although a lot has been optimized over the last 1.5 years since that
article was published.

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

Re: [prometheus-developers] Prometheus Storage Working Group

[Callum Styan]

I'd be interested in joining but the earliest I could do is around 1400 GMT
(I'm GMT-7 currently). If I'm the only one who can't make the time you're
proposing then that's okay, it's hard to schedule things at times that both
Ganesh and I can attend :)

On Mon, Sep 7, 2020 at 7:06 AM Manish G 
wrote:

> I am keen to be part of the initiative, but am relatively new to
> prometheus.
>
> With regards
>
> On Mon, Sep 7, 2020 at 4:28 PM fbra...@gmail.com 
> wrote:
>
>> Hello Prometheans,
>>
>> There have been various ideas around potentially improving parts of
>> Prometheus' TSDB. I would like to start a working group that meets
>> regularly around these topics and compares notes, researches, and
>> experiments with potential improvements and hopefully ultimately develop
>> designs to be proposed as improvements to Prometheus.
>>
>> I've been talking to Ganesh about this topic a bit and we've put together
>> a small starting document to kick this off:
>> https://docs.google.com/document/d/1HWL-NIfog3_pFxUny0kAHeoxd0grnqhCBcHVPZN4y3Y/edit?usp=sharing
>>
>> The idea, for now, is to meet at a biweekly cadence at 9 AM GMT for 30
>> minutes, a link to the meeting is in the above document. (this works for
>> Ganesh and me, we're open to rescheduling this and or extending this if
>> needed)
>>
>> The first meeting for this is scheduled for the 22nd of September. There
>> will be meeting notes, so if you're just interested in the results read
>> those, if you're interested in contributing to these topics join us! :)
>>
>> Best regards,
>> Frederic
>>
>> --
>> 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/ab025c6f-c37d-44e0-8dba-455ac9c1fadfn%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/CAOFd6ii279fV0XBxU5H0Ra4h3iuNmkxFt1QYY_%3D96kGnaOxKBQ%40mail.gmail.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/CAN2d5ORgRyN%2BkXjj8Qe7HmRZERmuMfSyWTFnnfjXpW4Ms1%3DWcw%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Storage Working Group

[Manish G]

I am keen to be part of the initiative, but am relatively new to prometheus.

With regards

On Mon, Sep 7, 2020 at 4:28 PM fbra...@gmail.com 
wrote:

> Hello Prometheans,
>
> There have been various ideas around potentially improving parts of
> Prometheus' TSDB. I would like to start a working group that meets
> regularly around these topics and compares notes, researches, and
> experiments with potential improvements and hopefully ultimately develop
> designs to be proposed as improvements to Prometheus.
>
> I've been talking to Ganesh about this topic a bit and we've put together
> a small starting document to kick this off:
> https://docs.google.com/document/d/1HWL-NIfog3_pFxUny0kAHeoxd0grnqhCBcHVPZN4y3Y/edit?usp=sharing
>
> The idea, for now, is to meet at a biweekly cadence at 9 AM GMT for 30
> minutes, a link to the meeting is in the above document. (this works for
> Ganesh and me, we're open to rescheduling this and or extending this if
> needed)
>
> The first meeting for this is scheduled for the 22nd of September. There
> will be meeting notes, so if you're just interested in the results read
> those, if you're interested in contributing to these topics join us! :)
>
> Best regards,
> Frederic
>
> --
> 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/ab025c6f-c37d-44e0-8dba-455ac9c1fadfn%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/CAOFd6ii279fV0XBxU5H0Ra4h3iuNmkxFt1QYY_%3D96kGnaOxKBQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Storage Working Group

[fbra...@gmail.com]

I changed the link to be a public calendar with the calendar item in it 
instead. I've been confirmed, that that works.

On Monday, 7 September 2020 at 14:17:35 UTC+2 gout...@gmail.com wrote:

> Love the initiative, thanks for spearheading this! I have it in my OKRs to 
> explore and write up a design doc (just the usecases we want to support, 
> not the implementation details) around this and you've just made my life 
> mch easier :D 9AM GMT Mondays works for me as well!
>
> I am not able to access the calendar link though, is it just me or does it 
> not work for others as well?
>
> Thanks,
> Goutham.
>
> On Mon, Sep 7, 2020 at 12:58 PM fbra...@gmail.com  
> wrote:
>
>> Hello Prometheans,
>>
>> There have been various ideas around potentially improving parts of 
>> Prometheus' TSDB. I would like to start a working group that meets 
>> regularly around these topics and compares notes, researches, and 
>> experiments with potential improvements and hopefully ultimately develop 
>> designs to be proposed as improvements to Prometheus.
>>
>> I've been talking to Ganesh about this topic a bit and we've put together 
>> a small starting document to kick this off: 
>> https://docs.google.com/document/d/1HWL-NIfog3_pFxUny0kAHeoxd0grnqhCBcHVPZN4y3Y/edit?usp=sharing
>>
>> The idea, for now, is to meet at a biweekly cadence at 9 AM GMT for 30 
>> minutes, a link to the meeting is in the above document. (this works for 
>> Ganesh and me, we're open to rescheduling this and or extending this if 
>> needed)
>>
>> The first meeting for this is scheduled for the 22nd of September. There 
>> will be meeting notes, so if you're just interested in the results read 
>> those, if you're interested in contributing to these topics join us! :)
>>
>> Best regards,
>> Frederic
>>
>> -- 
>> 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/ab025c6f-c37d-44e0-8dba-455ac9c1fadfn%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/ca6f3615-504a-4b61-8ce4-76f900ec5d9fn%40googlegroups.com.

Re: [prometheus-developers] Prometheus Storage Working Group

[Goutham Veeramachaneni]

Love the initiative, thanks for spearheading this! I have it in my OKRs to
explore and write up a design doc (just the usecases we want to support,
not the implementation details) around this and you've just made my life
mch easier :D 9AM GMT Mondays works for me as well!

I am not able to access the calendar link though, is it just me or does it
not work for others as well?

Thanks,
Goutham.

On Mon, Sep 7, 2020 at 12:58 PM fbra...@gmail.com 
wrote:

> Hello Prometheans,
>
> There have been various ideas around potentially improving parts of
> Prometheus' TSDB. I would like to start a working group that meets
> regularly around these topics and compares notes, researches, and
> experiments with potential improvements and hopefully ultimately develop
> designs to be proposed as improvements to Prometheus.
>
> I've been talking to Ganesh about this topic a bit and we've put together
> a small starting document to kick this off:
> https://docs.google.com/document/d/1HWL-NIfog3_pFxUny0kAHeoxd0grnqhCBcHVPZN4y3Y/edit?usp=sharing
>
> The idea, for now, is to meet at a biweekly cadence at 9 AM GMT for 30
> minutes, a link to the meeting is in the above document. (this works for
> Ganesh and me, we're open to rescheduling this and or extending this if
> needed)
>
> The first meeting for this is scheduled for the 22nd of September. There
> will be meeting notes, so if you're just interested in the results read
> those, if you're interested in contributing to these topics join us! :)
>
> Best regards,
> Frederic
>
> --
> 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/ab025c6f-c37d-44e0-8dba-455ac9c1fadfn%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/CAKQV3GEwKdm%2BCAssYdFH13tdMyz4JjydHSQnc-fcvORhiOk4Hw%40mail.gmail.com.

Re: [prometheus-developers] Prometheus target state is Down

[Christian Hoffmann]

Hi,

On 4/27/20 7:36 PM, srinivas vemula wrote:
> I have implemented prometheus monitoring for docker container's. But few
> server's the prometheus target state is Down for some reason. Could you
> please help me to resolve this resolve.

The targets page in the Web UI should provide some further details about
the cause (e.g. deadline exceeded).

You can also have a look at several meta metrics such as
scrape_duration_seconds (a high value might point to a timeout or slow
scrape) or the metric for the scrape limit.

Kind regards,
Christian

-- 
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/70008ccd-9638-408f-218c-b6b69198d1a3%40hoffmann-christian.info.

Re: [prometheus-developers] Prometheus expression correction help

[Julius Volz]

Hi,

Moving this thread to prometheus-users (+bcc -dev), where it is a better
fit.

Assuming the label names and values referenced in your expression actually
exist in your metrics data, one problem is that with the regex you are
trying to select only part of a string. However, Prometheus regular
expression matchers always try to match an entire string, not a substring.
If for example you want to match any string that ends with
"-aws-db-prd-om-enc", you would have to explicitly make it a substring
match like so: dbinstance_identifier=~".*-aws-db-prd-om-enc". Note you have
some "com", "om", "-om" inconsistencies in your examples.

I assume you are just starting out with this query fragment and are still
planning on adding further constructs (like "== 0") around that selector
expression to actually detect if the sum is 0.

Cheers,
Julius

On Wed, Apr 8, 2020 at 11:40 AM Travel & Devops 
wrote:

> Hello Team ,
>
> I am trying to create a alert rule to monitor RDS databse connections
> count , if the database connection count is less-than one we need an alert
> , but RDS has read-replicas and we don't want to monitor read-replicas ,
>
> I have wrote the below alert rule to exclude read-replica but i was not
> giving any data seem's to be some issue with the expression,
>
>
> *aws_rds_database_connections_sum{dbinstance_identifier=~"aws-db-prd-om-enc",d*
> *binstance_identifier!~".*-read-replica"}*
>
> above expression is not giving any data
> Can any one help me on this to correct the expression
>
> Sample DB name :testing-c1-us-east-1-aws-db-prd-com-enc"
> Replica DB Name: testing-c1-us-east-1-aws-db-prd--om-enc-read-replica"
>
> Regards
> Reddy
>
> --
> 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/3694e31d-f03a-4cb3-81e5-8a4970801977%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/CA%2BT6YozLt1k-x%2BTB3Wa4aLu2vBvyGZJU7rYgjUugDjYgsp4kJQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus rules and runtime reload

[Frederic Branczyk]

I don’t know the exact setup of the helm chart, but generally those use
cases are covered by the prometheus operator. The first by provisioning
PrometheusRule objects in the application namespace and the second,
Prometheus is simply automatically reloaded when the new rule appears in
the container, which because of configmap reload times, this can be up to
5minutes delay.

I recommend going through the alerting user guide to understand the
components involved:
https://github.com/coreos/prometheus-operator/blob/master/Documentation/user-guides/alerting.md

On Sun 22. Mar 2020 at 23:41, EnthuDeveloper  wrote:

> Hello,
> I am trying helm charts(prometheus operator ) to install Prometheus and
> Alertmanager. Looking for some recommendations as to what the preferable
> options are for :
> 1. Reading alert rules generated from our application in form of a yaml
> file and loading them to container running Prometheus ?
> 2. How to reload the alert rules for prometheus in case , the rules yaml
> file generated by our application sees any modifications.
>
> Any recommendations would be much appreciated ?
>
> Thanks.
>
> --
> 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/f81e52b7-d5bc-4c2f-8543-2b626956e92a%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/CAOs1Umx5aEsiNQx2KrDZjK6w55e6-TE20qJkM%3Daf3thG_eqBTg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus & Go Modules - An experiment

[Brian Brazil]

On Thu, 12 Mar 2020 at 00:03, Duco van Amstel 
wrote:

> Dear devs,
>
> During the summer of 2019 a long thread
> 
> on this mailing list discussed the various issues that the Prometheus
> project was facing with the adoption of the new Go modules dependency
> management system. Based on the various arguments and facts that came out
> of this thread and a discussion with the project's maintainers I offered a
> potential way out in the form of a generic tool
> 
> .
>
> This tool, dubbed 'modularise', has now left its initial development
> stages and is ready for wider use and experimentation by Go projects
> including, but not limited to, Prometheus.
>
> The constraints for a solution to the "modules problem" were, on the
> various discussions, as follows:
>
>1. Keep Prometheus's codebase in a single repository to allow for
>quick iteration cycles.
>2. Continue to use the existing semantic versioning for Prometheus
>releases.
>3. Align with the strong semantic versioning requirements that Go
>modules puts on the contents of any given module.
>4. Allow for the large ecosystem of projects around Prometheus to
>consume the "internal" implementation APIs (tsdb, promql, etc.) with which
>Prometheus is built in a developer-friendly manner.
>
> As with most problems involving dependency management and versioning, many
> potential solutions exist. However all the ones that had previously been
> evoked in the context of Go modules, inside or outside of the Prometheus
> project, are based on hard tradeoffs. One or more of the above 4 points is
> required to give in and in practice its usually the first and most
> important constraint, which in my eyes is ease-of-development, that is
> sacrificed. The 'modularise' tool provides a new solution, one that aims to
> not suffer from such a compromise.
>
> The simplified version of what 'modularise' does is to:
>
>- Copy a defined set of packages from an existing Go module to a
>separate directory.
>- Rewrite / rewire import paths where necessary.
>- Initialise a Go module in the newly created directory.
>- Publish the result to a git repository.
>
> As a result, external projects can depend on these automatically
> maintained & independent modules without depending on the core project.
> These modules can be versioned separately from the main Prometheus project
> with their own dedicated release cadence. These separate modules also have
> the benefit of not depending on the project from which they are extracted.
> This introduces the potential for considerably reducing the size of your
> downstream project's dependency graph.
>
> All this might look nice on paper (or maybe not if you dislike the idea ;)
> ) but nothing gives a better idea of what this means than a good example.
> Besides the 'modularise' source code now being available
>  there is also a secondary
> project  which performs a daily
> run on the latest master commit of Prometheus (and soon other projects as
> well).
>
> The current setup produces two new modules:
>
>- prometheus-tsdb  - which
>contains the 'tsdb' subtree and some required associated packages.
>- prometheus-promql  - 
> which
>contains the 'promql' subtree and depends on prometheus-tsdb.
>
> Although these projects, which are meant to be simple demos, will not be
> tagged or go through other forms of manual curation they should be
> consumable by other Go projects without issues.
>

Great! Having them available like this is what we hoping for at the last
dev summit, so let's see how this all goes now.

Brian


>
> As the title of this message puts it: this is meant to be an experiment,
> so do share your thoughts, your ideas and experiment yourself by using the
> demo projects (although please don't yet deploy the result to production :)
> ). Last but not least I'd like to extend a special thank you to +Bartłomiej
> Płotka  for bringing me on to the original issue and
> discussion!
>
> Thank you for reading up to this point and happy developing!
>
> Duco
>
> --
> 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/CAP8_5EBj08U__jGx-Evu-p0As6zbgSsY3hKcK1dmoiy_d69ndg%40mail.gmail.com
> 

Re: [prometheus-developers] Prometheus violating Go modules semantic versioning rules - what to do?

[Duco van Amstel]

For what it's worth I've just started a fresh topic

with my first results using the modularise tool.

On Fri, 28 Feb 2020 at 13:23, Sylvain Rabot  wrote:

> Ok so I've been talking to Duco about this and he convinced me that using
> in repo replace directives with relative paths is not a good idea.
>
> If he has the time he can explain it much better than I could.
>
> On Fri, 28 Feb 2020 at 12:04, Sylvain Rabot 
> wrote:
>
>> After giving it more search, it came to (my) light that go mod handles
>> "special" git tags for go mod sub-versioning.
>>
>>
>> https://github.com/golang/go/wiki/Modules#what-are-multi-module-repositories
>>
>> The tag for version 1.2.3 of module "my-repo/foo/rop" is "foo/rop/v1.2.3".
>>>
>>
>> I.E, "go get github.com/prometheus/prometheus/tsdb/v2@v2.13.0" would
>> resolve "github.com/prometheus/prometheus.git" at tag "tsdb/v2.13.0"
>>
>> With that in mind, I believe having multiple independent go modules in
>> the same git repo is OK.
>>
>> With this we can leverage the initial reason of having those "core"
>> modules inside prometheus/prometheus (no sync overhead) and a decent
>> independent development oriented life cycle.
>>
>> We currently have release shepherds, I think that if we were to implement
>> this, we would need a shepherd per module responsible for releasing
>> versions of "his" module(s).
>>
>> I made a Draft PR to get a sense of it:
>> https://github.com/prometheus/prometheus/pull/6888/commits/44149825edb0b5c92885f362b6f3ae1643e2f451
>>
>> It's pretty light if we exclude removing vendoring altogether (because I
>> don't believe vendoring makes sense anymore with the latest versions of go
>> and because each module having its own go mod needs its own vendor/ dir).
>>
>> The only problem I encountered came from promu. In the case we want to
>> build a binary in a module that has its own go.mod file (like tsdb), the go
>> build command needs to be run from within the dir of the module (because of
>> the relative paths in the go.mod replace directive I assume). I already
>> have a patch for this (
>> https://github.com/sylr/promu/commit/c6e6a2bcdf5d50338b1ee70022c40152a8992c82
>> ).
>>
>> Regards.
>>
>> On Fri, 7 Feb 2020 at 18:12, Bjoern Rabenstein 
>> wrote:
>>
>>> I think it became already obvious from the discussion so far: Semantic
>>> versioning for the user of the Prometheus server is completely
>>> different from semantic versioning for the user of Go packages
>>> contained in the Prometheus code base.
>>>
>>> Conflating both will be bad for both parties.
>>>
>>> We could have a _separate_ versioning, using vx.y.z tags for the Go
>>> module versioning and a new tag naming schema (e.g. release-x.y.z) for
>>> user releases.
>>>
>>> Besides the obvious concerns about this, I also think that semantic
>>> versioning for a large number of Go packages together is problematic
>>> in any case. Any breaking change in any one package will bump the
>>> major version for _all_ packages, leading to new import paths in the
>>> Go modules world, which can lead to interoperability problems for
>>> indirect users of the packages. (They could find themselves in the
>>> situation of assigning a v2/model.Label spit out by one of their
>>> direct dependencies to a v3/model.Label required by another of their
>>> direct dependencies.)
>>>
>>> That's why I think Duco's Modularize project has some
>>> merits. Alternatively (as I said before), I could see better tooling
>>> for maintaining multiple Go modules within the same Git repo as a
>>> viable (and less invasive) solution.
>>>
>>> Therefore, I'd prefer to see how Modularize turns out in practice (or
>>> if alternatively somebody comes up with tooling and/or easy-to-follow
>>> best practices for multi-module repos) and then reconsider what we can
>>> do in prometheus/prometheus.
>>>
>>> --
>>> Björn Rabenstein
>>> [PGP-ID] 0x851C3DA17D748D03
>>> [email] bjo...@rabenste.in
>>>
>>
>>
>> --
>> Sylvain Rabot 
>>
>
>
> --
> Sylvain Rabot 
>

-- 
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/CAP8_5EDBuQWN7GeTLDDnY7xHgP617c69CvWtD_iRVPSMqqHxbg%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Alert handle/resolve handling

[EnthuDeveloper]

Thank you Matthias.

Actually our webhook implementation is depending upon status of alert sent i.e. 
firing vs resolved.

If we receive an notification for a given group containing some number of 
alerts, we just assume it to be new alert instances and end up creating new 
alert records in database.

It is quite hard to determine if we are receiving notification with diff labels 
/ content or is just an update of an exiting group alert.

For e.g. if I have a service down alert configured and webhook receives the 
notification for service A first and service B later than they are two 
different alert instances for us.

So basically the main question is every-time our webhook gets the alert 
notifications as group then how to ensure,

We are not repetitively creating alert records and updating them as resolved 
each time the notification is sent with different statuses.

Thanks.

-- 
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/2cab5e7f-6517-49c2-b17b-1ba09e478db6%40googlegroups.com.

Re: [prometheus-developers] Prometheus Alert handle/resolve handling

['Matthias Rampke' via Prometheus Developers]

I think it helps to think about Alertmanager webhooks differently.

Alertmanager does not notify about individual alerts but about *groups* of
alerts. These groups come into being, the number of alert instances in them
potentially changes over time. Subsequent webhooks about the same groups
are updates about the status, not a separate instance of anything. The
resolution notification closes the group.

By design, you cannot rely on 1 webhook call = 1 alert. To ensure delivery,
Alertmanager will err on the side of notifying more than needed if it is
not sure what you already got. This is especially the case with clustered
Alertmanager.

The webhooks contain a groupKey field. Use this field to identify which
group a notification is about, and update that one if you already have it
in your UI. That way, there is only one thing to close as well.


/MR

On Tue, 3 Mar 2020, 16:54 EnthuDeveloper,  wrote:

> Hi ,
> I am just curious to know if we have a custom webhook implemented to
> receive alerts from Prometheus Alertmanager then what should be the
> considerations for implementing the custom logic for resolved alerts ?
> My question is more from a standpoint that if repeat_interval is
> configured to be a frequent interval , then our system might have received
> multiple alerts with firing status for the same alert. So when Prometheus
> identifies that alert should be resolved now would it just send one alert
> with resolved status ?
>
> My confusion is shouldn’t we mark all the existing alert instances with
> matching alert name as resolved in our custom logic once Prometheus sees an
> alert transitioning from firing to resolved status.
>
> Note : This logic is needed on our custom framework side to avoid listing
> resolved alerts on the alert dashboard.
>
>
> Any input would be greatly appreciated.
>
>
> Thanks.
>
> --
> 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/ceaf9c38-3b17-47e0-a4bd-e79e7d229e3f%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/CAFU3N5W5sOy-fy4ZyrGq%2BZw7b9-aNGjKe2CNy%3DjnqMr4eFQsLQ%40mail.gmail.com.

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Callum Styan]

I'll leave it up to the next few release shepherds to decide if they want
to revisit this topic. I'll do so myself next time I'm the release shepherd.

Thanks for the discussion everyone!

On Tue, Feb 18, 2020 at 7:56 AM Simon Pasquier  wrote:

> On Fri, Feb 14, 2020 at 11:30 PM 'Matthias Rampke' via Prometheus
> Developers  wrote:
> >
> > How do I make it so there is no entry?
>
> If you mean "ignore a PR that shouldn't appear in the changelog" then
> all PRs that aren't labelled will added as comments to the
> CHANGELOG.md file.
> From there you're still free to rearrange whatever has been produced.
>
> Here is an example with Alertmanager:
>
> https://github.com/simonpasquier/alertmanager/commit/7fde3cc25471c626e82def873a01a9924e1816ae
>
>
> >
> > On Fri, 14 Feb 2020, 18:07 Simon Pasquier,  wrote:
> >>
> >> Correct, the PR is in the promu repository (I've updated it just now
> >> to address comments from Brian though it should have been done long
> >> ago):
> >> https://github.com/prometheus/promu/pull/170
> >>
> >> Right now, it leverages the PR labels to classify the change (BUGFIX,
> >> CHANGE, ...) and it uses the PR's title as the changelog entry. It
> >> wouldn't be hard to mimic what Kubernetes is doing and lookup the
> >> changelog entry in the PR description as Matthias suggested. If
> >> nothing is found it can always fallback to the title.
> >> I agree that asking every PR to include the changelog update might not
> >> be convenient (both for the contributor and the maintainer).
> >>
> >> On Fri, Feb 14, 2020 at 8:10 AM Frederic Branczyk 
> wrote:
> >> >
> >> > I recall Simon having a tool that would largely generate the
> changelog automatically, that worked pretty well last time I was release
> shepherd. Otherwise I'm also happy to discuss a process like in Kubernetes
> where the changelog item is written into the PR. On Thanos we have in the
> PR template that people have ensured that the changelog item was added
> respective to the change. Seems like there are options, I personally would
> favor something that would be done at contribution time, so not all the
> responsibility falls on the release shepherd as it does today, and more
> generally it seems like the person contributing the change probably is also
> a good candidate to describe it in the changelog.
> >> >
> >> > On Fri, 14 Feb 2020 at 08:05, Callum Styan 
> wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I'd like to start a discussion around changing how we manage the
> prometheus/prometheus changelog, specifically the fact that the changelog
> is generated manually by the release shepherd as part of the release
> process.
> >> >>
> >> >> We can discuss options for what the new process would look like,
> such as requiring PR's to include changelog entries before merging or the
> next release shepherd periodically updating the changelog prior to the
> release, in more detail later. However I'd first like to get a sense of
> whether anyone else feels strongly about either changing or not changing
> this part of the release process.
> >> >>
> >> >> Thanks,
> >> >> Callum.
> >> >>
> >> >> --
> >> >> 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/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.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/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.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/CAM6RFu79WLX7ZZezxMvQdinV5VMdP-0pfPSfTPs45g7RO-qGcA%40mail.gmail.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/CAFU3N5XcbOkOrPVrQ-Mzd-FX%2B7W%2B6kdL_uKOCQ%3DLn1X8f2%2BdtQ%40mail.gmail.com
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"

Re: [prometheus-developers] Prometheus security related questions

[Bjoern Rabenstein]

On 27.02.20 17:16, Julien Pivotto wrote:
> On 27 Feb 08:12, Mihai Iordache wrote:
> > I have some additional questions as following:
> > 1. Are you performing regularly pentests ? if yes, how often ?
> 
> As https://prometheus.io/docs/operating/security/#external-audits
> 
> There was a pentest in 2018. There will probably be a new one in 2020,
> to be confirmed.

That was an audit. I wouldn't call that a pentest.

> > 2. All high and critical issues are addressed in a short amount of time ?
> 
> Prometheus is an open source project and we address those issues on a
> best-effort basis. You try to do our best but we don't promise anything.
> Some team members also closely follow golang releases for security
> vulnerabilities.

Exactly. If you want any kind of guarantee, you either have to
contribute security fixes yourself, or you have to pay somebody to do
it for you. (The latter is one of the many facets of building a
business on top of open source software.)

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

Re: [prometheus-developers] Prometheus violating Go modules semantic versioning rules - what to do?

[Sylvain Rabot]

Ok so I've been talking to Duco about this and he convinced me that using
in repo replace directives with relative paths is not a good idea.

If he has the time he can explain it much better than I could.

On Fri, 28 Feb 2020 at 12:04, Sylvain Rabot  wrote:

> After giving it more search, it came to (my) light that go mod handles
> "special" git tags for go mod sub-versioning.
>
>
> https://github.com/golang/go/wiki/Modules#what-are-multi-module-repositories
>
> The tag for version 1.2.3 of module "my-repo/foo/rop" is "foo/rop/v1.2.3".
>>
>
> I.E, "go get github.com/prometheus/prometheus/tsdb/v2@v2.13.0" would
> resolve "github.com/prometheus/prometheus.git" at tag "tsdb/v2.13.0"
>
> With that in mind, I believe having multiple independent go modules in the
> same git repo is OK.
>
> With this we can leverage the initial reason of having those "core"
> modules inside prometheus/prometheus (no sync overhead) and a decent
> independent development oriented life cycle.
>
> We currently have release shepherds, I think that if we were to implement
> this, we would need a shepherd per module responsible for releasing
> versions of "his" module(s).
>
> I made a Draft PR to get a sense of it:
> https://github.com/prometheus/prometheus/pull/6888/commits/44149825edb0b5c92885f362b6f3ae1643e2f451
>
> It's pretty light if we exclude removing vendoring altogether (because I
> don't believe vendoring makes sense anymore with the latest versions of go
> and because each module having its own go mod needs its own vendor/ dir).
>
> The only problem I encountered came from promu. In the case we want to
> build a binary in a module that has its own go.mod file (like tsdb), the go
> build command needs to be run from within the dir of the module (because of
> the relative paths in the go.mod replace directive I assume). I already
> have a patch for this (
> https://github.com/sylr/promu/commit/c6e6a2bcdf5d50338b1ee70022c40152a8992c82
> ).
>
> Regards.
>
> On Fri, 7 Feb 2020 at 18:12, Bjoern Rabenstein  wrote:
>
>> I think it became already obvious from the discussion so far: Semantic
>> versioning for the user of the Prometheus server is completely
>> different from semantic versioning for the user of Go packages
>> contained in the Prometheus code base.
>>
>> Conflating both will be bad for both parties.
>>
>> We could have a _separate_ versioning, using vx.y.z tags for the Go
>> module versioning and a new tag naming schema (e.g. release-x.y.z) for
>> user releases.
>>
>> Besides the obvious concerns about this, I also think that semantic
>> versioning for a large number of Go packages together is problematic
>> in any case. Any breaking change in any one package will bump the
>> major version for _all_ packages, leading to new import paths in the
>> Go modules world, which can lead to interoperability problems for
>> indirect users of the packages. (They could find themselves in the
>> situation of assigning a v2/model.Label spit out by one of their
>> direct dependencies to a v3/model.Label required by another of their
>> direct dependencies.)
>>
>> That's why I think Duco's Modularize project has some
>> merits. Alternatively (as I said before), I could see better tooling
>> for maintaining multiple Go modules within the same Git repo as a
>> viable (and less invasive) solution.
>>
>> Therefore, I'd prefer to see how Modularize turns out in practice (or
>> if alternatively somebody comes up with tooling and/or easy-to-follow
>> best practices for multi-module repos) and then reconsider what we can
>> do in prometheus/prometheus.
>>
>> --
>> Björn Rabenstein
>> [PGP-ID] 0x851C3DA17D748D03
>> [email] bjo...@rabenste.in
>>
>
>
> --
> Sylvain Rabot 
>


-- 
Sylvain Rabot 

-- 
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/CADjtP1EgLt--JMvyZrw%3DKyxd%3Da3WJ%3DoaWCsR0Euc5HQwBb7_GA%40mail.gmail.com.

Re: [prometheus-developers] Prometheus violating Go modules semantic versioning rules - what to do?

[Sylvain Rabot]

After giving it more search, it came to (my) light that go mod handles
"special" git tags for go mod sub-versioning.

https://github.com/golang/go/wiki/Modules#what-are-multi-module-repositories

The tag for version 1.2.3 of module "my-repo/foo/rop" is "foo/rop/v1.2.3".
>

I.E, "go get github.com/prometheus/prometheus/tsdb/v2@v2.13.0" would
resolve "github.com/prometheus/prometheus.git" at tag "tsdb/v2.13.0"

With that in mind, I believe having multiple independent go modules in the
same git repo is OK.

With this we can leverage the initial reason of having those "core" modules
inside prometheus/prometheus (no sync overhead) and a decent independent
development oriented life cycle.

We currently have release shepherds, I think that if we were to implement
this, we would need a shepherd per module responsible for releasing
versions of "his" module(s).

I made a Draft PR to get a sense of it:
https://github.com/prometheus/prometheus/pull/6888/commits/44149825edb0b5c92885f362b6f3ae1643e2f451

It's pretty light if we exclude removing vendoring altogether (because I
don't believe vendoring makes sense anymore with the latest versions of go
and because each module having its own go mod needs its own vendor/ dir).

The only problem I encountered came from promu. In the case we want to
build a binary in a module that has its own go.mod file (like tsdb), the go
build command needs to be run from within the dir of the module (because of
the relative paths in the go.mod replace directive I assume). I already
have a patch for this (
https://github.com/sylr/promu/commit/c6e6a2bcdf5d50338b1ee70022c40152a8992c82
).

Regards.

On Fri, 7 Feb 2020 at 18:12, Bjoern Rabenstein  wrote:

> I think it became already obvious from the discussion so far: Semantic
> versioning for the user of the Prometheus server is completely
> different from semantic versioning for the user of Go packages
> contained in the Prometheus code base.
>
> Conflating both will be bad for both parties.
>
> We could have a _separate_ versioning, using vx.y.z tags for the Go
> module versioning and a new tag naming schema (e.g. release-x.y.z) for
> user releases.
>
> Besides the obvious concerns about this, I also think that semantic
> versioning for a large number of Go packages together is problematic
> in any case. Any breaking change in any one package will bump the
> major version for _all_ packages, leading to new import paths in the
> Go modules world, which can lead to interoperability problems for
> indirect users of the packages. (They could find themselves in the
> situation of assigning a v2/model.Label spit out by one of their
> direct dependencies to a v3/model.Label required by another of their
> direct dependencies.)
>
> That's why I think Duco's Modularize project has some
> merits. Alternatively (as I said before), I could see better tooling
> for maintaining multiple Go modules within the same Git repo as a
> viable (and less invasive) solution.
>
> Therefore, I'd prefer to see how Modularize turns out in practice (or
> if alternatively somebody comes up with tooling and/or easy-to-follow
> best practices for multi-module repos) and then reconsider what we can
> do in prometheus/prometheus.
>
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>


-- 
Sylvain Rabot 

-- 
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/CADjtP1FkVUSFx8hJpe10pTS3d4P_5NKHThu8nORKvyYJHCCavA%40mail.gmail.com.

Re: [prometheus-developers] Prometheus security related questions

[Julien Pivotto]

On 27 Feb 08:12, Mihai Iordache wrote:
> I have some additional questions as following:
> 1. Are you performing regularly pentests ? if yes, how often ?

As https://prometheus.io/docs/operating/security/#external-audits

There was a pentest in 2018. There will probably be a new one in 2020,
to be confirmed.

> 2. All high and critical issues are addressed in a short amount of time ?

Prometheus is an open source project and we address those issues on a
best-effort basis. You try to do our best but we don't promise anything.
Some team members also closely follow golang releases for security
vulnerabilities.

> 
> 
> On Monday, 24 February 2020 15:42:04 UTC+2, Björn Rabenstein wrote:
> >
> > On 20.02.20 23:29, Lucian Iordache wrote: 
> > > Thank you for info, Already reviewed that but these does not cover 
> > entirely our 
> > > questions. 
> > > We would appreciate some targeted answers to our questions. 
> >
> > Anything else is essentially fluid and not really formalized. 
> >
> > You'll get individual views on how our practices have developed in 
> > practice (cf. the other response in this thread by Ben Kochie). But 
> > views and opinions will vary, and you therefore cannot expect any of 
> > those practices to be applied consistently and systematically. 
> >
> > -- 
> > 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/prometheus-developers/69b2f00f-9273-44a0-8e71-b8f3b787e8b0%40googlegroups.com.


-- 
 (o-Julien Pivotto
 //\Open-Source Consultant
 V_/_   Inuits - https://www.inuits.eu

-- 
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/20200227161612.GA26706%40oxygen.


signature.asc
Description: PGP signature

Re: [prometheus-developers] Prometheus security related questions

[Mihai Iordache]

I have some additional questions as following:
1. Are you performing regularly pentests ? if yes, how often ?
2. All high and critical issues are addressed in a short amount of time ?


On Monday, 24 February 2020 15:42:04 UTC+2, Björn Rabenstein wrote:
>
> On 20.02.20 23:29, Lucian Iordache wrote: 
> > Thank you for info, Already reviewed that but these does not cover 
> entirely our 
> > questions. 
> > We would appreciate some targeted answers to our questions. 
>
> Anything else is essentially fluid and not really formalized. 
>
> You'll get individual views on how our practices have developed in 
> practice (cf. the other response in this thread by Ben Kochie). But 
> views and opinions will vary, and you therefore cannot expect any of 
> those practices to be applied consistently and systematically. 
>
> -- 
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/69b2f00f-9273-44a0-8e71-b8f3b787e8b0%40googlegroups.com.

Re: [prometheus-developers] Prometheus security related questions

[Bjoern Rabenstein]

On 20.02.20 23:29, Lucian Iordache wrote:
> Thank you for info, Already reviewed that but these does not cover entirely 
> our
> questions.
> We would appreciate some targeted answers to our questions.

Anything else is essentially fluid and not really formalized.

You'll get individual views on how our practices have developed in
practice (cf. the other response in this thread by Ben Kochie). But
views and opinions will vary, and you therefore cannot expect any of
those practices to be applied consistently and systematically.

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

Re: [prometheus-developers] Prometheus security related questions

[Ben Kochie]

On Wed, Feb 19, 2020 at 10:37 AM Lucian Iordache 
wrote:

> Hi,
>
> My name is Lucian and I am SRE Observability Engineer at Mambu GmbH.
>
> We are working on a custom solution based on Prometheus, and we have some
> questions from security perspective as following:
>
> 1. How is the Prometheus design performed ? Are you considering security
> requirements in architecture and design phase of the product and new
> features ?
>
> In general, yes, we consider security when designing new features.

> 2. Are you performing code reviews ?  If yes, security checks are part of
> it ?
>
> Yes, the Prometheus project uses code review via GitHub pull requests.

> 3. How dependencies are managed?
>
> We use Go modules and Yarn.

>
> 3.1 Are you scanning for vulnerable dependencies ?
>
> GitHub provides dependency vulnerability scanning for us.

> 3.2 How are dependencies reviewed before added to the product, and how
> vulnerable or non-maintained dependencies are handled ?
>
> They're reviewed as part of our code review process.

> 4. How the source code is checked for vulnerabilities (E.g. Static code
> analysis, penetration tests …) ?
>
> We use a 3rd party audit service. Currently Cure53.

> 5. How the build process is secured ?
>
> We preform builds via CircleCI and use CircleCI's official build images.

>
>
> Thank You .
>
> Regards,
> Lucian Iordache
> SRE Observability Engineer
> Mambu
>
> --
> 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/13b4a798-fa97-4c60-81d8-08cd4b793219%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/CABbyFmozj8e%3DuDkAu85dSXR01TJsjS-FV0w4bYTperbrq4q1dQ%40mail.gmail.com.

Re: [prometheus-developers] Prometheus security related questions

[Lucian Iordache]

Thank you for info, Already reviewed that but these does not cover entirely 
our questions.
We would appreciate some targeted answers to our questions.

On Thursday, 20 February 2020 16:30:24 UTC+2, Björn Rabenstein wrote:
>
> On 19.02.20 01:37, Lucian Iordache wrote: 
> > 
> > We are working on a custom solution based on Prometheus, and we have 
> some 
> > questions from security perspective as following: 
>
> For canonical answers, you should have a look at 
> https://prometheus.io/docs/operating/security/ . 
>
> Also note the Cure53 audit linked from that page: 
>
> https://prometheus.io/assets/downloads/2018-06-11--cure53_security_audit.pdf 
>
> -- 
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/7489502d-f14c-4492-b490-32fc479b0670%40googlegroups.com.

Re: [prometheus-developers] Prometheus security related questions

[Bjoern Rabenstein]

On 19.02.20 01:37, Lucian Iordache wrote:
> 
> We are working on a custom solution based on Prometheus, and we have some
> questions from security perspective as following:

For canonical answers, you should have a look at
https://prometheus.io/docs/operating/security/ .

Also note the Cure53 audit linked from that page:
https://prometheus.io/assets/downloads/2018-06-11--cure53_security_audit.pdf

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

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Simon Pasquier]

On Fri, Feb 14, 2020 at 11:30 PM 'Matthias Rampke' via Prometheus
Developers  wrote:
>
> How do I make it so there is no entry?

If you mean "ignore a PR that shouldn't appear in the changelog" then
all PRs that aren't labelled will added as comments to the
CHANGELOG.md file.
>From there you're still free to rearrange whatever has been produced.

Here is an example with Alertmanager:
https://github.com/simonpasquier/alertmanager/commit/7fde3cc25471c626e82def873a01a9924e1816ae


>
> On Fri, 14 Feb 2020, 18:07 Simon Pasquier,  wrote:
>>
>> Correct, the PR is in the promu repository (I've updated it just now
>> to address comments from Brian though it should have been done long
>> ago):
>> https://github.com/prometheus/promu/pull/170
>>
>> Right now, it leverages the PR labels to classify the change (BUGFIX,
>> CHANGE, ...) and it uses the PR's title as the changelog entry. It
>> wouldn't be hard to mimic what Kubernetes is doing and lookup the
>> changelog entry in the PR description as Matthias suggested. If
>> nothing is found it can always fallback to the title.
>> I agree that asking every PR to include the changelog update might not
>> be convenient (both for the contributor and the maintainer).
>>
>> On Fri, Feb 14, 2020 at 8:10 AM Frederic Branczyk  
>> wrote:
>> >
>> > I recall Simon having a tool that would largely generate the changelog 
>> > automatically, that worked pretty well last time I was release shepherd. 
>> > Otherwise I'm also happy to discuss a process like in Kubernetes where the 
>> > changelog item is written into the PR. On Thanos we have in the PR 
>> > template that people have ensured that the changelog item was added 
>> > respective to the change. Seems like there are options, I personally would 
>> > favor something that would be done at contribution time, so not all the 
>> > responsibility falls on the release shepherd as it does today, and more 
>> > generally it seems like the person contributing the change probably is 
>> > also a good candidate to describe it in the changelog.
>> >
>> > On Fri, 14 Feb 2020 at 08:05, Callum Styan  wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I'd like to start a discussion around changing how we manage the 
>> >> prometheus/prometheus changelog, specifically the fact that the changelog 
>> >> is generated manually by the release shepherd as part of the release 
>> >> process.
>> >>
>> >> We can discuss options for what the new process would look like, such as 
>> >> requiring PR's to include changelog entries before merging or the next 
>> >> release shepherd periodically updating the changelog prior to the 
>> >> release, in more detail later. However I'd first like to get a sense of 
>> >> whether anyone else feels strongly about either changing or not changing 
>> >> this part of the release process.
>> >>
>> >> Thanks,
>> >> Callum.
>> >>
>> >> --
>> >> 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/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.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/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.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/CAM6RFu79WLX7ZZezxMvQdinV5VMdP-0pfPSfTPs45g7RO-qGcA%40mail.gmail.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/CAFU3N5XcbOkOrPVrQ-Mzd-FX%2B7W%2B6kdL_uKOCQ%3DLn1X8f2%2BdtQ%40mail.gmail.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/CAM6RFu6r4

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Julius Volz]

I'm with Björn and Brian on keeping the CHANGELOG.md manually curated. You
need to understand all relevant changes since the last release anyway as
the release shepherd, and it's much easier and less overall overhead to
weigh everything centrally in the end than trying to get everyone to
formulate changelog entries for every PR that in the end result in a
cohesive whole.

On Mon, Feb 17, 2020 at 4:13 PM Łukasz Mierzwa  wrote:

> Adopting one of many variants of semantic commits and using one of many
> tools that generates a changelog from it can save some time there.
> Examples: example: https://www.conventionalcommits.org/,
> https://keepachangelog.com/
> Going that path is easier if one uses commit message linter, to ensure all
> comit messages follow required format -
> https://github.com/conventional-changelog/commitlint
>
> That being said from a purely user oriented perspectice I always find it
> useful when changelog includes a section that gives me a human readable
> overview of what's included in given release, that is difficult to automate
> but can be added on top of automated changelog.
>
> On Monday, 17 February 2020 15:06:42 UTC, Björn Rabenstein wrote:
>>
>> Just my 2¢:
>>
>> I'm firmly in the camp of hand-creating the CHANGELOG. I do so many
>> editorial work on it that a pre-populated CHANGELOG might easily
>> create more work than it saves. I do have to understand anyway what
>> each change is doing as we are supposed to filter out changes that are
>> not user-visible/-impacting (which could as well be that a
>> user-visible change was introduced with its corresponding CHANGELOG
>> entry, but later it was removed again before a release happened).
>>
>> I'm essentially doing what Brian is doing when I cut a release. I only
>> found that problematic after releases were procrastinated for too long
>> and the CHANGELOG exploded. With the fixed cadence in
>> prometheus/prometheus, that isn't really a problem anymore (but 2.16.0
>> was a biggie nevertheless).
>>
>> What is a problem is unclear or incomplete commit and/or PR
>> descriptions. I guess we can all agree to ask for those in reviews.
>>
>> I don't feel strongly about how in detail we want to encourage good
>> commit and PR descriptions. If we put a hint in there to suggest a
>> changelog line if applicable, I'm all for it. If people want a
>> specific keyword to autoextract it, sure, as long as I don't have to
>> use it and it doesn't make it harder to contribute.
>>
>> I would not like to directly edit the CHANGELOG.md file in each PR,
>> for all the reasons already stated.
>>
>> --
>> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/da403d28-cfad-41c2-8d0b-91168be070f5%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/CA%2BT6Yoxd7SOi%2BMPP%3Dbxmhm67kUy1QK_qECwBR1FkTtKU0%2BGFRg%40mail.gmail.com.

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Łukasz Mierzwa]

Adopting one of many variants of semantic commits and using one of many 
tools that generates a changelog from it can save some time there.
Examples: example: https://www.conventionalcommits.org/, 
https://keepachangelog.com/
Going that path is easier if one uses commit message linter, to ensure all 
comit messages follow required format - 
https://github.com/conventional-changelog/commitlint

That being said from a purely user oriented perspectice I always find it 
useful when changelog includes a section that gives me a human readable 
overview of what's included in given release, that is difficult to automate 
but can be added on top of automated changelog.

On Monday, 17 February 2020 15:06:42 UTC, Björn Rabenstein wrote:
>
> Just my 2¢: 
>
> I'm firmly in the camp of hand-creating the CHANGELOG. I do so many 
> editorial work on it that a pre-populated CHANGELOG might easily 
> create more work than it saves. I do have to understand anyway what 
> each change is doing as we are supposed to filter out changes that are 
> not user-visible/-impacting (which could as well be that a 
> user-visible change was introduced with its corresponding CHANGELOG 
> entry, but later it was removed again before a release happened). 
>
> I'm essentially doing what Brian is doing when I cut a release. I only 
> found that problematic after releases were procrastinated for too long 
> and the CHANGELOG exploded. With the fixed cadence in 
> prometheus/prometheus, that isn't really a problem anymore (but 2.16.0 
> was a biggie nevertheless). 
>
> What is a problem is unclear or incomplete commit and/or PR 
> descriptions. I guess we can all agree to ask for those in reviews. 
>
> I don't feel strongly about how in detail we want to encourage good 
> commit and PR descriptions. If we put a hint in there to suggest a 
> changelog line if applicable, I'm all for it. If people want a 
> specific keyword to autoextract it, sure, as long as I don't have to 
> use it and it doesn't make it harder to contribute. 
>
> I would not like to directly edit the CHANGELOG.md file in each PR, 
> for all the reasons already stated. 
>
> -- 
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/da403d28-cfad-41c2-8d0b-91168be070f5%40googlegroups.com.

Re: [prometheus-developers] Prometheus metrics are lost if the prometheus push gateway from different instance is down

[Bjoern Rabenstein]

On 17.02.20 03:10, Rajesh Somasundaram wrote:
> 
> 1) Instance A - running service xyz and its related metrics are pushed to
> push-gateway running in the same instance.
> 2) Instance B - Prometheus is scraping the metrics from Gateway and it is
> visualized in Grafana.
> 
> Issue:
> 
> 1) When the instance A is down, the prometheus lost its previously scraped
> metrics. Ideally, it should have saved the scraped metrics from the gateway
> though when the instance A is down.
>     But it is not happening at my end. Could anyone please help me with that?

Prometheus will for sure save the scraped metrics. It just cannot
ingest up-to-date metrics from the Pushgateway while it is down. So
time series end at the time of the last scrape, and that's probably
what you see in your visualization. That's the intended behavior. You
have to look farther back in time, or do some PromQL tricks with
max_over_time or avg_over_time (see also
https://www.robustperception.io/alerting-on-gauges-in-prometheus-2-0
for a related topic).

In different news, your question isn't really about development of
Prometheus itself. It is a better fit for the prometheus-users mailing
list, see https://groups.google.com/forum/#!forum/prometheus-users

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

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Bjoern Rabenstein]

Just my 2¢:

I'm firmly in the camp of hand-creating the CHANGELOG. I do so many
editorial work on it that a pre-populated CHANGELOG might easily
create more work than it saves. I do have to understand anyway what
each change is doing as we are supposed to filter out changes that are
not user-visible/-impacting (which could as well be that a
user-visible change was introduced with its corresponding CHANGELOG
entry, but later it was removed again before a release happened).

I'm essentially doing what Brian is doing when I cut a release. I only
found that problematic after releases were procrastinated for too long
and the CHANGELOG exploded. With the fixed cadence in
prometheus/prometheus, that isn't really a problem anymore (but 2.16.0
was a biggie nevertheless).

What is a problem is unclear or incomplete commit and/or PR
descriptions. I guess we can all agree to ask for those in reviews.

I don't feel strongly about how in detail we want to encourage good
commit and PR descriptions. If we put a hint in there to suggest a
changelog line if applicable, I'm all for it. If people want a
specific keyword to autoextract it, sure, as long as I don't have to
use it and it doesn't make it harder to contribute.

I would not like to directly edit the CHANGELOG.md file in each PR,
for all the reasons already stated.

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

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Julien Pivotto]

On 14 Feb 23:30, 'Matthias Rampke' via Prometheus Developers wrote:
> How do I make it so there is no entry?

There is still work to be done after the changelog is generated.

> 
> On Fri, 14 Feb 2020, 18:07 Simon Pasquier,  wrote:
> 
> > Correct, the PR is in the promu repository (I've updated it just now
> > to address comments from Brian though it should have been done long
> > ago):
> > https://github.com/prometheus/promu/pull/170
> >
> > Right now, it leverages the PR labels to classify the change (BUGFIX,
> > CHANGE, ...) and it uses the PR's title as the changelog entry. It
> > wouldn't be hard to mimic what Kubernetes is doing and lookup the
> > changelog entry in the PR description as Matthias suggested. If
> > nothing is found it can always fallback to the title.
> > I agree that asking every PR to include the changelog update might not
> > be convenient (both for the contributor and the maintainer).
> >
> > On Fri, Feb 14, 2020 at 8:10 AM Frederic Branczyk 
> > wrote:
> > >
> > > I recall Simon having a tool that would largely generate the changelog
> > automatically, that worked pretty well last time I was release shepherd.
> > Otherwise I'm also happy to discuss a process like in Kubernetes where the
> > changelog item is written into the PR. On Thanos we have in the PR template
> > that people have ensured that the changelog item was added respective to
> > the change. Seems like there are options, I personally would favor
> > something that would be done at contribution time, so not all the
> > responsibility falls on the release shepherd as it does today, and more
> > generally it seems like the person contributing the change probably is also
> > a good candidate to describe it in the changelog.
> > >
> > > On Fri, 14 Feb 2020 at 08:05, Callum Styan 
> > wrote:
> > >>
> > >> Hi all,
> > >>
> > >> I'd like to start a discussion around changing how we manage the
> > prometheus/prometheus changelog, specifically the fact that the changelog
> > is generated manually by the release shepherd as part of the release
> > process.
> > >>
> > >> We can discuss options for what the new process would look like, such
> > as requiring PR's to include changelog entries before merging or the next
> > release shepherd periodically updating the changelog prior to the release,
> > in more detail later. However I'd first like to get a sense of whether
> > anyone else feels strongly about either changing or not changing this part
> > of the release process.
> > >>
> > >> Thanks,
> > >> Callum.
> > >>
> > >> --
> > >> 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/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.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/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.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/CAM6RFu79WLX7ZZezxMvQdinV5VMdP-0pfPSfTPs45g7RO-qGcA%40mail.gmail.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/CAFU3N5XcbOkOrPVrQ-Mzd-FX%2B7W%2B6kdL_uKOCQ%3DLn1X8f2%2BdtQ%40mail.gmail.com.

-- 
 (o-Julien Pivotto
 //\Open-Source Consultant
 V_/_   Inuits - https://www.inuits.eu

-- 
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/20200215122002.GA8431%40oxygen.


signature.asc
Description: PGP signature

Re: [prometheus-developers] prometheus/prometheus Changelog Management

['Matthias Rampke' via Prometheus Developers]

How do I make it so there is no entry?

On Fri, 14 Feb 2020, 18:07 Simon Pasquier,  wrote:

> Correct, the PR is in the promu repository (I've updated it just now
> to address comments from Brian though it should have been done long
> ago):
> https://github.com/prometheus/promu/pull/170
>
> Right now, it leverages the PR labels to classify the change (BUGFIX,
> CHANGE, ...) and it uses the PR's title as the changelog entry. It
> wouldn't be hard to mimic what Kubernetes is doing and lookup the
> changelog entry in the PR description as Matthias suggested. If
> nothing is found it can always fallback to the title.
> I agree that asking every PR to include the changelog update might not
> be convenient (both for the contributor and the maintainer).
>
> On Fri, Feb 14, 2020 at 8:10 AM Frederic Branczyk 
> wrote:
> >
> > I recall Simon having a tool that would largely generate the changelog
> automatically, that worked pretty well last time I was release shepherd.
> Otherwise I'm also happy to discuss a process like in Kubernetes where the
> changelog item is written into the PR. On Thanos we have in the PR template
> that people have ensured that the changelog item was added respective to
> the change. Seems like there are options, I personally would favor
> something that would be done at contribution time, so not all the
> responsibility falls on the release shepherd as it does today, and more
> generally it seems like the person contributing the change probably is also
> a good candidate to describe it in the changelog.
> >
> > On Fri, 14 Feb 2020 at 08:05, Callum Styan 
> wrote:
> >>
> >> Hi all,
> >>
> >> I'd like to start a discussion around changing how we manage the
> prometheus/prometheus changelog, specifically the fact that the changelog
> is generated manually by the release shepherd as part of the release
> process.
> >>
> >> We can discuss options for what the new process would look like, such
> as requiring PR's to include changelog entries before merging or the next
> release shepherd periodically updating the changelog prior to the release,
> in more detail later. However I'd first like to get a sense of whether
> anyone else feels strongly about either changing or not changing this part
> of the release process.
> >>
> >> Thanks,
> >> Callum.
> >>
> >> --
> >> 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/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.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/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.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/CAM6RFu79WLX7ZZezxMvQdinV5VMdP-0pfPSfTPs45g7RO-qGcA%40mail.gmail.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/CAFU3N5XcbOkOrPVrQ-Mzd-FX%2B7W%2B6kdL_uKOCQ%3DLn1X8f2%2BdtQ%40mail.gmail.com.

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Simon Pasquier]

Correct, the PR is in the promu repository (I've updated it just now
to address comments from Brian though it should have been done long
ago):
https://github.com/prometheus/promu/pull/170

Right now, it leverages the PR labels to classify the change (BUGFIX,
CHANGE, ...) and it uses the PR's title as the changelog entry. It
wouldn't be hard to mimic what Kubernetes is doing and lookup the
changelog entry in the PR description as Matthias suggested. If
nothing is found it can always fallback to the title.
I agree that asking every PR to include the changelog update might not
be convenient (both for the contributor and the maintainer).

On Fri, Feb 14, 2020 at 8:10 AM Frederic Branczyk  wrote:
>
> I recall Simon having a tool that would largely generate the changelog 
> automatically, that worked pretty well last time I was release shepherd. 
> Otherwise I'm also happy to discuss a process like in Kubernetes where the 
> changelog item is written into the PR. On Thanos we have in the PR template 
> that people have ensured that the changelog item was added respective to the 
> change. Seems like there are options, I personally would favor something that 
> would be done at contribution time, so not all the responsibility falls on 
> the release shepherd as it does today, and more generally it seems like the 
> person contributing the change probably is also a good candidate to describe 
> it in the changelog.
>
> On Fri, 14 Feb 2020 at 08:05, Callum Styan  wrote:
>>
>> Hi all,
>>
>> I'd like to start a discussion around changing how we manage the 
>> prometheus/prometheus changelog, specifically the fact that the changelog is 
>> generated manually by the release shepherd as part of the release process.
>>
>> We can discuss options for what the new process would look like, such as 
>> requiring PR's to include changelog entries before merging or the next 
>> release shepherd periodically updating the changelog prior to the release, 
>> in more detail later. However I'd first like to get a sense of whether 
>> anyone else feels strongly about either changing or not changing this part 
>> of the release process.
>>
>> Thanks,
>> Callum.
>>
>> --
>> 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/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.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/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.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/CAM6RFu79WLX7ZZezxMvQdinV5VMdP-0pfPSfTPs45g7RO-qGcA%40mail.gmail.com.

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Callum Styan]

>
> Even with all that the release shepard would still need to go through all
> the commits and double check that nothing was missed, plus fixing poor
> wording. I don't think saving 2-3 minutes off a release is worth all these
> downsides.


I agree with Bartek's response here, it's not a 2-3 minute process at all.
Not everyone is familiar with as many areas of the prometheus/prometheus
code as you are, and we're not reviewing or merging most of the PR's in
areas we don't know about. Another factor is the fact that commit messages
and PR descriptions vary widely, and in some cases merged PR's had no
descriptions and commit messages that did not really accurately reflect the
user facing change of the PR.

Even with all these changes, the only thing you'd save is the
> copying&pasting bit as the release shepard still needs to do all of the
> rest which is why I'm saying 2-3 minutes.

The point is the messages you're copy/pasting are not necessarily accurate,
and again it's not 2-3 minutes.

DCO is a strawman argument. We're always going to have issues with
> submission quality.

Yes. While I think the delaying of PR merges and having to rebase because
of CHANGELOG.md are valid concerns, I don't think we should choose not to
adopt some improved changelog management based on these reasons. As you
say, we're always going to have issues with varying quality of drive by
submissions. We can only do our best to encourage people submitting those
PR's to be good citizens and help make our lives easier.

Right now I'm liking Matthias' idea:

> My ideal flow would be:

- the PR template has an empty entry for the changelog. a 
> encourages contributors to fill it in but notes that the maintainers will
> take care of it
> - it also has an optional entry for additional changelog remarks (we can
> leave this out if it's too much)
> - as the maintainer, if I want to change or edit it, I edit the PR
> description
> - if we don't want an entry for the PR, we delete it or leave it empty
> - once I hit merge, an automatic mechanism adds both to the changelog (can
> CircleCI commit?)

- when creating the release, the shepherd only looks over the changelog,
> possibly adds or consolidates notes about an overarching theme (say, if
> multiple PRs together introduce a change)


I also like the idea of a prombot command like Julien brought up.

-- 
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/CAN2d5ORVNwUb4JUEYGZ%2BN0buAg1ndvz_H3hEAUd%3DskZHMCV1KA%40mail.gmail.com.

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Ben Kochie]

But we don't have to block on changelog entries like we do for DCO legal
requirements.

For example, in GitLab codebases, we have a CI test that warns if a
changelog entry is missing. Unless you tag the review with a label.

On Fri, Feb 14, 2020 at 2:22 PM Brian Brazil <
brian.bra...@robustperception.io> wrote:

> On Fri, 14 Feb 2020 at 13:15, Matthias Rampke  wrote:
>
>> The friction is real – DCO is not a submission quality issue but a
>> roundtrip one. This would be even more difficult with wording.
>>
>
> I'm with Matthias on this one. We've often have PRs which are ready to
> merge, but have been sitting there months waiting for a DCO.
>
> Brian
>
>
>>
>>  I agree that in *many* cases contributors can write the changelog
>> entry; having the field in the PR template would encourage them to do so
>> proactively.
>>
>> /MR
>>
>> On Fri, Feb 14, 2020 at 1:12 PM Ben Kochie  wrote:
>>
>>> DCO is a strawman argument. We're always going to have issues with
>>> submission quality.
>>>
>>> I've had very good luck asking for changelog entries on the
>>> node_exporter.
>>>
>>> On Fri, Feb 14, 2020 at 8:22 AM Brian Brazil <
>>> brian.bra...@robustperception.io> wrote:
>>>
 On Fri, 14 Feb 2020 at 07:10, Frederic Branczyk 
 wrote:

> I recall Simon having a tool that would largely generate the changelog
> automatically, that worked pretty well last time I was release shepherd.
> Otherwise I'm also happy to discuss a process like in Kubernetes where the
> changelog item is written into the PR. On Thanos we have in the PR 
> template
> that people have ensured that the changelog item was added respective to
> the change. Seems like there are options,
>



> I personally would favor something that would be done at contribution
> time, so not all the responsibility falls on the release shepherd as it
> does today, and more generally it seems like the person contributing the
> change probably is also a good candidate to describe it in the changelog.
>

 This is additional friction to contributions, we already have enough
 fun getting the DCO signed. It's also an additional burden on every single
 PR, we need to individually figure out if it's worth mentioned in the
 changelog (many PRs aren't) and then get it in the right category, with
 good wording, and handling the regular conflicts as everyone would be
 touching the same lines in the same file.

 Even with all that the release shepard would still need to go through
 all the commits and double check that nothing was missed, plus fixing poor
 wording. I don't think saving 2-3 minutes off a release is worth all these
 downsides.

 Brian


>
> On Fri, 14 Feb 2020 at 08:05, Callum Styan 
> wrote:
>
>> Hi all,
>>
>> I'd like to start a discussion around changing how we manage the
>> prometheus/prometheus changelog, specifically the fact that the changelog
>> is generated manually by the release shepherd as part of the release
>> process.
>>
>> We can discuss options for what the new process would look like, such
>> as requiring PR's to include changelog entries before merging or the next
>> release shepherd periodically updating the changelog prior to the 
>> release,
>> in more detail later. However I'd first like to get a sense of whether
>> anyone else feels strongly about either changing or not changing this 
>> part
>> of the release process.
>>
>> Thanks,
>> Callum.
>>
>> --
>> 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/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.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/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.com
> 
> .
>


 --
 Brian Brazil
 www.robustperception.io

 --
 You received this message

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Ben Kochie]

The way I've been doing it in the node_exporter is to ask for the changelog
entry, but I don't block on it. If the code is ok, but they don't add a
changelog entry, I'll merge and do it myself.

Usually what saves the round trip time is I include a copy-paste text of
exactly what I want in the changelog, rather than leave it up to them to
have to figure it out.

For example:
https://github.com/prometheus/node_exporter/pull/1580#issuecomment-569954208

On Fri, Feb 14, 2020 at 2:15 PM Matthias Rampke  wrote:

> The friction is real – DCO is not a submission quality issue but a
> roundtrip one. This would be even more difficult with wording.
>
>  I agree that in *many* cases contributors can write the changelog entry;
> having the field in the PR template would encourage them to do so
> proactively.
>
> /MR
>
> On Fri, Feb 14, 2020 at 1:12 PM Ben Kochie  wrote:
>
>> DCO is a strawman argument. We're always going to have issues with
>> submission quality.
>>
>> I've had very good luck asking for changelog entries on the node_exporter.
>>
>> On Fri, Feb 14, 2020 at 8:22 AM Brian Brazil <
>> brian.bra...@robustperception.io> wrote:
>>
>>> On Fri, 14 Feb 2020 at 07:10, Frederic Branczyk 
>>> wrote:
>>>
 I recall Simon having a tool that would largely generate the changelog
 automatically, that worked pretty well last time I was release shepherd.
 Otherwise I'm also happy to discuss a process like in Kubernetes where the
 changelog item is written into the PR. On Thanos we have in the PR template
 that people have ensured that the changelog item was added respective to
 the change. Seems like there are options,

>>>
>>>
>>>
 I personally would favor something that would be done at contribution
 time, so not all the responsibility falls on the release shepherd as it
 does today, and more generally it seems like the person contributing the
 change probably is also a good candidate to describe it in the changelog.

>>>
>>> This is additional friction to contributions, we already have enough fun
>>> getting the DCO signed. It's also an additional burden on every single PR,
>>> we need to individually figure out if it's worth mentioned in the changelog
>>> (many PRs aren't) and then get it in the right category, with good wording,
>>> and handling the regular conflicts as everyone would be touching the same
>>> lines in the same file.
>>>
>>> Even with all that the release shepard would still need to go through
>>> all the commits and double check that nothing was missed, plus fixing poor
>>> wording. I don't think saving 2-3 minutes off a release is worth all these
>>> downsides.
>>>
>>> Brian
>>>
>>>

 On Fri, 14 Feb 2020 at 08:05, Callum Styan 
 wrote:

> Hi all,
>
> I'd like to start a discussion around changing how we manage the
> prometheus/prometheus changelog, specifically the fact that the changelog
> is generated manually by the release shepherd as part of the release
> process.
>
> We can discuss options for what the new process would look like, such
> as requiring PR's to include changelog entries before merging or the next
> release shepherd periodically updating the changelog prior to the release,
> in more detail later. However I'd first like to get a sense of whether
> anyone else feels strongly about either changing or not changing this part
> of the release process.
>
> Thanks,
> Callum.
>
> --
> 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/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.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/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.com
 
 .

>>>
>>>
>>> --
>>> Brian Brazil
>>> www.robustperception.io
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Prometheus Developers" group.
>>> To unsubscribe from this group and stop receiving email