[prometheus-developers] Collected reasons why Prometheus doesn't allow dot as a regular character in metric and label names

In a recent thread on this mailing list ("Limiting the blast radius of OTel..."), several people once again suggested that Prometheus should just allow the dot (`.`) as a regular character in metric and label names and be done with it. I responded that we have discussed this topic countless times,

Re: [prometheus-developers] Limiting the blast radius of OTel / UTF-8 support for normal Prometheus users?

I'm trying to keep things short, as all of this had been discussed at length before. WRT "how to explain UTF-8 support to users": I actually don't think this is a huge problem. I would frame it "this is like file names". You can use blanks and slashes in Unix file names, and if you do, it

[prometheus-developers] dev-summit this Thursday

Hi Prometheans, This is a reminder that we have our monthly dev-summit this week: Thursday, 2024-05-23, 1500UTC The link to join is https://meet.google.com/hmj-eyrv-fhr . If you have trouble joining, please yell in #prometheus-dev on the CNCF Slack. (We've had trouble in the past with

Re: [prometheus-developers] Re: metrics TTL for pushgateway

On 19.04.24 01:33, John Yu wrote: > I'm thinking, why can't we deploy an additional prom as an agent to receive > data, and then write to the core prom remotely after receiving the data? > Although I know that this will lead to breaking away from the pull model to > a certain extent, it is

Re: [prometheus-developers] Native Histograms and Pushgateway Backwards Compatibility

On 10.04.24 11:40, 'Fabian Stäber' via Prometheus Developers wrote: > > I'm wondering about backwards compatibility: What happens if I push a > histogram (by default it's both classic and native representation) to an > old Pushgateway that does not have native histogram support? If the native

Re: [prometheus-developers] Protobuf support

Disclaimer: I'm not the expert for remote-write/-read, and only do a little with the protobuf stuff. But since you didn't get an answer in a week, I'm trying now. On 29.02.24 20:38, Clément Jean wrote: > > I finally go around to do this and the unit tests seem to be passing. You > can find what

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

On 02.03.24 08:00, Mirco wrote: > Any reason samples are still encoded as a list of pairs? Using two arrays > would both reduce the number of objects and allow using varint encoding for > timestamps. I assume you are referring to the protobuf messages for TimeSeries and Sample? I'm not an

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

Thanks for doing this. Beyond benchmarks, two general concerns: - How unsafe is `enableunsafedecode=true`? I spot-checked the csproto code, and the risk seems to be on the side of the user code, i.e. luckily there isn't any unsafe input, but I'm wondering how easily we'll introduce bugs in

Re: [prometheus-developers] Re: Call for maintainers: Exporter team

On 17.01.24 11:28, Matt Doughty wrote: > I've gotten so much from prometheus that I would be happy to help, but > I haven't been involved. Just let me know if there is anything I can > do. There is plenty to do. The best is, as I like to say, if you "can scratch your own itch" - work on

[prometheus-developers] Proposing George Krajcsovits as maintainer for native histogram related code in prometheus/prometheus

I hereby propose George Krajcsovits AKA Krajo as a maintainer for the native histogram related code in prometheus/prometheus. Krajo has contributed a lot of native histogram code, but more importantly, he has contributed substantially to reviewing other contributors' native histogram code, up to a

Re: [prometheus-developers] Re: Call for maintainers: Exporter team

On 15.01.24 10:00, gitperr wrote: > > Currently, I have some MRs waiting for review/help in different parts of > the project. > https://github.com/prometheus/golang-builder/pull/239 > https://github.com/prometheus/node_exporter/pull/2833 Thanks for your contributions. The first PR seems to be

Re: [prometheus-developers] [Feature/Proposal] Concurrent evaluation of independent rules

On 28.10.23 04:32, Danny Kopping wrote: > > The feature is hidden behind a feature-flag, but I would argue that we can > drop the flag and simply set --rules.max-concurrent-evals=0 as default which > is functionally equivalent to not having any concurrency at all (the > current behaviour);

Re: [prometheus-developers] Protobuf support

