[prometheus-developers] Optimizing Histogram Buckets Format

[Bashar Al Rawi]

Hi all,

I would like to propose a new format for storing bucket counts that can 
provide substantial improvements for sparse/bi-modal metrics along with 
changes to histogram_quantile that allow the new format. Both the change 
and format aren't complex and can be done with backward compatibility. The 
main breaking change would be adding a new reserved label.

I put together my thoughts in this Google doc 

 that 
is open for comments and a rough implementation in this commit 

.

Please, take a look and let me know what your thoughts are.

Bashar

-- 
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/b3cd52af-3e60-4385-8a0d-b914559ab0b0n%40googlegroups.com.

Re: [prometheus-developers] PromQL formatting/prettifying support in promtool

[Tobias Schmidt]

Thanks a lot for your great work! Expression formatting will likely require
dozens of detailed rules in order to get things consistent, and style
discussions are the perfect case for bikeshedding. I really appreciate your
efforts and can't wait for a `promtool fmt` on-save editor integration. The
proverb of Go has arguably held true: Gofmt's style is no one's favorite,
yet gofmt is everyone's favorite
.

I hope we can get it right without having to make (large) changes in later
releases. The most annoying thing with auto-formatters is changing rules
with every release creating constant diff noise (looking at you rubocop).



On Fri, Jun 19, 2020 at 3:19 PM Harkishen Singh 
wrote:

> Hello everyone!
>
> As part of the GSoC 2020, I am working on designing a Promql expression
> formatting/prettifying tool whose support will be as an extension in the
> current promtool. A design document related to the same has been made and
> it would be great for some comments/views/suggestions, etc.
>
> Here is the link to the document: PromQL prettier
> 
>
> --
> 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/0e1b1867-b818-4afe-a970-1bbc21046844o%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/CAChBsdDHBjphxKUc_%3D7bcKuPoorGPxiy5duYqzvXM%2B3jNoNC%3Dw%40mail.gmail.com.

Re: [prometheus-developers] Re: Helm charts home

[Augustin Husson]

Hello,

Well having a single repo for each chart would create so much repositories
and IMHO just imagine to create for each of them the CI/CD even if it's the
same each time, is to exausting. ( Yeah I'm a bit lazy)

Moreover if you have to change one CI/CD for whatever reason you will have
to change it in all of them to keep the same.

Then it's quite fine to have a single repo of all helm-charts. We can even
imagine to create a bit clever scrip that will only run the test for the
charts that changed. That's not super rocket science I think.

And perhaps it makes sense actually to split the helm-charts into 2 repo.
One could go to prometheus and will have the helm chart owned by
prometheus. Then another one that will go to prometheus-community that will
contain the others (like the jira-alerts).

This split is just to provide to the helm chart of
prometheus/alertManager/node-exporter a better visibility and a sort of tag
"official helm chart of prometheus"

Kinds regards

Le ven. 19 juin 2020 à 20:14, Mingchin Hsieh  a écrit :

> Hi André,
>
> I would take back what I said. I originally intended to not mess-up repos
> under prometheus-community and might think too much on current CI e2e
> testing stucking issues.
>
> Best,
> Mingchin
>
> On Sat, Jun 20, 2020 at 1:50 AM André Bauer  wrote:
>
>> Why would you want to add "helm-chart" in the name of the chart and have
>> multiple repos?
>>
>> Imho it would be:
>>
>> helm-charts/prometheus
>> helm-charts/alertmanager
>> helm-charts/...
>>
>> and so on. So being "helm-charts" the repos main directory and the charts
>> inside of it.
>> Adding "helm-chart" to the name would also waste chars in helms limited
>> release name lenght.
>>
>> Maintenance of single repos for every chart would also be total overkill.
>> Imagine alone changes in the CI would be done multiple times.
>>
>>
>>
>> zanh...@gmail.com schrieb am Freitag, 19. Juni 2020 um 16:36:05 UTC+2:
>>
>>> Hi Stuart,
>>>
>>> No. My ideal expectation would be different repos, unless cost and / or
>>> maintenance is too high.
>>>
>>> Best,
>>> Mingchin
>>>
>>> On Fri, Jun 19, 2020 at 10:26 PM Stuart Clark 
>>> wrote:
>>>
 On 2020-06-19 15:09, Mingchin Hsieh wrote:
 > Hi,
 >
 > I sort of agree with Stuart's idea; only a little tweak: adding
 > helm-chart as prefix or suffix. For example,
 >
 > Prefix approach -
 > helm-chart-prometheus-adapter
 > helm-chart-prometheus-blackbox-exporter
 > helm-chart-prometheus-cloudwatch-exporter
 > helm-chart-prometheus-consul-exporter
 > helm-chart-prometheus-couchdb-exporter
 > helm-chart-prometheus-mongodb-exporter
 > helm-chart-prometheus-mysql-exporter
 > helm-chart-prometheus-nats-exporter
 > helm-chart-prometheus-node-exporter
 > helm-chart-prometheus-operator
 > helm-chart-prometheus-postgres-exporter
 > helm-chart-prometheus-pushgateway
 > helm-chart-prometheus-rabbitmq-exporter
 > helm-chart-prometheus-redis-exporter
 > helm-chart-prometheus-snmp-exporter
 > helm-chart-prometheus-to-sd
 > helm-chart-prometheus
 >
 > Suffix approach -
 > prometheus-adapter-helm-chart
 > prometheus-blackbox-exporter-helm-chart
 > prometheus-cloudwatch-exporter-helm-chart
 > prometheus-consul-exporter-helm-chart
 > prometheus-couchdb-exporter-helm-chart
 > prometheus-mongodb-exporter-helm-chart
 > prometheus-mysql-exporter-helm-chart
 > prometheus-nats-exporter-helm-chart
 > prometheus-node-exporter-helm-chart
 > prometheus-operator-helm-chart
 > prometheus-postgres-exporter-helm-chart
 > prometheus-pushgateway-helm-chart
 > prometheus-rabbitmq-exporter-helm-chart
 > prometheus-redis-exporter-helm-chart
 > prometheus-snmp-exporter-helm-chart
 > prometheus-to-sd-helm-chart
 > prometheus-helm-chart
 >
 > This is due to there are some existing repos in prometheus-community
 > that focus on each component implementation level (e.g. docker image
 > or stand-alone service). Mixing together might be harder to put on
 > hub.helm.sh [1]. But, the owners of prometheus-community hold their
 > right for the final decision.
 >
 > BTW, would any prometheus-community owners / members explain the
 > current testing infrastructure? Currently helm chart testing infra is
 > based on Google Bazel + CircleCI. There's some limitation over there,
 > e.g. the chart owners / approvers debug the testing infra is hard. I
 > think all the current prometheus related helm chart owners would like
 > to know how hard would be for migration / automation.
 >
 > Best,
 > Mingchin
 >
 > On Fri, Jun 19, 2020 at 8:55