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

I think we should allow dot (.) in names without quoting. It gives up a possible operator, but makes the syntax nicer for the vast majority of people who need a change. BryanOn 24 May 2024, at 10:00, Julius Volz wrote:Hi,While others are figuring out how to add UTF-8 support and other OTel compat

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

> 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. Just to note that Prometheus is coded to send just one sample per series in a remote-write message. In normal usage we want to send

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

of the code. > > Note: I took the liberty to use 10 labels for both tests > <https://github.com/prometheus/prometheus/commit/7080c6ac8cc4175d79a1fd047cb17f0976f57130> > . > > On Wednesday, February 14, 2024 at 10:18:30 AM UTC+1 Bryan Boreham wrote: > >> No need to apologis

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

No need to apologise! Do you have benchmarks using the Prometheus remote-read and remote-write protobufs ? On Wednesday 14 February 2024 at 08:08:37 UTC mircod...@gmail.com wrote: > Hi all, sorry to disrupt this discussion. > > Before stumbling upon this thread, I had worked on a separate fork

[prometheus-developers] Re: Accessing target servers in prometheus showing Down state

The reason they are showing Down is given on the right, in the text ending "... connection refused". Since the IP address is 127.0.0.1 (specified as "localhost") I can guess this relates to the processes running in different containers, which each have their own network namespace. Either run th

Re: [prometheus-developers] Protobuf support

> - why not moving to the official generated code? It seems it's the only stable one on the long term At least because nobody has put the work in to do the conversion and demonstrate it is no worse than today. I don't like the extra fields in generated structs, but I didn't measure the impact.

[prometheus-developers] Re: [Feature/Proposal][go]: instrument http client connection metrics

Hello, thanks for your interest in the Prometheus project. Your issue did not get any engagement, so I guess not many people want this feature. If you implement it, you could describe how it benefited you, then maybe more people would want it too. Bryan On Monday, 2 October 2023 at 08:38:50 UT

[prometheus-developers] Re: Proposal: refactoring rules seriesInPreviousEval

Are you building with -tags stringlabels? This tends to reduce memory used by Labels. Also I hope to reduce memory much more, though work stalled for a bit. (PR ) Since Prometheus has to store all the output series in the head, I wouldn't ta

[prometheus-developers] Re: Exemplars & histogram buckets

> does it de-dup the exemplars Yes, an exemplar that is a duplicate of one in memory is discarded. > so it doesn't ingest the older exemplars for some buckets, again, for every scrape Prometheus reads the values on every scrape. I don’t know how it could de-dup without reading them. Did yo

Re: [prometheus-developers] Potential big performance gain in common/expfmt/TextParser

For completeness, the parsers that Prometheus uses for scraping live here: https://github.com/prometheus/prometheus/tree/main/model/textparse Labels are cached by the scraper, so parsing is only done once for the lifetime of each target. This means that Prometheus is not too sensitive to the perf

[prometheus-developers] Re: Correlation between memory used and timeseries

You may be interested in this talk I gave at PromCon recently, showing some detail around where the memory is used: https://youtu.be/vc5LgoiP_CA Bryan On Friday, 25 November 2022 at 12:13:10 UTC l.mi...@gmail.com wrote: > This: > go_memstats_alloc_bytes / prometheus_tsdb_head_series > > gives y

[prometheus-developers] Re: Should labels.Labels.Hash() be consistent?

ng() calls Labels.Hash(). I could not find where this was used. I created https://github.com/prometheus/prometheus/pull/11635 to add a comment warning it may change. Bryan On Wednesday, 9 November 2022 at 15:11:15 UTC Bryan Boreham wrote: > As part of #10991 I took advantage of the new data

Re: [prometheus-developers] rbac support for exporter-toolkit

I see that kube-rbac-proxy both authenticates the caller and performs an authorization request to check whether that caller is allowed. Given divided opinions, how about a separate library which implements the feature, and a hook in prometheus/exporter-toolkit so that any similar library can be

Re: [prometheus-developers] rbac support for exporter-toolkit

What is meant by "add rbac support to the exporter-toolkit " ? I have been using Kubernetes and Prometheus for many years; I know what RBAC is but cannot immediately see how an exporter would want to write code that references it. Bryan On Frida

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

Would I be right in thinking this is the code which tripped you up? https://github.com/prometheus/prometheus/blob/c2b4de3611a6/model/textparse/openmetricsparse.go#L472-L479 This is insisting that exemplars only work on metrics ending in "_bucket" or "_total". Personally I would be fine with relax

[prometheus-developers] Should labels.Labels.Hash() be consistent?

As part of #10991 I took advantage of the new data structure to make Hash() run a lot faster; however the new version gives different answers to the old version. From my reading of the Prometheus code, this is OK because hash values are never persisted. Later, I became aware that query-sharding

Re: [prometheus-developers] Protect main branch on client_java

for Prometheus projects to have a > protected main branch I'm happy to do that. However, it won't change much > as long as I'm the only active maintainer. > > On Fri, Nov 4, 2022 at 7:22 PM Bryan Boreham wrote: > >> Hi, when I visited https://github.com/prometheus/clien

[prometheus-developers] Protect main branch on client_java

Hi, when I visited https://github.com/prometheus/client_java today, GitHub warned me that the main branch is not protected against force-push or deletion. It seems that client_golang is protected (and requires CI to pass for merge); do we want to turn on protection for client_java? Bryan --

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

>>> Also, what do you think about supporting _count in Histograms (since Histogram extends Summary with buckets)? >> How exactly would you change this while remaining backwards-compatible for existing users? > As far as I can see, adding Exemplars to _count should be a backward-compatible change

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

> >> On Saturday, October 8, 2022 at 5:36:27 AM UTC-7 fab...@fstab.de wrote: >> >>> > Example: Counts are often used for error rates like this: >>> >>> sum(rate(http_server_duration_count{http_status_code=~"5.."}[5m])) / >>> sum(rate(http_server_duration_count[5m])) >>> >>> Small hack: http_s

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

lick on an example >> of an HTTP 500 error and navigate directly to the corresponding trace, or >> to the logs filtered by trace ID. >> >> Fabian >> >> >> On Sat, Oct 8, 2022 at 2:28 PM Bryan Boreham wrote: >> >>> I suspect the answer is tha

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

I suspect the answer is that the OpenMetrics spec does not mention exemplars on Summaries. https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#summary I don't see any technical obstacle to attaching them in https://github.com/prometheus/client_golang. Inside P

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

. Bryan On Sunday, 19 June 2022 at 17:32:16 UTC+1 Bryan Boreham wrote: > https://github.com/prometheus/prometheus/pull/10887 > > On Wednesday, 25 May 2022 at 16:40:41 UTC+1 bjo...@rabenste.in wrote: > >> On 12.05.22 17:07, Bryan Boreham wrote: >> > >> > I

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

https://github.com/prometheus/prometheus/pull/10887 On Wednesday, 25 May 2022 at 16:40:41 UTC+1 bjo...@rabenste.in wrote: > 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

Re: [prometheus-developers] Change the implementation of labels.Builder in Prometheus

/10662, but since it adds a hundred lines of code with no explanation, may I suggest that you add such explanation in comments or commit messages and then I can look again. Bryan Boreham On Thursday, 12 May 2022 at 04:56:43 UTC-7 husson@gmail.com wrote: > Hi Brian, > > Thanks for y

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

to replace those with an abstraction: all tests pass, and benchmarks go broadly at the same speed. If there is interest I will make a PR containing just the above change, no change to the structure labels.Labels itself as yet. Regards, Bryan Boreham -- You received this message because you are subscr