On 05.10.23 17:48, Clément Jean wrote: > I'm not entirely sure yet because I'm new to contributing to prometheus. If > there is any use cases that you guys already discussed around Protobuf, I'd > be happy to help. If you are really deep into protobuf, there is definitely one big and fat issue

Re: [prometheus-developers] Protobuf support

On 03.10.23 18:06, Clément Jean wrote: > > I met with Richard Hartmann at KubeCon Shanghai and he mentioned that the > team is interested in adding support for Protobuf. I'm here to see what I > can do to help. If you have any recommendation on how to get started, I'd > be happy to start

Re: [prometheus-developers] In-person dev-summit this Saturday in Berlin

The dev summit has started, and here is the link for online participation: https://meet.google.com/uvm-fcst-bsc See you there. -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] bjo...@rabenste.in -- You received this message because you are subscribed to the Google Groups "Prometheus

[prometheus-developers] In-person dev-summit this Saturday in Berlin

Dear Prometheans, as you might have noticed, this week PromCon is happening in Berlin, see https://promcon.io . Following our ancient traditions, there will be an in-person developer summit on the day after PromCon, which is Saturday (2023-09-30). We'll start 06:30 UTC (08:30 CEST) with coffee

Re: [prometheus-developers] client_golang: updating client_model dependency to 0.4.0

On 17.07.23 16:47, Daniel Swarbrick wrote: > > But now we get to the ugly stuff. There are several testable examples in > the client_golang package, which compare the example code's text marshaled > metrics output to the golden "// Output:" text. As you've probably guessed, > these now all

Re: [prometheus-developers] Prometheus Pushgateway TTL

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

Re: [prometheus-developers] Prometheus Pushgateway TTL

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

Re: [prometheus-developers] Prometheus Pushgateway TTL

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

Re: [prometheus-developers] Prometheus Pushgateway TTL

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

Re: [prometheus-developers] New Prometheus client library for Delphi

On 26.03.23 07:40, Marco Breveglieri wrote: > > But let's get to the point: is there any path that I could walk to get this > client listed in the "Unofficial third-party client libraries" page > (https://prometheus.io/docs/instrumenting/clientlibs/) on Prometheus > website? Create a PR

Re: [prometheus-developers] Should Alertmanager be more tolerant of templating errors?

On 07.02.23 05:57, 'George Robinson' via Prometheus Developers wrote: > > While I appreciate the responsibility of writing correct templates is on > the user, I have also been considering whether Alertmanager should be more > tolerant of template errors, and attempt to send some kind of

Re: [prometheus-developers] Reserved labels in client libraries

On 08.02.23 09:50, Chris Sinjakli wrote: > > Am I right in thinking that client libraries generally don't reserve any > label names outside of ones prefixed with double underscore? I'm curious if > this is something that's changed over time in other clients and we've not > kept up, or if at

[prometheus-developers] Brainstorming doc about quoting for metric and label names

Hi Prometheans, at the last in-person dev-summit in Munich, we talked a lot about how to allow arbitrary UTF-8 characters in metric and label names (or maybe just allow a few like "." and "/"...). We also had some whiteboarding and brainstorming in the breaks, which isn't reflected in the

Re: [prometheus-developers] Is the +Inf bucket optional?

On 17.01.23 10:01, 'Fabian Stäber' via Prometheus Developers wrote: > > I'm having trouble figuring out if the +Inf bucket is optional. > > The client_model protobuf says it's optional: > > >

[prometheus-developers] Some ideas about native histograms and the text format

Dear Prometheans, I've just chatted to a few of you abouh options for the text format representation of native histograms. Here is a doc with the ideas we discussed: https://docs.google.com/document/d/1w6GhLmDYKkkNLsyPWkC3TGhW3Rs1G73j7E_nG7bhlw0/edit?usp=sharing This is especially relevant if

Re: [prometheus-developers] Windows Exporter License

