[prometheus-developers] Thanos sidecar is not discovered in Thanos Querier by DNS servcie discovery

Thanos sidecar was not discovered by DNS service discovery in Thanos querier: I was using stable/prometheus-operator helm chart to deploy prometheus and Thanos Sidecar. below is my config in Thanos querier deployment file for discovering all thanos sidecars… But I don’t see any reporting..

[prometheus-developers] Prometheus alert tracking

Hi all, We have seen an alert getting triggered couple of days ago and it got resolved after 5 seconds. After checking container logs & grafana screenshots, no evidence was seen in support of the alert which was created and resolved. System does not show any symptom relevant to the

Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?

On 27.05.20 16:13, Richard Hartmann wrote: > On Wed, May 27, 2020 at 12:54 AM Bjoern Rabenstein wrote: > > > - The changes as suggested in > > > > https://github.com/prometheus/docs/commit/f7ee6ac5a9b841be6be25d92e2c403de15949491 > > are _not_ following the spirit of RFC7282. > > I

Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?

On Wed, May 27, 2020 at 8:35 AM Stuart Clark wrote: > In a lot of organisations with chair based systems which work well the > opposite is often true. > > The chair is there to facilitate the debate and therefore doesn't > express their own opinion. As a result, if the judgement call has to be >

Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?

On Wed, May 27, 2020 at 12:54 AM Bjoern Rabenstein wrote: > - The changes as suggested in > > https://github.com/prometheus/docs/commit/f7ee6ac5a9b841be6be25d92e2c403de15949491 > are _not_ following the spirit of RFC7282. I disagree with the above, and with the longer-form text not quoted,

Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?

On Tue, May 26, 2020 at 11:08 PM Julius Volz wrote: > Even if there's already an outspoken (relative) majority against that > minority? How would that be rough consensus then? If 100 people wanted to support traces natively in Prometheus, it would not need much of discussion to dismiss them.

Re: [prometheus-developers] move https/ package to client_golang

On 27 May 08:05, Brian Brazil wrote: > On Wed, 27 May 2020 at 07:52, Stuart Clark wrote: > > > On 27/05/2020 07:50, Brian Brazil wrote: > > > > On Wed, 27 May 2020 at 07:05, Ben Kochie wrote: > > > >> I was thinking about building an "exporter kit" repo that would include > >> some helpful

Re: [prometheus-developers] move https/ package to client_golang

On Wed, 27 May 2020 at 07:52, Stuart Clark wrote: > On 27/05/2020 07:50, Brian Brazil wrote: > > On Wed, 27 May 2020 at 07:05, Ben Kochie wrote: > >> I was thinking about building an "exporter kit" repo that would include >> some helpful functions to reduce the amount of boilerplate needed to

Re: [prometheus-developers] move https/ package to client_golang

On 27/05/2020 07:50, Brian Brazil wrote: On Wed, 27 May 2020 at 07:05, Ben Kochie > wrote: I was thinking about building an "exporter kit" repo that would include some helpful functions to reduce the amount of boilerplate needed to write exporters. I've

Re: [prometheus-developers] move https/ package to client_golang

On Wed, 27 May 2020 at 07:05, Ben Kochie wrote: > I was thinking about building an "exporter kit" repo that would include > some helpful functions to reduce the amount of boilerplate needed to write > exporters. > I've thought such a thing would be useful for a long time, though my presumption

Re: [prometheus-developers] move https/ package to client_golang

Like github.com/prometheus/toolkit/tls Yes that would be an option. As an independent piece of code it could still have its own tags and go.mod, to allow smooth updates. As it does not produce binaries that should be easy. Le mer. 27 mai 2020 à 08:05, Ben Kochie a écrit : > I was

Re: [prometheus-developers] Changing Prometheus from lazy to rough consensus?

On 27/05/2020 00:51, Bjoern Rabenstein wrote: Yes that joins what I said just before. However it might be difficult to give one person so much "power". At least the "parliament" (i.e. prometheus-team) could just elect another chair if the current one goes wild. In a lot of organisations

Re: [prometheus-developers] move https/ package to client_golang

I was thinking about building an "exporter kit" repo that would include some helpful functions to reduce the amount of boilerplate needed to write exporters. Perhaps we could star this project, have the https code moved there? github.com/prometheus/exporter/https On Wed, May 27, 2020 at 12:00