On 13.12.22 11:19, Julien Pivotto wrote: > > In this sense, I think we should ask for an exception to the GB with the > following arguments: Silence means consent, right? But just in case you are wondering if anyone has read your message, I think it makes complete sense, and I fully agree with

Re: [prometheus-developers] Changing consensus on HTTP headers

On 06.12.22 23:15, Julien Pivotto wrote: > > https://github.com/prometheus/prometheus/issues/1724 > > Quoting Brian in 2016: > > The question here is how complex do we want to allow scraping protocol > > to be, and how complex a knot are we willing to let users tie themselves > > in via the core

Re: [prometheus-developers] [VOTE] Promote Windows Exporter as an official exporter

On 06.12.22 23:05, Julien Pivotto wrote: > > I had two things in mind when calling the actual move to a vote: > > 1. I considered that the Windows exporter had a large community of users >and that taking the decision in public would be good for the community. >Some people might object

Re: [prometheus-developers] [VOTE] Promote Windows Exporter as an official exporter

YES For the record: While I agree with the proposal, I do not think it requires a vote. I'm mostly mentioning it here so that nobody will see this as a precedent or a role model that we will require votes from now on on every new repository in the Prometheus GH org or something. I think of

Re: [prometheus-developers] Changing consensus on HTTP headers

On 28.11.22 11:29, Julien Pivotto wrote: > > However, I have crafted a pull request that changes that consensus and > makes HTTP headers configurable in the common HTTP client, with some > reserved headers. For findability: https://github.com/prometheus/common/pull/416 > What does the community

Re: [prometheus-developers] Name for new histograms

On 13.11.22 21:21, 'Fabian Stäber' via Prometheus Developers wrote: > > I'm struggling with the name "native histograms" while implementing it in > client_java because it does not imply a good name for the old histograms > (maybe non-native histograms?). I usually used the term "conventional

Re: [prometheus-developers] Prometheus client_model protobuf question

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

Re: [prometheus-developers] Exemplars for _count in Summaries

On 06.10.22 14:45, 'Fabian Stäber' via Prometheus Developers wrote: > > Great question from the CNCF Slack: What's the reason why we don't allow > Exemplars for _count in Summary metrics? > > What do you think? Any reason why Exemplars don't work in _count in > Summaries? Would that be

[prometheus-developers] Dev summit this Thursday

Hi Prometheans, We finally have a (virtual) dev-summit again this Thursday 2022-09-22, 15:00 UTC, see https://docs.google.com/document/d/11LC3wJcVk00l8w5P3oLQ-m3Y37iom6INAMEu2ZAGIIE/edit Unfortunately, I have to help out with an all-day event run by my employer and very likely won't be able to

Re: [prometheus-developers] Re: Prometheus Events and Calendar

Oops. Various balls got dropped here, including not responding to this email thread in a timely fashion. I am very sorry. We had a discussion in the Prometheus team today, and we came up with a plan to organize these meetings in a more reliable fashion. Stay tuned... On 24.08.22 22:20, Alolita

Re: [prometheus-developers] Inf buckets in Native Histograms

On 06.09.22 02:50, 'Fabian Stäber' via Prometheus Developers wrote: > > Looking at client_golang, it seems you can observe math.Inf(), and bucket > index math.MaxInt32 is used to represent the Inf bucket. > >

Re: [prometheus-developers] When to merge native histograms into main branch?

On 01.08.22 06:28, Ganesh Vernekar wrote: > > We have come up with a checklist of items with P0-P4 priorities for the > native histogram work (See here > > ). > > The native histogram work

Re: [prometheus-developers] What if Prometheus to Scape Anything from Anywhere with embedded Zero Trust?

On 10.06.22 17:48, Rudford Hamon wrote: > Yes :) What would be the best approach to see adoption and letting the > community collectively know/try? I guess you did the right thing already. A web search for "openziti prometheus" gives tons of relevant results and discussions. This list

Re: [prometheus-developers] What if Prometheus to Scape Anything from Anywhere with embedded Zero Trust?

On 01.06.22 11:28, Rudford Hamon wrote: > > For example, OpenZiti has a tunneler embedded with zero trust that > can be used to connect (upstream or downstream) with a few lines of > code. Super flexible and doesn't require any changes to your > binaries. Also, as you mentioned, this will give the

Re: [prometheus-developers] What if Prometheus to Scape Anything from Anywhere with embedded Zero Trust?

On 23.05.22 15:24, Rudford Hamon wrote: > > So, I am part an open source project called OpenZiti, where you can embed > zero trust networking into anything (apps-to-apps, server-to-apps, > server-to-server, etc) and be completely invisible while using basic > community internet. VPNs,

Re: [prometheus-developers] RFC: The implementation of labels.Labels

On 12.05.22 17:07, Bryan Boreham wrote: > > If there is interest I will make a PR containing just the above change, no > change to the structure labels.Labels itself as yet. I'm definitely interested. ;o) -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] bjo...@rabenste.in -- You

Re: [prometheus-developers] OpenMetrics Summary Created Timestamp

On 24.05.22 15:54, Brian Brazil wrote: > On Tue, 24 May 2022 at 15:38, 'Fabian Stäber' via Prometheus Developers < > prometheus-developers@googlegroups.com> wrote: > > > > > I'm wondering: Is this how the Created timestamp for Summary metrics is > > supposed to be implemented? > > > > Unless I

Re: [prometheus-developers] Help the Alertmanager repository

On 15.03.22 07:32, 'Josh Abreu Mesa' via Prometheus Developers wrote: > Dear Prometheus Developers, > > Now that I finally have some long-term dedicated time to spend on the > Alertmanager, I'd like to know which area(s) do you consider that need help > the most? I have some vague TODO notes

[prometheus-developers] Save the date: in-person dev-summit as part of KubeCon + CloudNativeCon Europe

Hi Prometheus developers, Finally, we will have an in-person developer summit again. It will be a pre-conference event prior to KubeCon + CloudNativeCon Europe in Valencia, Spain. It will happen Monday, 2022-05-16, 08:00–15:00 CEST (06:00-13:00 UTC). We will get a room at the conference venue,

Re: [prometheus-developers] Context and Timeouts in client_golang

Hi Joe, I think you got the below quite right in general. The most relevant prior discussion I know of is starting at this GH comment (hidden in the issue about not using channels in the Collector interface): https://github.com/prometheus/client_golang/issues/228#issuecomment-475214970

[prometheus-developers] Brainstorming doc for Histogram JSON format

Hi devs, a crucial piece of the puzzle missing in the Sparse Histogram PoC (you can find it in the https://github.com/prometheus/prometheus/tree/sparsehistogram branch) is the representation of the new histograms in the JSON returned by the Prometheus query API. I created a exploratory document

Re: [prometheus-developers] [VOTE] Rename blackbox_exporter to prober

NO Not feeling strongly, actually. In general, I'm not sure if the renaming itself will have a positive or negative effect (pretty much along the lines of Marcelo's mail). Add to that the overhead and confusion that comes with any renaming, I end up with a net-negative. I explicitly don't want

Re: [prometheus-developers] Evolving remote APIs

On 25.11.21 10:35, Fabian Reinartz wrote: > > The point on TSDB becoming more structured is interesting – how firm are > these plans at this point? Any rough timelines? I hope there will be a PoC for histograms in two or three months. It's hard to estimate how long it will take after that to

Re: [prometheus-developers] Evolving remote APIs

On 18.11.21 16:36, 'Fabian Reinartz' via Prometheus Developers wrote: > > A central issue is that the remote APIs expose the Prometheus storage data > model. It is notably different from the Prometheus/OpenMetrics > instrumentation model and discards most of the structure known at scrape > time.

Re: [prometheus-developers] Feature request: Setting a custom lookback delta for a query

As a short- to mid-term remedy, I like the idea of a lookback-delta per query. Long-term, I would prefer if we could get rid of the lookback delta altogether. We want richer metadata anyway, and part of it could be when a series starts and ends and what the configured scrape interval was. Once we

Re: [prometheus-developers] Enable auto merge

On 16.11.21 14:17, Levi Harrison wrote: > > Recently, I've come across a few instances where auto-merge would have been > helpful and was wondering if consensus had been reached here. My impression was that the discussion dwindled because it became increasingly unclear what we are even

Re: [prometheus-developers] Updating the Prometheus "Roadmap" page

On 02.11.21 14:48, Julius Volz wrote: > > As Björn pointed out somewhere, our roadmap page at > https://prometheus.io/docs/introduction/roadmap/ is pretty outdated. I'd > encourage everyone who is working on great new roadmap items (sparse > histograms are an obvious candidate, but maybe

[prometheus-developers] HEADS-UP: Packages will be moved out of prometheus/prometheus/pkg

Dear Prometheus developers, On 2021-08-22, the Prometheus dev summit has expressed a consensus to deprecate the `pkg` directory, see https://docs.google.com/document/d/11LC3wJcVk00l8w5P3oLQ-m3Y37iom6INAMEu2ZAGIIE/edit?pli=1#heading=h.80qrixk0sjgv The `pkg` directory is used in some (but not all)

[prometheus-developers] Explaratory document: Sparse Histograms and PromQL

Dear Prometheans, As you might know, we are busily working on implementing the new sparse high-res histograms (commonly called “Sparse Histograms”). Progress can be tracked in the `sparsehistogram` branch of various repos: - https://github.com/prometheus/prometheus/tree/sparsehistogram -

Re: [prometheus-developers] regarding missing some timeseries data differs in millisecond in prometheus

On 06.10.21 23:18, Prince wrote: > I am monitoring an application. For which Prometheus server is scraping the > matrices at the endpoint along with the timestamp. > But in prometheus graph It is not getting displayed for timestamps that are > differ in millisecond. For eg: >

Re: [prometheus-developers] Change the focus of our docs section

On 05.10.21 11:22, Richard Hartmann wrote: > > Within Docs WG[1] we realized that we're blocking ourselves. We're > front-loading huge amounts of work which no one of us can > realistically perform in the site setup. On the content side, we carry > huge PRs which are always out of date and a pain

Re: [prometheus-developers] what's experimental .. again

Thanks, Julien, for bringing this to the mailing list, and apologies for my late reply. Despite the long time I needed to reply, only one other reply (by l.mierzwa) has happened. Not sure if that means there is not much interest in the topic, or everyone else agrees with Julien. Anyway, here is

Re: [prometheus-developers] Combining multiple metric to show on one graph in Prometheus

On 13.09.21 03:20, Prince wrote: > > I want to combine two metrics in such a way that both should be displayed > on one graph in Prometheus. For eg: > metric_one{label1:value1} 123 > metrci_two{label2:value2} 345 > > I want these metrics should be displayed on one chart in Prometheus.

Re: [prometheus-developers] Adding timestamps to Gauge Metric

On 31.08.21 04:27, Prince wrote: > > for NewMetricWithTimestamp(time.Time,metric) Is it compulsory that the > time should be in UTC? Short answer: No. The Go `time.Time` type includes the time zone. It can use any time zone. The library will then use the capabilities of the Go `time.Time`

Re: [prometheus-developers] Deprecating https://github.com/prometheus/nagios_plugins (?)

On 18.08.21 12:03, Julien Pivotto wrote: > We should graveyard it. If you are concerned about redirecting people to > the fork, we should transfer the ownership of the repo. Yeah, but transferring the ownership will require quite a risky dance (because the fork already exists for a while, see my

Re: [prometheus-developers] Deprecating https://github.com/prometheus/nagios_plugins (?)

On 17.08.21 10:54, Matthias Rampke wrote: > I think the no-magic route is better. You can also archive the repo[0] to > make it clear that it's read only (with this GitHub feature, do we still > need to graveyard anything ourselves? That's a good idea. I'll do just that. In general, I think it

[prometheus-developers] Deprecating https://github.com/prometheus/nagios_plugins (?)

Hi, More than a year ago, I added a pointer from https://github.com/prometheus/nagios_plugins (the "old repo") to its fork https://github.com/magenta-aps/check_prometheus_metric (the "new repo"), see https://github.com/prometheus/nagios_plugins/pull/26 . I've never heard any complaints about the

Re: [prometheus-developers] How about adding some anomaly detection functions in the promql/function.go file

On 25.06.21 01:27, Shandong Dong wrote: > Ok, I will try the PR first. Can I know what‘s the concern of "Personally, > I'm still not sure if that's a sustainable approach. "? We had a handful of requests in the past to add specific advanced statistics functions. In one case, a function was

Re: [prometheus-developers] How about adding some anomaly detection functions in the promql/function.go file

On 24.06.21 00:05, 董善东 wrote: > hi,all > In the existing prometheus version, the anomaly detection still relies > fully on the rules setting. We find that it is inconvenient to set and hard > to maintain in practical use. > So I propose to add some statistical analysis functions to provide

Re: [prometheus-developers] Requirements / Best Practices to use Prometheus Metrics for Serverless environments

On 22.06.21 11:26, Tobias Schmidt wrote: > > Last night I was wondering if there are any other common interfaces > available in serverless environments and noticed that all products by AWS > (Lambda) and GCP (Functions, Run) at least provide the option to handle log > streams, sometimes even log

Re: [prometheus-developers] Requirements / Best Practices to use Prometheus Metrics for Serverless environments

On 15.06.21 20:59, Bartłomiej Płotka wrote: > > Let's now talk about FaaS/Serverless. Excellent! That's my 2nd favorite topic after histograms. (And while I provably talked about histograms as my favorite topic since early 2015, I have only started to talk about FaaS/Serverless as an important

Re: [prometheus-developers] Add metric for scrape timeout

On 06.06.21 09:56, Christian Galsterer wrote: > There are metrics for the actual scrape duration but currently there are no > metrics for the scrape timeouts. Adding metrics for the scrape timeout > would it make possible to monitor and alert on scrape timeouts without > hard-coding the

Re: [prometheus-developers] Alerting rule for gauge metric with new label value

[Redirecting this to prometheus-users@ and bcc'ing prometheus-developers@ because it is about using Prometheus, not developing it.] On 05.06.21 10:00, karthik reddy wrote: > > > Hello Developers, > > Please let me know how to create alerting rule such that, whenever > Prometheus scrapes a

[prometheus-developers] New maintainers for prometheus/client_golang

Hi Prometheans, I'm retiring as a maintainer of prometheus/client_golang, focusing on other projects within the Prometheus ecosystem (like, who would have guessed, the new histograms...). Please welcome the new maintainers: * Bartłomiej Płotka @bwplotka * Kemal Akkoyun @kakkoyun If you want

Re: [prometheus-developers] count_values string formatting

On 06.05.21 16:41, Julien Pivotto wrote: > On 06 May 14:01, Bjoern Rabenstein wrote: > > Initially, I intuitively thought we should do what Julien has now > > proposed, too. However, in the course of the discussion, I then > > convinced myself that Tristan's approach makes mo

Re: [prometheus-developers] count_values string formatting

Initially, I intuitively thought we should do what Julien has now proposed, too. However, in the course of the discussion, I then convinced myself that Tristan's approach makes more sense. So maybe we all have to go through these stages. (o: -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03

Re: [prometheus-developers] count_values string formatting

As you can guess from my comments on the issue, I like the idea. Formatting is a problem if you put a number into a string. And while I doubt that `FormatFloat` has any guarantees of always formatting in the same way across Go versions and platforms, at least we can help the user a bit here. On

Re: [prometheus-developers] FR/Discuss: Enable non-collection of metrics based on curried labels

On 30.03.21 17:42, Aaron Gable wrote: > > Suppose I have a `CounterVec` that I call `requestsCounter`, with labels > `method` (whose values are only `GET` and `POST`) and `success` (whose > values are only `true` and `false`). Maybe I have a set of unittests which > implement a

Re: [prometheus-developers] [VOTE] Allow environment variable expansion on external label values

On 25.03.21 23:06, Julien Pivotto wrote: > Hereby I am calling a vote to allow the expansion on environment > variables in the prometheus configuration file. > Because it can be seen as an override of a previous vote[1], I am calling a > new vote for this specific part. > > The consensus in the

[prometheus-developers] Prometheus dev summit TODAY

Hi Prometheans, Sorry for the very late notice. The idea was to send out this announcement earlier. We have the March developer summit today, at 15:00 UTC (i.e. in 30m). Use https://meet.google.com/hmj-eyrv-fhr to join the Google Meet. Or even better, have a look at our public calendar, which

Re: [prometheus-developers] Add collector for database/sql#DBStats

On 23.03.21 14:31, Julien Pivotto wrote: > > I find what we do with Java quite nice: > > https://github.com/prometheus/client_java Could you be more specific what you are referring to? > Unfortunately for golang, it will be more difficult for at least 2 > releases, the time for go mod lazy

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

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

[prometheus-developers] PromCon CfP deadline this Friday! (was: PromCon 2021 virtEUl CfP now open)

Hi all, In contrast to what was announced previously (see below), the deadline for the PromCon online 2021 will be this Friday, 2021-03-05. See https://promcon.io/2021-online/submit/ . On 09.02.21 14:42, Richard Hartmann wrote: > Dear all, > > * CfP runs until 2021-04-02 > * Event co-hosted

[prometheus-developers] Configuration: Should we generally enable reading secrets from files?

Hi Prometheans, Container orchestration platforms like Kubernetes offer secrets management. K8s provides those secrets directly to the Kubelet, or via environment variables, or as files in a volume that containers can mount, see

[prometheus-developers] RFC: better histograms for Prometheus

Hi Prometheans, tl;dr: I have just published a draft of a design document about better histograms for Prometheus and would appreciate your feedback: https://docs.google.com/document/d/1cLNv3aufPZb3fNfaJgdaRBZsInZKKIHo9E6HinJVbpM/edit?usp=sharing As many of you might know, I have been

Re: [prometheus-developers] Docker images from scratch

On 31.01.21 17:32, Ben Kochie wrote: > Another option is we could fully build our own busybox binary, with the > necessary fixes. > > I'm somewhat in favor of going distroless. With a large number of users > using our container images in Kubernetes, it's less necessary to include > busybox, as

Re: [prometheus-developers] Enable auto merge

On 22.12.20 17:17, Julien Pivotto wrote: > Approve and auto merge are different. Auto merge is another value of the merge > button, next to squash etc. OK, that's different then. I have no objections to an additional button that essentially says "merge this once the tests have passed, and, if

Re: [prometheus-developers] Enable auto merge

On 16.12.20 21:33, Julien Pivotto wrote: > > Can we enable the new github feature, auto-merge, in prometheus > repositories? > > It waits for everything to be green before merging. Auto-merge assumes that all tests green and one valid approval means "please merge". But I don't think that's

Re: [prometheus-developers] Multiple metrics path for Prometheus

There is probably same nuance in arguing if and when this is a good idea and when not. But in fact, the famous https://github.com/kubernetes/kube-state-metrics is doing it. It's not using different paths, but different ports, but that's kind of similar. On the Prometheus side, however, you need

Re: [prometheus-developers] Lazy consensus: Merging options

On 03.12.20 14:15, Ben Kochie wrote: > I'd like to adjust our defaults for GitHub merging settings: > > Right now, we allow all three modes for PR merges. > * Merge commits > * Squash merging > * Rebase merging > > Proposal: Remove rebase merging (aka fast-forward merges) so that we stick to >

Re: [prometheus-developers] converting prometheus.Metric to data suitable for ingesting by prometheus write protocol.

On 02.12.20 02:15, Alexey Lesovsky wrote: > I have metrics received from collector over channel like "chan<- > prometheus.Metric". > The 'prometheus.Metric' is an interface with Desc and Write methods from ' > github.com/prometheus/client_golang/prometheus' package. > > I'd like to send these

Re: [prometheus-developers] Delta usage issues？

On 13.10.20 01:22, linux...@gmail.com wrote: > I want to get the difference between the current time and the past 5 minutes, > but I tried two methods and couldn’t get it > > 1. delta(isphone{name="qq",exname!~"test|test1"}[5m]) > > 2. sum_over_time(isphone{name="qq",exname!~"test|test1"}[5m])

Re: [prometheus-developers] pushgateway new release to address jquery css vuln. when?

On 23.09.20 10:48, Don450 wrote: > My question is, when will the next release of pushgateway? > https://coderelease.io/github/repository/prometheus/pushgateway > > The need is to address security concern jquery < 3.5.0 (pushgateway v1.2.0 > release has jquery-3.4.1) CSS vuln. > > This change

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

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

Re: [prometheus-developers] Remove /api/v2 of Prometheus

On 27.08.20 16:40, Julien Pivotto wrote: > > Do we want to add in the 2.21 release notes that we will remove it in > 2.22? Good idea. But make clear that this is a weird API that probably next to nobody is actually using. Along the lines: "In the unlikely case that you use the HTTP API v2 (list

Re: [prometheus-developers] Docker Hub's upcoming 100 pulls per user/IP limit

On 26.08.20 15:58, Bartłomiej Płotka wrote: > Quay does not plan anything like this, so we could go for quay if we want. I hope the Quay plans won't change once most of the universe has switched from Docker Hub to Quay and the resulting huge traffic increase raises the attention of some people

Re: [prometheus-developers] Docker Hub's upcoming 100 pulls per user/IP limit

On 26.08.20 12:07, Julius Volz wrote: > For a start, I filled out dummy answers (without submitting) to get to see all > the subsequent pages of the application form. You can see all the questions > they ask here: > > https://docs.google.com/document/d/123fdfSGk5_tjdXAE0G1CeVcIpMBy9JBthwG0lwYjMXc

Re: [prometheus-developers] Optimizing Histogram Buckets Format

Hi Bashar, Thanks for your thoughts and ideas. I more or less agree with all of them, namely: - We need sparse histograms. - Cumulative buckets, despite some tactical advantages, are problematic for sparse histograms, while on the other hand a bit of math can always emulate dropping

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

Quoting the governance: “A vote may be called and closed early if enough votes have come in one way so that further votes cannot change the final decision.” This vote is about the following proposal: “Allow Kelvin as a base unit in certain cases and update our documented recommendation and the

Re: [prometheus-developers] [VOTE] Allow listing non-SNMP exporters for devices that can already be monitored via the SNMP Exporter

On 28.05.20 21:30, Julius Volz wrote: > > I therefore call a vote for the following proposal: > > Allow adding exporters to https://prometheus.io/docs/instrumenting/exporters/ >  although the devices or applications that they export data for can already be > monitored via SNMP (and thus via the

Re: [prometheus-developers] Temperature histograms (was: Allow Kelvin as temperature unit in some cases)

On 29.05.20 14:42, Julien Pivotto wrote: > > That said, I don't see why a fridge company couldn't have SLA on fridges > temperature? (99.95% below -21°C; 99.99% below -18°C). It would still be a gauge. And then you run `quantile_over_time` to measure your SLO. Note that you don't need a

Re: [prometheus-developers] Can CollectAndCompare validate range for non-deterministic values e.g. latency?

The testutil package is really more meant for end-to-end testing exporters and such, where you want to mirror an external metric source and therefore know exactly the input and expected output. If you want to test if your code was instrumented properly, I would rather go with a mock registry or

[prometheus-developers] Temperature histograms (was: Allow Kelvin as temperature unit in some cases)

On 28.05.20 21:59, Julien Pivotto wrote: > > Should we recommend kelvin instead of celcius in histograms and > summaries as there would not be negative observations ? > https://github.com/prometheus/prometheus/issues/6669 Technically correct answer: We should just fix histograms. Nerdy answer:

  1   2   >