Re: [prometheus-developers] Would tooling for PromQL formatting/manipulation be useful and where should it live?

[Frederic Branczyk]

I’m not sure your use cases match, but I’ve always wanted something like
prepared statements where something like a “?” operator could be an
expression placeholder, possibly even restricted to something like a label
matcher, or just a label-value, etc.

I think there might be overlap in the use cases but if not then sorry for
the noise.

On Wed 5. Oct 2022 at 18:45, Matthias Rampke  wrote:

> Re: drawing the line – I often feel like "specialized" tools that try to
> solve all advanced use cases end up with very complex and hard to use
> configuration (looking at you, relabeling). I often find it more pleasant
> to express what I want to do as *code*. What would an API look like that
> you or others could use to build their own tools for their specific needs,
> without making it part of any particular CLI?
>
> In general, is there a mock-up or reference of the interface you propose?
>
> /MR
>
> On Wed, Oct 5, 2022 at 4:06 PM r...@chronosphere.io 
> wrote:
>
>> Yes I realized that to manipulate the AST (and the AST will of course
>> change as new functions and features are added) much like codemirror-promql
>> moved into the Prometheus repository to get updates as they come to PromQL
>> that somewhere in the Prometheus repo itself would be a good starting point.
>>
>> How would you all feel of adding the commands under a "--experimental"
>> flag as David suggested? I'd be happy to make the "--experimental" flag
>> addition too David if you like, also happy to wait too until that's
>> available if that's preferential.
>>
>>
>> On Wednesday, October 5, 2022 at 5:55:58 AM UTC-4 Julius Volz wrote:
>>
>>> The versioning aspect is a good point, I hadn't thought of that.
>>>
>>> If we make promtool's scope broader than what I proposed, it's IMO still
>>> a question of where we draw the line in terms of niche specialized use
>>> cases. The proposes features in
>>> https://github.com/prometheus/prometheus/pull/11411 are kind of
>>> borderline to me in that regard, but I also wouldn't be unhappy if they
>>> went into promtool.
>>>
>>> On Wed, Oct 5, 2022 at 11:25 AM Julien Pivotto 
>>> wrote:
>>>
 I think the opposite - Prometheus contains PromQL, it's same codebase,
 same version. It makes sense to have those tools in promtool as well, so
 it is shipped to everyone, and has a known version.

 On 05 Oct 11:22, Julius Volz wrote:
 > I do feel that formatting entire rule files would be in scope for
 promtool,
 > but more specialized formatting and manipulations of individual PromQL
 > queries (while cool) should likely live in a separate tool. I see the
 scope
 > of promtool to be mostly a tool to interact with both the Prometheus
 > server, its immediately configuration files, and its TSDB directory.
 >
 > On Wed, Oct 5, 2022 at 11:13 AM David Leadbeater  wrote:
 >
 > > Hi Rob,
 > >
 > > I wonder if PromQL related things fit in promtool given the use for
 > > PromQL is wider than just Prometheus. I can imagine something like a
 > > "promqltool", which might actually be backed by the promql language
 > > server (so people can get similar things in editors too).
 > >
 > > However that's clearly a larger discussion, I don't see an issue
 with
 > > adding some promql subcommands to promtool for now, particularly as
 > > the formatting one exercises the code in Prometheus and is useful
 for
 > > developers anyway.
 > >
 > > I do think it's important to get the interface right, while we don't
 > > guarantee complete stability in promtool, it is difficult to change
 > > without breaking people. To that end I'm thinking of adding a top
 > > level "--experimental" flag in promtool, which can then enable the
 > > promql subcommands. (We do have feature flags in promtool, but that
 > > feels wrong here, as feature flags are currently shared with
 > > prometheus.)
 > >
 > > David
 > >
 > > On Wed, 5 Oct 2022 at 07:58, Rob Skillington 
 wrote:
 > > >
 > > > Hey Prometheus team,
 > > >
 > > > Have noticed asks for tooling around reformatting/manipulating and
 > > generally refactoring sets of queries and rule definitions (where
 there is
 > > a high number of defined queries). Use cases include such cases as
 "I want
 > > to duplicate a set of alerts to target different environments with
 > > different label combinations and also conditions".
 > > >
 > > > I opened a PR to add some basic commands given I had seen this
 earlier
 > > PR mention that there was intention for the PromQL AST pretty print
 > > formatting to be useable from promtool:
 > > > https://github.com/prometheus/prometheus/pull/10544
 > > >
 > > > I now realize it may have been better perhaps to raise the
 question of
 > > if/where it should live here before opening the PR. What would be
 the
 > > reception of housing 

Re: [prometheus-developers] Re: Welcoming Josh Abreu to the Prometheus Team

[Frederic Branczyk]

Welcome!

On Fri 24. Jun 2022 at 18:20, 'Josh Abreu Mesa' via Prometheus Developers <
prometheus-developers@googlegroups.com> wrote:

> Thank you, Julien! It's an honour to be part of this team.
>
> On Thursday, June 23, 2022 at 8:46:25 PM UTC+1 Julien Pivotto wrote:
>
>> Dear community,
>>
>> The Prometheus team welcomes Josh Abreu as new team member.
>>
>> Josh (@gotjosh) has been doing a great job in the alertmanager repository
>> in the
>> last months, and plans to continue working on it in the future.
>>
>> Welcome Josh!
>>
>> --
>> 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/dd909d30-2d82-480d-8bea-23b91b9ec699n%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/CAOs1Umw1gUdtJG%3DHtPmhyL%2BS_L7NgXavOsDdb8tmSqTBUfyhFw%40mail.gmail.com.

Re: [prometheus-developers] Move from CircleCI to GitHub action

[Frederic Branczyk]

If we're already doing this (and this is not the first or last time we've
moved CI systems) I do think there is value in thinking about abstracting
our CI so another move would be easy and not require us to rewrite
everything. Don't get me wrong, I'm very happy with GitHub Actions but
there's always "the next thing" (TM). If we're already doing this, I would
suggest having a look at Dagger (https://dagger.io/) to actually write the
pipelines and "just" run them on GitHub Actions.

Just my two cents, as always in the Prometheus project I think whoever does
the work can have the freedom to decide, but this would be my suggestion.

On Thu, 16 Jun 2022 at 13:13, Bartłomiej Płotka  wrote:

> Amazing! LGTM
>
> Kind Regards,
> Bartek Płotka (@bwplotka)
>
>
> On Thu, Jun 16, 2022 at 11:30 AM Julien Pivotto <
> roidelapl...@prometheus.io> wrote:
>
>> Yes, the plan is to rewrite the orb as a reusable github action. There
>> would be a repo similar to the orb we are using.
>>
>>
>> On 16 Jun 11:28, Augustin Husson wrote:
>> > I guess a nice way to reuse the orb is to create a GithubAction that
>> > provides more or less the same features.
>> >
>> > Le jeu. 16 juin 2022 à 11:05, Bartłomiej Płotka  a
>> > écrit :
>> >
>> > > Hi,
>> > >
>> > > Thanks!
>> > >
>> > > What does that mean to reusable Orbs we maintain? Can we reuse some
>> of the
>> > > jobs in the same manner across repos?
>> > >
>> > > Kind Regards,
>> > > Bartek Płotka (@bwplotka)
>> > >
>> > >
>> > > On Thu, Jun 16, 2022 at 10:45 AM Julien Pivotto <
>> > > roidelapl...@prometheus.io> wrote:
>> > >
>> > >> Hello,
>> > >>
>> > >> Based on a request from CNCF, I'd like to move from CircleCI to
>> Github
>> > >> Action.
>> > >>
>> > >> We are already using GitHub actions today, for linting and fuzzing.
>> > >>
>> > >> Compared to what we are using in CircleCI, it looks like GitHub
>> action
>> > >> runners are comparable in size, with slightly more ram.
>> > >>
>> > >> Pros' of the move:
>> > >> - Remove a CI system
>> > >> - Better integration with Github (access to logs, etc)
>> > >> - It seems better for CNCF itself
>> > >>
>> > >> Con's of the move:
>> > >> - Threading (e.g. parallel builds) will be a bit more itchy at the
>> > >>   moment but will be doable.
>> > >>
>> > >> I plan to do the work in the coming weeks, unless we don't have lazy
>> > >> consensus.
>> > >>
>> > >> 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/YqrtnRGCHWT5f1w1%40nixos
>> > >> .
>> > >>
>> > > --
>> > > 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/CAMssQwZUHemRqsAjwCM%2B6-iL28TrgyrPYbMKM9MPHEMt5jNfrw%40mail.gmail.com
>> > > <
>> https://groups.google.com/d/msgid/prometheus-developers/CAMssQwZUHemRqsAjwCM%2B6-iL28TrgyrPYbMKM9MPHEMt5jNfrw%40mail.gmail.com?utm_medium=email&utm_source=footer
>> >
>> > > .
>> > >
>> >
>> > --
>> > 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/CAOJizGdpoUuJ%3Dbws2oXcBtsLN%2BtjrB3JWDdrXJP98FMFQafZXA%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/CAMssQwbP0S02dQqVZ3b6iuco4szGP%2B%3DR5gOUcr%2BEkHjHRsOwnQ%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/promethe

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

[Frederic Branczyk]

I think I'd be most useful to rebase, and create a PR from this, then we
can see whether tests pass and we can run prombench (although I don't think
there are any perf tests that involve the proto parts). Then we can discuss
on there and figure out where to take this.

Thank you so much for the work you have already put into this!

On Mon, 21 Jun 2021 at 19:53, Austin Cawley-Edwards 
wrote:

> I've updated my branch (
> https://github.com/austince/prometheus/tree/feat/drop-gogo) to use both
> the vitess plugin and the buf tool, which indeed fit very nicely together.
>
> I've only updated the code enough for it to compile, have not investigated
> the semantic differences. This is likely the furthest I'll be able to take
> this for a bit, so feedback and playing around are welcome and appreciated
> if this is where we'd like protobuf in Prometheus to go :)
>
> Best,
> Austin
>
> On Thu, Jun 17, 2021 at 12:56 PM Frederic Branczyk 
> wrote:
>
>> I have heard great thing, but haven’t used it. Wrongfully thought that
>> they are mutually exclusive but turns out they are actually complementary:
>> https://twitter.com/fredbrancz/status/1405192828049838080?s=21
>>
>> We should probably do an investigation of the combination.
>>
>> On Thu 17. Jun 2021 at 18:26, Austin Cawley-Edwards <
>> austin.caw...@gmail.com> wrote:
>>
>>> Just saw this on the CNCF blog as well, seems like a promising library.
>>>
>>> Tangentially, have you heard of https://github.com/bufbuild/buf? It
>>> seems much nicer than compiling with shell scripts and protoc.
>>>
>>>
>>>

-- 
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/CAOs1UmyzDvuVoFEET3w1Syp9OrKnhG2HO%2BiD%3DhifvgjhMS25eQ%40mail.gmail.com.

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

[Frederic Branczyk]

I have heard great thing, but haven’t used it. Wrongfully thought that they
are mutually exclusive but turns out they are actually complementary:
https://twitter.com/fredbrancz/status/1405192828049838080?s=21

We should probably do an investigation of the combination.

On Thu 17. Jun 2021 at 18:26, Austin Cawley-Edwards 
wrote:

> Just saw this on the CNCF blog as well, seems like a promising library.
>
> Tangentially, have you heard of https://github.com/bufbuild/buf? It seems
> much nicer than compiling with shell scripts and protoc.
>
>
>

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

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

[Frederic Branczyk]

nds awesome - but I can't find any
>>>> more information about it.  Does v1.4.0 generate code for the serialisation
>>>> / deserialisation function or still rely on Golang reflection?  Does it
>>>> allow for the neat tricks to get rid of pointers and all the allocations?
>>>> Anything I can read about this would be super useful.
>>>>
>>>> > Off the top of my head, I would think checking in with the Cortex and
>>>> Thanos projects is probably a good idea, I know both have a good amount of
>>>> optimizations optimizing allocations, so it would be good to check that
>>>> these would still be possible.
>>>>
>>>> From a Cortex PoV, we have copies of these protos so I don't think this
>>>> would be too much of a problem, but I'd defer to people who know better
>>>> than me.
>>>>
>>>> Cheers
>>>>
>>>> Tom
>>>>
>>>> On Wed, Apr 28, 2021 at 10:07 AM Frederic Branczyk 
>>>> wrote:
>>>>
>>>>> I'd be very happy with this. One consideration that we should take
>>>>> (certainly not blocking this but should keep in mind) is how this would
>>>>> affect immediate downstream users. Off the top of my head, I would think
>>>>> checking in with the Cortex and Thanos projects is probably a good idea, I
>>>>> know both have a good amount of optimizations optimizing allocations, so 
>>>>> it
>>>>> would be good to check that these would still be possible.
>>>>>
>>>>> On Tue, 27 Apr 2021 at 22:51, Austin Cawley-Edwards <
>>>>> austin.caw...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> The protobuf library used in Prometheus, gogo/protobuf
>>>>>> <https://github.com/gogo/protobuf>, is no longer actively maintained
>>>>>> (activity largely stopped pre-2020, looking for new ownership
>>>>>> <https://github.com/gogo/protobuf/issues/691>). Along with that,
>>>>>> many of the performance boosts that are provided by gogo have been
>>>>>> addressed in the official Go lib, golang/protobuf
>>>>>> <https://github.com/golang/protobuf>, as of v1.4.0
>>>>>> <https://blog.golang.org/protobuf-apiv2>.
>>>>>>
>>>>>> Many projects that used gogo/protobuf have since switched to the
>>>>>> official lib (ex: Istio <https://github.com/istio/istio/pull/17132>,
>>>>>> Envoyproxy
>>>>>> <https://github.com/envoyproxy/go-control-plane/issues/213>),
>>>>>> largely for eco-system compatibility reasons now that performance is not 
>>>>>> a
>>>>>> factor. The gogo-compiled protobufs are not compatible with any
>>>>>> golang-compiled protobufs, and vice-versa. This makes consuming external
>>>>>> protobuf APIs impossible unless they also maintain a gogo version, which 
>>>>>> is
>>>>>> not common.
>>>>>>
>>>>>> I'm wondering if anyone has done work in this area recently, and if
>>>>>> the community agrees it's a net benefit switching to the official
>>>>>> golang/protobuf implementation.
>>>>>>
>>>>>> *What this would mean for Prometheus*
>>>>>>
>>>>>> Looking at the history of protobuf in Prometheus, it seems like both
>>>>>> golang/protobuf and gogo/protobuf were until the end of 2017, when it 
>>>>>> then
>>>>>> made sense to consolidate onto gogo (#3346
>>>>>> <https://github.com/prometheus/prometheus/issues/3346>) (#3394
>>>>>> <https://github.com/prometheus/prometheus/pull/3394>).
>>>>>>
>>>>>> As noted in the above issues, the official golang/protobuf package is
>>>>>> still present in vendored files, so it is just the Prometheus protos that
>>>>>> would need to be updated. The build procedures (mainly
>>>>>> scripts/genproto.sh
>>>>>> <https://github.com/prometheus/prometheus/blob/75e505babb9bbcefd8849e945814d35c7ce97e9f/scripts/genproto.sh>)
>>>>>> have not changed much since the 2017 shift, so the work would be mainly
>>>>>> adjusting this back to use golang/protobuf and recompiling the `prompb`
>>>>>> package.
>>>>>>
>>>>>> Does anyone know of other necessary changes/ complications that I'm
>>>>>> missing?
>>>>>>
>>>>>> Thanks all for your time,
>>>>>> Austin
>>>>>>
>>>>>> --
>>>>>> 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/38caa51d-e88a-489b-a045-54144cd1a03fn%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/prometheus-developers/38caa51d-e88a-489b-a045-54144cd1a03fn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>>> 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/CAOs1Umy%2BhjN10r9q_MOwZ2wHL-0MEDZWw_2SCUPW%2B%3D8xpKvdQw%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/prometheus-developers/CAOs1Umy%2BhjN10r9q_MOwZ2wHL-0MEDZWw_2SCUPW%2B%3D8xpKvdQw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>

-- 
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/CAOs1Umwjo3KdK1%3DCKvQev%2BO-wyV%3Def9K6wWK6smEtewGS1nRNw%40mail.gmail.com.

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

[Frederic Branczyk]

I'd be very happy with this. One consideration that we should take
(certainly not blocking this but should keep in mind) is how this would
affect immediate downstream users. Off the top of my head, I would think
checking in with the Cortex and Thanos projects is probably a good idea, I
know both have a good amount of optimizations optimizing allocations, so it
would be good to check that these would still be possible.

On Tue, 27 Apr 2021 at 22:51, Austin Cawley-Edwards 
wrote:

>
> Hi all,
>
> The protobuf library used in Prometheus, gogo/protobuf
> , is no longer actively maintained
> (activity largely stopped pre-2020, looking for new ownership
> ). Along with that, many of
> the performance boosts that are provided by gogo have been addressed in the
> official Go lib, golang/protobuf , as
> of v1.4.0 .
>
> Many projects that used gogo/protobuf have since switched to the official
> lib (ex: Istio , Envoyproxy
> ), largely for
> eco-system compatibility reasons now that performance is not a factor. The
> gogo-compiled protobufs are not compatible with any golang-compiled
> protobufs, and vice-versa. This makes consuming external protobuf APIs
> impossible unless they also maintain a gogo version, which is not common.
>
> I'm wondering if anyone has done work in this area recently, and if the
> community agrees it's a net benefit switching to the official
> golang/protobuf implementation.
>
> *What this would mean for Prometheus*
>
> Looking at the history of protobuf in Prometheus, it seems like both
> golang/protobuf and gogo/protobuf were until the end of 2017, when it then
> made sense to consolidate onto gogo (#3346
> ) (#3394
> ).
>
> As noted in the above issues, the official golang/protobuf package is
> still present in vendored files, so it is just the Prometheus protos that
> would need to be updated. The build procedures (mainly scripts/genproto.sh
> )
> have not changed much since the 2017 shift, so the work would be mainly
> adjusting this back to use golang/protobuf and recompiling the `prompb`
> package.
>
> Does anyone know of other necessary changes/ complications that I'm
> missing?
>
> Thanks all for your time,
> Austin
>
> --
> 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/38caa51d-e88a-489b-a045-54144cd1a03fn%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/CAOs1Umy%2BhjN10r9q_MOwZ2wHL-0MEDZWw_2SCUPW%2B%3D8xpKvdQw%40mail.gmail.com.

Re: [prometheus-developers] Standard path for mixins

[Frederic Branczyk]

In newer versions of jsonnet-bundler this is not strictly necessary
anymore, the module name has been only a “legacy” import option for the
last year (I just checked the version allowing it went out almost to the
day exactly a year ago). If there are conflicts the absolute (go import
style) full module name must be specified, which might be nice way to move
the ecosystem forward anyways.

I don’t think this should stop us from doing this, I don’t feel strongly
one way or the other about the directory structure itself though I agree we
could be more consistent.

On Wed 3. Mar 2021 at 15:59, Tom Wilkie  wrote:

> @Frederic Branczyk  should weigh in on this, but I
> believe the module name == the directory name in jsonnet bundler, so if we
> call them all monitoring-mixin then it will make it tricky to import
> multiple ones into the same project.  So with that in mind I like
> "-mixin".
>
> But we could be more consistent about root-of-repo vs docs vs
> documentation directories...
>
>
> Tom
>
> On Wed, Mar 3, 2021 at 2:47 PM Ben Kochie  wrote:
>
>> We currently have mixins spread out over various paths within each
>> repository. It would be nice if there was a standard path for this.
>>
>> What do people think of having all projects keep their mixins in
>> `/monitoring-mixin`?
>>
>> alertmanager/doc/alertmanager-mixin
>> mysqld_exporter/mysqld-mixin
>> node_exporter/docs/node-mixin
>> prometheus/documentation/prometheus-mixin
>>
>> --
>> 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/CABbyFmrhhG-%3DEQcb2zm%3Dkc2%3DuqX7nxHb2%3D6YG8cgTNec-fqdRQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/prometheus-developers/CABbyFmrhhG-%3DEQcb2zm%3Dkc2%3DuqX7nxHb2%3D6YG8cgTNec-fqdRQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

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

Re: [prometheus-developers] Adding a CODEOWNERS file to prometheus/prometheus?

[Frederic Branczyk]

Yeah, I was thinking the same as Julius said, but maybe it's fair to see
who wants to opt-in to this and who doesn't.

FWIW I added myself as codeowner of the Kubernetes service discovery just
like it's mentioned in the maintainers file.

https://github.com/prometheus/prometheus/pull/8553

On Mon, 1 Mar 2021 at 21:18, Julius Volz  wrote:

> Great - I made a PR at https://github.com/prometheus/prometheus/pull/8552.
>
> I added /storage/remote, but at that point maybe we want to add all the
> other dirs with specific maintainers as well?
>
> On Mon, Mar 1, 2021 at 9:10 PM Tom Wilkie  wrote:
>
>> Yes! I was chatting to Beorn about this the other week...  Big +1 from
>> me.  Mind adding a line for /storage/remote too?
>>
>> Thanks
>>
>> Tom
>>
>> On Mon, Mar 1, 2021 at 8:05 PM Julius Volz  wrote:
>>
>>> Heya all,
>>>
>>> Julien often helpfully pings me on PRs that touch the React UI, but it
>>> would be much nicer if I could somehow get auto-notified by GitHub
>>> specifically of those that touch anything under /web/ui/. Others might feel
>>> the same about their areas of purview.
>>>
>>> GitHub has a CODEOWNERS file feature (
>>> https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners),
>>> which allows specifying owners for parts of a repo, which then get
>>> auto-assigned as reviewers for PRs touching those files.
>>>
>>> Is anyone opposed to me experimenting with a CODEOWNERS file that only
>>> has a rule about /web/ui for a start? So just a line like:
>>>
>>> # Assign any UI-related PRs to Julius.
>>> /web/ui @juliusv
>>>
>>> That would give me the notifications I want, as a side effect of
>>> auto-assigning me as a reviewer for UI PRs at the same time (which should
>>> be fine for that subdir as well). If that works well, others can start
>>> using the file as well.
>>>
>>> Regards,
>>> Julius
>>>
>>> --
>>> 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%2BT6Yozt9UCqty8cVXYsaa-KjMmqPcPi5iQwNAg9t_erByM%2B3Q%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%2BT6Yoz4GkHP6wJNPcW3JuAxq4%3D%3D7p4dp7cO3b853iYO43UPpw%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/CAOs1UmywWsDE7tKESJ_xmNhMeQbz7MGCDnF63DaKQai_Gk_e1Q%40mail.gmail.com.

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

[Frederic Branczyk]

I think all secrets must be readable from files.

On Thu 18. Feb 2021 at 15:49, Bjoern Rabenstein  wrote:

> 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
>
> https://kubernetes.io/docs/concepts/configuration/secret/#overview-of-secrets
> for details.
>
> Good arguments have been made why secrets in environment variables are
> problematic. In the Prometheus ecosystem, we have mostly converged on
> using files in the scenario described here. That works just fine for
> the password of HTTP basic auth, the bearer token, TLS certificates,
> and probably more. However, there are a bunch of secrets in config
> files (in particular for Prometheus itself and for the Alertmanager)
> that _must_ be provided in the config file itself. (Search for
> `` in the documentation of a config file to find all secrets.)
> If you want to leverage the K8s secrets management for those, you have
> to jump through hoops, i.e. set up an init container that creates a
> config on the fly before starting the actual Prometheus or
> Alertmanager binary.
>
> My inner minister for consistency tells me we should either allow all
> secrets to be provided in a file or none. My inner minister for user
> experience tells me we can hardly make users jump through those hoops
> for the secrets where we currently allow files.
>
> So what do you think about generally providing a `xxx_file: `
> config
> option where we currently just allow `xxx: `? There are a lot
> of those, but maybe it's the way to go?
>
> --
> 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/20210218144952.GF2747%40jahnn
> .
>

-- 
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/CAOs1UmzrpXgFEbh-TG2N%3D%2B8d5teUqrrHp43hjScX9o%3DZdsaA4g%40mail.gmail.com.

Re: [prometheus-developers] OpenID Connect for remote write

[Frederic Branczyk]

OIDC specifies a couple of important things on top of oauth2. I would
welcome it if we implemented it OIDC compliant (since all OIDC is oauth2,
this shouldn't be a big deal for those that only care about oauth2).

I don't have time to implement this in the foreseeable future but I'm happy
to review designs, I've worked a number of times with OIDC in
similar scenarios. Specifically for OIDC for remote-write, we should
probably limit ourselves to a few reasonable OIDC-flows that actually make
sense for machine-to-machine authn/authz.

The use case I imagine is having short-lived tokens that are refreshed
relatively often. A common security practice.

On Thu, 28 Jan 2021 at 23:45, Julien Pivotto 
wrote:

>
> Dear -developers,
>
> Per the last dev summit, there is a consensus for having OpenID
> connect support for remote_write.
>
> My understanding and experience of the protocol is that we should
> actually aim at oauth2 support, and not openid connect.
>
> Implementation wise, it would mean sticking to
> https://pkg.go.dev/golang.org/x/oauth2
>
> Who has an actual use case and can confirm this?
>
> 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/20210128224526.GA1343460%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/CAOs1UmxC63zQP9SPorZPnKXd00SqgFkj44BZxfzPhRA6mPh1GQ%40mail.gmail.com.

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

[Frederic Branczyk]

I don’t like squash merging, don’t think I’ve ever used rebase merging but
don’t feel too strongly about it. Merge commit is my preference.

On Thu 3. Dec 2020 at 15:06, Julien Pivotto 
wrote:

> On 03 Dec 14:59, Bartłomiej Płotka wrote:
> > I am ok with this proposal.
> >
> > Long term I would even vote for squash only, but we discussed this in the
> > past.
>
> How would you merge release branches in master?
>
> >
> > Kind Regards,
> > Bartek Płotka (@bwplotka)
> >
> >
> > On Thu, 3 Dec 2020 at 14:20, Brian Brazil <
> brian.bra...@robustperception.io>
> > wrote:
> >
> > > On Thu, 3 Dec 2020 at 13: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 merge/squash and merge.
> > >>
> > >
> > > I use rebase merges sometimes to keep the history clean from
> > > unnecessary merge commits, so I'd like it to hang around.
> > >
> > > Brian
> > >
> > >
> > >>
> > >> [image: image.png]
> > >>
> > >> --
> > >> 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/CABbyFmp0X26pjfvyATvaUxH9p_nwBh0QSMgtJGNzfDLnZJjdMQ%40mail.gmail.com
> > >> <
> https://groups.google.com/d/msgid/prometheus-developers/CABbyFmp0X26pjfvyATvaUxH9p_nwBh0QSMgtJGNzfDLnZJjdMQ%40mail.gmail.com?utm_medium=email&utm_source=footer
> >
> > >> .
> > >>
> > >
> > >
> > > --
> > > 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/CAHJKeLpwuPY6iE0k7zRP8PFAGTrEx9hYzx6j%3DQT8p4hLQVF6-w%40mail.gmail.com
> > > <
> https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLpwuPY6iE0k7zRP8PFAGTrEx9hYzx6j%3DQT8p4hLQVF6-w%40mail.gmail.com?utm_medium=email&utm_source=footer
> >
> > > .
> > >
> >
> > --
> > 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/CAMssQwahWTP3uPQuEDcu8jQB_EBDe5AOKXrJYd6%2Bad-wqOpEFQ%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/20201203140641.GA543460%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/CAOs1Umx8Ug%2BaT3sr7VEw7ryngY4Fm7Fzzdp7z6QO6ODpWXa7mQ%40mail.gmail.com.

Re: [prometheus-developers] Alertmanager stdout notifier (or tweak some debug logs)

[Frederic Branczyk]

On debug log level, I don't see why we wouldn't add it to the stringer
method. I feel this is useful debugging context, so I'd be happy to have
this.

On Wed, 4 Nov 2020 at 17:20, 'Ed Welch' via Prometheus Developers <
prometheus-developers@googlegroups.com> wrote:

>
> Hey folks! Looking for some feedback on a potential solution for a problem
> I would like to solve:
>
> I would like to capture all the alerts being sent via alertmanager via the
> logger into my logging system so that I can do some analytics on alerts and
> frequency after the fact.
>
> Currently, the debug level logging in the dispatch.go for alerts will log
> the alert as it's processed [1]
>
> However the Stringer method for the Alert type only includes the alert
> name and the fingerprint of the labels [2]. I really need the printed
> labels for the log line to be useful for the purpose I'm seeking.
>
> I have 2 thoughts:
> - would the project be receptive to changing this Stringer method to also
> include the full label list?
> - as an alternative would something like a stdout notifier be considered
> for inclusion in the alertmanager?
>
> For the second case I'm thinking a very simple notifier which just prints
> the alert to stdout, perhaps with some basic options for controlling the
> format.
>
> Thoughts?
>
> Thanks,
> Ed
>
> [1]
> https://github.com/prometheus/alertmanager/blob/0c0c6bdb0133e399c1a9fe4c1a170ce49ec67b58/dispatch/dispatch.go#L138
> [2]
> https://github.com/prometheus/alertmanager/blob/f10e5cb703616584f9772966589e2060db5daf34/vendor/github.com/prometheus/common/model/alert.go#L55
>
> --
> 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/7332de62-bd64-4c5e-889e-69d8b4421d13n%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/CAOs1UmzHZf4%3DiK08YBvk9R23kbb_aguL1NzLy1yPSsO8SGRegQ%40mail.gmail.com.

Re: [prometheus-developers] Re: Proposal: Add SD implementation backed by a gRPC interface for custom providers

[Frederic Branczyk]

> If you have the Prometheus Operator, you have a my understanding is that
> you can make your "generic sd" by creating Probe CRD's (e.g. from within
> the kuma controllers). Did you consider that option too? If you are not
> in kube then you don't have shared mountpoints issues.

Just for clarification, Prometheus Operator Probes are only meant for
automating the setup and specialties around making blackbox probes more
accessible. They are not a general-purpose way to scrape targets.

On Sat, 10 Oct 2020 at 01:09, Julien Pivotto 
wrote:

> On 09 Oct 14:48, Austin Cawley-Edwards wrote:
> > Hey all,
> >
> > Trying to bring this thread back to life and give some updates since it
> > petered out.
> >
> > At Kuma[0], we've gone down the suggested `file_sd` route by building a
> > custom binary that runs in a Prometheus sidecar to do the polling and
> > writing of the sd file, which is then shared w/ Prometheus via volume
> > mounts[1]. This works very well once it is set up correctly, but has
> proven
> > difficult for many users to get up and running as it involves a good
> deal
> > of low-level, non-prometheus config. It's even more difficult if they
> are
> > not on the team managing Prometheus infra.
> >
> > For those reasons, implementing another generic SD would help purely
> with
> > adoption, as configuring a few lines of yaml is a dramatically lower
> > starting place compared to configuring a sidecar with shared volume
> mounts.
> > I understand and agree with the general hesitation here, especially when
> it
> > comes to defining entirely new "generic" SDs, and even the hesitation to
> > adopt a widely-used protocol like envoy's xDS, but with the primary goal
> of
> > increasing adoption, what do you all think about exposing a grpc_sd that
> > uses the same format as the file_sd? I'm sure much of the implementation
> > could be shared and it would remove the burden of setting up the network
> > hop and file sharing themselves.
> >
> > Lastly, in terms of continued support, we at Kuma are committed to our
> > Prometheus integration and are happy to contribute and maintain this SD
> > with the Promtheus community.
> >
> > Other related issues:
> > - #6484 [2], gRPC proposal
> > - #7919 [3], Kuma SD proposal
>
> As you might have seen, we are slowly getting new SD's into prometheus
> core. We had 4 new SD's in the last weeks.
>
> When the issue for Kuma arrived in te bug tracker, there were some
> leftover questions, like did you try the DNS-SD? Then the issue was
> directly closed.
>
> If you have the Prometheus Operator, you have a my understanding is that
> you can make your "generic sd" by creating Probe CRD's (e.g. from within
> the kuma controllers). Did you consider that option too? If you are not
> in kube then you don't have shared mountpoints issues.
>
> Should we have a generic SD, I would not like that much GRPC as would
> bring many dependencies, that we already had issues with. Additionally,
> we have more chances to use a more-established standard like HTTP (with
> long poll). Especially since the communications only need to be one-way.
>
> I also think that such SD's should be limited to what they do, and that
> it should be less flexible than the current file_sd. I think that any
> generic remote file_sd should have constraints, such as all the labels
> should be prefixes with __meta unless the __address__ label. We should
> try to enforce on those SD's the same rules we have kept for the SD's
> that are implemented now.
>
> >
> > Thanks for hearing this out,
> > Austin
> >
> > [0]: https://kuma.io/
> > [1]:
> >
> https://kuma.io/docs/0.5.0/policies/traffic-metrics/#configure-dataplane-discovery-by-prometheus-2
> > [2]: https://github.com/prometheus/prometheus/issues/6484
> > [3]: https://github.com/prometheus/prometheus/issues/7919
> > On Friday, December 20, 2019 at 6:55:08 PM UTC-5
> > brian@robustperception.io wrote:
> >
> > > On Fri, 20 Dec 2019 at 22:57, Yaroslav Skopets 
> wrote:
> > >
> > >> Thank you!
> > >>
> > >> Do you why the discussion around `http_sd` stop ?
> > >>
> > >
> > > That particular one looks like it started going into the weeds of
> > > inventing a brand new SD, and petered out. There's enough of them out
> there
> > > without us creating more.
> > >
> > > More generally, why should we have two generic SDs? That kinda defeats
> the
> > > purpose of having a generic integration, which is to have one thing
> that
> > > all the other use cases can be handled via.
> > > If you want to add a hop that goes over http it's not exactly
> difficult to
> > > run curl in a cronjob or have a sidecar.
> > >
> > > Brian
> > >
> > >
> > >> On Fri, Dec 20, 2019 at 11:19 PM Daniel Swarbrick <
> > >> daniel.s...@cloud.ionos.com> wrote:
> > >>
> > >>> You might want to read this earlier thread first:
> > >>>
> https://groups.google.com/d/topic/prometheus-developers/3B3jBsErK5M/discussion
> > >>>
> > >>> I would certainly be in favour of some generic gRPC-based SD method,
> > 

Re: [prometheus-developers] Introduce the concept of scrape Priority for Targets

[Frederic Branczyk]

That's only effective in limiting the number of targets, the point here is
that selectively scraping those with a higher priority based on
backpressure of the system as a whole.

On Wed, 22 Jul 2020 at 17:00, Julien Pivotto 
wrote:

> On 22 Jul 16:47, Frederic Branczyk wrote:
> > In practice even that can still be problematic. You only know that
> > Prometheus has a problem when everything fails, the point is to keep
> things
> > alive well enough for more critical components.
> >
> > On Wed, 22 Jul 2020 at 16:38, Julien Pivotto  >
> > wrote:
> >
> > > On 22 Jul 16:36, Frederic Branczyk wrote:
> > > > It's unclear how that helps, can you help me understand?
> > >
> > > - job: highprio
> > >   relabel_configs:
> > >   - target_label: job
> > > replacement: pods
> > >   - source_labels: [__meta_pod_priority]
> > > regex: high
> > > action: keep
>
> highprio job will always be scraped.
>
> > > - job: lowprio
> > >   relabel_configs:
> > >   - target_label: job
> > > replacement: pods
> > >   - source_labels: [__meta_pod_priority]
> > > regex: high
> > > action: drop
> > >   target_limit: 1000
> > >
> > > >
> > > > On Wed, 22 Jul 2020 at 16:34, Julien Pivotto <
> roidelapl...@prometheus.io
> > > >
> > > > wrote:
> > > >
> > > > > On 22 Jul 16:32, Frederic Branczyk wrote:
> > > > > > Can you explain what you mean by two jobs? Do you mean two scrape
> > > > > configs?
> > > > >
> > > > > Yes.
> > > > >
> > > > > >
> > > > > > On Wed, 22 Jul 2020 at 11:40, Julien Pivotto <
> > > roidelapl...@prometheus.io
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On 22 Jul 02:35, Lili Cosic wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wednesday, 22 July 2020 11:23:00 UTC+2, Brian Brazil
> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, 22 Jul 2020 at 10:18, Julien Pivotto <
> > > > > roidel...@prometheus.io
> > > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> On 22 Jul 02:14, Lili Cosic wrote:
> > > > > > > > >> > Only now seen in the docs that I am supposed to start
> any
> > > > > > > discussions
> > > > > > > > >> here
> > > > > > > > >> > first before opening an issue, sorry about that! :)
> > > > > > > > >> >
> > > > > > > > >> > Currently there is no way of a target to have higher
> scrape
> > > > > > > priority
> > > > > > > > >> over
> > > > > > > > >> > another, but if you have a setup and even if you set
> target
> > > > > limits
> > > > > > > and
> > > > > > > > >> > sample limits you can still overestimate your setup, you
> > > still
> > > > > want
> > > > > > > to
> > > > > > > > >> have
> > > > > > > > >> > a higher priority targets that are preferred over the
> entire
> > > > > > > Prometheus
> > > > > > > > >> to
> > > > > > > > >> > fail. It would need to be based on the inability to
> ingest
> > > into
> > > > > > > tsdb on
> > > > > > > > >> the
> > > > > > > > >> > current rate we are scrapping, if that is hit the
> priority
> > > class
> > > > > > > would
> > > > > > > > >> take
> > > > > > > > >> > affect and only the highest priority targets would be
> > > scrapped
> > > > > in
> > > > > > > > >> favour of
> > > > > > > > >> > lower priority. Another option which might be simpler
> would
> > > be
> > > > > to
> > > > > > > have
> > > > > > > > >> a
> > > >

Re: [prometheus-developers] Introduce the concept of scrape Priority for Targets

[Frederic Branczyk]

In practice even that can still be problematic. You only know that
Prometheus has a problem when everything fails, the point is to keep things
alive well enough for more critical components.

On Wed, 22 Jul 2020 at 16:38, Julien Pivotto 
wrote:

> On 22 Jul 16:36, Frederic Branczyk wrote:
> > It's unclear how that helps, can you help me understand?
>
> - job: highprio
>   relabel_configs:
>   - target_label: job
> replacement: pods
>   - source_labels: [__meta_pod_priority]
> regex: high
> action: keep
> - job: lowprio
>   relabel_configs:
>   - target_label: job
> replacement: pods
>   - source_labels: [__meta_pod_priority]
> regex: high
> action: drop
>   target_limit: 1000
>
> >
> > On Wed, 22 Jul 2020 at 16:34, Julien Pivotto  >
> > wrote:
> >
> > > On 22 Jul 16:32, Frederic Branczyk wrote:
> > > > Can you explain what you mean by two jobs? Do you mean two scrape
> > > configs?
> > >
> > > Yes.
> > >
> > > >
> > > > On Wed, 22 Jul 2020 at 11:40, Julien Pivotto <
> roidelapl...@prometheus.io
> > > >
> > > > wrote:
> > > >
> > > > > On 22 Jul 02:35, Lili Cosic wrote:
> > > > > >
> > > > > >
> > > > > > On Wednesday, 22 July 2020 11:23:00 UTC+2, Brian Brazil wrote:
> > > > > > >
> > > > > > > On Wed, 22 Jul 2020 at 10:18, Julien Pivotto <
> > > roidel...@prometheus.io
> > > > > > > > wrote:
> > > > > > >
> > > > > > >> On 22 Jul 02:14, Lili Cosic wrote:
> > > > > > >> > Only now seen in the docs that I am supposed to start any
> > > > > discussions
> > > > > > >> here
> > > > > > >> > first before opening an issue, sorry about that! :)
> > > > > > >> >
> > > > > > >> > Currently there is no way of a target to have higher scrape
> > > > > priority
> > > > > > >> over
> > > > > > >> > another, but if you have a setup and even if you set target
> > > limits
> > > > > and
> > > > > > >> > sample limits you can still overestimate your setup, you
> still
> > > want
> > > > > to
> > > > > > >> have
> > > > > > >> > a higher priority targets that are preferred over the entire
> > > > > Prometheus
> > > > > > >> to
> > > > > > >> > fail. It would need to be based on the inability to ingest
> into
> > > > > tsdb on
> > > > > > >> the
> > > > > > >> > current rate we are scrapping, if that is hit the priority
> class
> > > > > would
> > > > > > >> take
> > > > > > >> > affect and only the highest priority targets would be
> scrapped
> > > in
> > > > > > >> favour of
> > > > > > >> > lower priority. Another option which might be simpler would
> be
> > > to
> > > > > have
> > > > > > >> a
> > > > > > >> > global limit on how much prometheus can handle based on perf
> > > > > testing.
> > > > > > >> >
> > > > > > >> > This would be treated as a last resort, and there would
> > > definitely
> > > > > be a
> > > > > > >> > need for a high severity alert to inform the admin that
> > > something
> > > > > went
> > > > > > >> > terribly wrong, but because we would still be able to ingest
> > > > > Prometheus
> > > > > > >> > metrics for example if they are higher priority class
> alerting
> > > > > would be
> > > > > > >> > possible.
> > > > > > >>
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> I think that limiting the number of targets you scrape is
> already
> > > a
> > > > > last
> > > > > > >> resort. I don't think we would need a second line of defense.
> > > > > > >>
> > > > > > >
> > > > > > > I agree with Julien 

Re: [prometheus-developers] Introduce the concept of scrape Priority for Targets

[Frederic Branczyk]

It's unclear how that helps, can you help me understand?

On Wed, 22 Jul 2020 at 16:34, Julien Pivotto 
wrote:

> On 22 Jul 16:32, Frederic Branczyk wrote:
> > Can you explain what you mean by two jobs? Do you mean two scrape
> configs?
>
> Yes.
>
> >
> > On Wed, 22 Jul 2020 at 11:40, Julien Pivotto  >
> > wrote:
> >
> > > On 22 Jul 02:35, Lili Cosic wrote:
> > > >
> > > >
> > > > On Wednesday, 22 July 2020 11:23:00 UTC+2, Brian Brazil wrote:
> > > > >
> > > > > On Wed, 22 Jul 2020 at 10:18, Julien Pivotto <
> roidel...@prometheus.io
> > > > > > wrote:
> > > > >
> > > > >> On 22 Jul 02:14, Lili Cosic wrote:
> > > > >> > Only now seen in the docs that I am supposed to start any
> > > discussions
> > > > >> here
> > > > >> > first before opening an issue, sorry about that! :)
> > > > >> >
> > > > >> > Currently there is no way of a target to have higher scrape
> > > priority
> > > > >> over
> > > > >> > another, but if you have a setup and even if you set target
> limits
> > > and
> > > > >> > sample limits you can still overestimate your setup, you still
> want
> > > to
> > > > >> have
> > > > >> > a higher priority targets that are preferred over the entire
> > > Prometheus
> > > > >> to
> > > > >> > fail. It would need to be based on the inability to ingest into
> > > tsdb on
> > > > >> the
> > > > >> > current rate we are scrapping, if that is hit the priority class
> > > would
> > > > >> take
> > > > >> > affect and only the highest priority targets would be scrapped
> in
> > > > >> favour of
> > > > >> > lower priority. Another option which might be simpler would be
> to
> > > have
> > > > >> a
> > > > >> > global limit on how much prometheus can handle based on perf
> > > testing.
> > > > >> >
> > > > >> > This would be treated as a last resort, and there would
> definitely
> > > be a
> > > > >> > need for a high severity alert to inform the admin that
> something
> > > went
> > > > >> > terribly wrong, but because we would still be able to ingest
> > > Prometheus
> > > > >> > metrics for example if they are higher priority class alerting
> > > would be
> > > > >> > possible.
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> I think that limiting the number of targets you scrape is already
> a
> > > last
> > > > >> resort. I don't think we would need a second line of defense.
> > > > >>
> > > > >
> > > > > I agree with Julien here. If you've gotten to this point you're
> > > already
> > > > > seriously overloaded, and prioritising individual targets is just
> > > > > rearranging the deckchairs at that point.
> > > > >
> > > > >
> > > > >>
> > > > >> You can achieve this priority by setting 2 jobs, one which is
> limited
> > > > >> and one which is not, and use relabeling to decinde which target
> is
> > > > >> going in which job.
> > > > >>
> > > > >
> > > > > Or more generally, one Prometheus for the important targets and
> > > another
> > > > > for the less important and riskier targets.
> > > > >
> > > >
> > > > I get your point completely Brian, and agree to some degree but
> people
> > > are
> > > > still going to be setting up a multi tenant prometheus which then
> causes
> > > > the above problems I mentioned. Even within the riskier targets there
> > > will
> > > > be some more important than others for users. I think we should still
> > > > strive to making a single shared Prometheus as safe as possible, if
> this
> > > is
> > > > not the priority class I suggested, open to other ideas!
> > >
> > > Then 2 jobs are the answer, one unlimited and one limited.
> > >
> > > The target_li

Re: [prometheus-developers] Introduce the concept of scrape Priority for Targets

[Frederic Branczyk]

Can you explain what you mean by two jobs? Do you mean two scrape configs?

On Wed, 22 Jul 2020 at 11:40, Julien Pivotto 
wrote:

> On 22 Jul 02:35, Lili Cosic wrote:
> >
> >
> > On Wednesday, 22 July 2020 11:23:00 UTC+2, Brian Brazil wrote:
> > >
> > > On Wed, 22 Jul 2020 at 10:18, Julien Pivotto  > > > wrote:
> > >
> > >> On 22 Jul 02:14, Lili Cosic wrote:
> > >> > Only now seen in the docs that I am supposed to start any
> discussions
> > >> here
> > >> > first before opening an issue, sorry about that! :)
> > >> >
> > >> > Currently there is no way of a target to have higher scrape
> priority
> > >> over
> > >> > another, but if you have a setup and even if you set target limits
> and
> > >> > sample limits you can still overestimate your setup, you still want
> to
> > >> have
> > >> > a higher priority targets that are preferred over the entire
> Prometheus
> > >> to
> > >> > fail. It would need to be based on the inability to ingest into
> tsdb on
> > >> the
> > >> > current rate we are scrapping, if that is hit the priority class
> would
> > >> take
> > >> > affect and only the highest priority targets would be scrapped in
> > >> favour of
> > >> > lower priority. Another option which might be simpler would be to
> have
> > >> a
> > >> > global limit on how much prometheus can handle based on perf
> testing.
> > >> >
> > >> > This would be treated as a last resort, and there would definitely
> be a
> > >> > need for a high severity alert to inform the admin that something
> went
> > >> > terribly wrong, but because we would still be able to ingest
> Prometheus
> > >> > metrics for example if they are higher priority class alerting
> would be
> > >> > possible.
> > >>
> > >> Hi,
> > >>
> > >> I think that limiting the number of targets you scrape is already a
> last
> > >> resort. I don't think we would need a second line of defense.
> > >>
> > >
> > > I agree with Julien here. If you've gotten to this point you're
> already
> > > seriously overloaded, and prioritising individual targets is just
> > > rearranging the deckchairs at that point.
> > >
> > >
> > >>
> > >> You can achieve this priority by setting 2 jobs, one which is limited
> > >> and one which is not, and use relabeling to decinde which target is
> > >> going in which job.
> > >>
> > >
> > > Or more generally, one Prometheus for the important targets and
> another
> > > for the less important and riskier targets.
> > >
> >
> > I get your point completely Brian, and agree to some degree but people
> are
> > still going to be setting up a multi tenant prometheus which then causes
> > the above problems I mentioned. Even within the riskier targets there
> will
> > be some more important than others for users. I think we should still
> > strive to making a single shared Prometheus as safe as possible, if this
> is
> > not the priority class I suggested, open to other ideas!
>
> Then 2 jobs are the answer, one unlimited and one limited.
>
> The target_limit is already pretty advanced use case.
>
> >
> >
> > >
> > > Brian
> > >
> > >
> > >>
> > >> >
> > >> > We could model this on something like PriorityClass
> > >> > <
> > >>
> https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass>
>
> > >> from
> > >> > Kubernetes, but I am open to other suggestions.
> > >>
> > >> That could be used in relabeling as I said.
> > >>
> > >> >
> > >> > I am open to other suggestions, or maybe there is something like
> this
> > >> but I
> > >> > missed it. The main purpose is to ensure there are protection
> > >> mechanisms in
> > >> > place, so any ideas and suggestions welcome!
> > >> >
> > >>
> > >> regards,
> > >>
> > >> > Thanks and kind regards,
> > >> > Lili
> > >> >
> > >> > --
> > >> > 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/30df615e-5420-4bdf-9cb7-2790ef19d520o%40googlegroups.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/20200722091759.GA140540%40oxygen
> > >> .
> > >>
> > >
> > >
> > > --
> > > 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
>

Re: [prometheus-developers] Shipping mixins

[Frederic Branczyk]

I've thought for quite some time about how the experience around mixins
could maybe be improved. I'm not sure pre-compiled versions are necessarily
the best thing. I think there can be a more dynamic yet equally convenient
solution to this. Something that I've thought about a bit is something that
in my head I call "auto discovery", where mixins could define a query which
discovers label selectors that it might be applicable to. For example for
the prometheus-mixin that could be `prometheus_build_info`, this is still a
heuristic but tends to be a very accurate one, and is just a suggestion, a
user would still make the final decision.

More generally speaking I think there is still a good amount of room for
improvement on user experience around mixins, but there are many people
interested in this, so I'd be more than happy to talk to anyone who wants
to go over more details and we could build some tooling to make this
reality.

On Sat, 4 Jul 2020 at 10:51, Julius Volz  wrote:

> I assume that with "the mixins", you mean the ones at
> https://monitoring.mixins.dev/ / https://github.com/monitoring-mixins/docs
> .
>
> Shipping such rule and dashboard templates along with the software that
> exposes the metrics that they work for was part of my initial idea many
> years ago in
> https://docs.google.com/document/d/1oXfthGcAOMriy7PEqrq_E8ecz1U_Jyn3QYqEWoHN7S8/edit#
>
> Quote from that document:
>
> "During the experimental phase, we should probably start with a
> centralized repository that is clearly marked as experimental (and might go
> away). This enables quick iteration and experimentation with the example
> bundles, until we get a better idea of what works and what doesn’t. When
> the example bundle format becomes more settled and people agree on the
> usefulness of the concept, we should consider hosting the examples in
> decentralized fashion, together with the exporting components."
>
> So if we think that the overall way of structuring mixins has become
> relatively stable, it might be time for that second phase. I'm not
> personally involved enough with the current jsonnet mixins efforts to judge
> that, but I'm sure others can.
>
> Cheers,
> Julius
>
> On Fri, Jul 3, 2020 at 8:53 PM Julien Pivotto 
> wrote:
>
>> Dear developers,
>>
>> What would you think about shipping the mixins with the Prometheus
>> (&exporters) releases? Maybe e.g. a minimum compiled version of the
>> alerting rules, which would work nicely in the default prometheus.yml
>> file..
>>
>> --
>> 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/20200703185353.GA486029%40oxygen
>> .
>>
>
>
> --
> 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/CAObpH5x2nZ15dN5WzoSWAtvKmUPAM%3DH%2BH-E6Ekhxx-J4qPcAbg%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/CAOs1Umx7NBkeBx9nePzBzth15XO14KrEo1U%3D_Mi7FLdcOdJpZg%40mail.gmail.com.

Re: [prometheus-developers] Changing `master` to `main` across the org?

[Frederic Branczyk]

Tobias’ idea sounds great, and I’m +1 with this!

On Wed 24. Jun 2020 at 17:17, Tobias Schmidt  wrote:

> +1
>
> As Github seems to be working on it already, I'd wait to see what they can
> provide to simplify the transition. Would it make sense to tweet from our
> Twitter account to let them know we're interested in such functionality?
>
> I looked at other problematic terminologies across our code bases, and
> it'll be hard to do much about it until third-parties have changed it on
> their side, e.g.
> https://github.com/search?q=org%3Aprometheus+slave&type=Code
>
> On Wed, Jun 24, 2020 at 4:15 PM Bartłomiej Płotka 
> wrote:
>
>> +1 on this from Prometheus side, but also cc Thanos Team, I think we
>> should do that everywhere.
>>
>> Kind Regards
>> Bartek
>>
>> On Wed, 24 Jun 2020 at 16:06, Richard Hartmann <
>> richih.mailingl...@gmail.com> wrote:
>>
>>> Dear all,
>>>
>>> I talked about this with a few of you already and the general feeling
>>> of the room was "this is worthwhile, but it carries an opportunity
>>> cost". So: What do you think? Should this be a goal?
>>>
>>> CNCF is on board and assigned tech writer resources to switching over,
>>> and I suggested making CI/CD migrations etc part of Community Bridge
>>> outreach as it's a great intern project.
>>>
>>> It definitely makes sense to wait for GitHub to decide on a name and
>>> to provide tooling to minimize toil.
>>>
>>> Thoughts?
>>>
>>>
>>> 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%2BgTerwefdtSU5PB0vPmYA%2BW-20VoDy2GG7AH6F%2BG2RoL3Q%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/CAMssQwZPF36eS-Sz0c%3DTArmdy7scuZ7FGv2KQjaF2CzwnkLF1g%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Thanos Team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to thanos-io+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/thanos-io/CAChBsdC01oRuGXRmTk-gJVwB1MmbwF5nGfj4OD732Oswfbp1dA%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/CAOs1Umwj%3DtUA8RzN2z2bUGd7uoopf9yidh01K1qLMUyngvB%3DKw%40mail.gmail.com.

[prometheus-developers] Change language on blackbox vs whitebox to closedbox vs openbox

[Frederic Branczyk]

Hi all,

I would like to propose to change all occurrences and namings within the 
Prometheus project of whitebox and blackbox monitoring. In itself the term 
Black 
box  doesn't seem to come from a 
racist background, but I think it's problematic when the opposite is 
"white", in particular as this has a connotation in relation to 
whitelist/blacklist namings which are undoubtedly problematic. I would like 
to propose to replace them with open/closed box monitoring, which not only 
removes any potential of being offensive, it actually conveys much more 
clearly what is meant without having to explain.

The biggest impact this would have would be renaming of the 
blackbox_exporter  to 
closedbox_exporter, all other occurrences of this language seem to be 
limited to documentation.

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/98b3d620-d0d6-4436-bf15-3d90915f7909o%40googlegroups.com.

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

[Frederic Branczyk]

I wasn't saying they don't have their place, I'm saying they both do too
much to accurately match their name. The prometheus chart should only be
about deploying prometheus, and nothing else, as in no additional exporters
etc. and neither should the prometheus-operator chart, it should only
deploy the prometheus-operator and nothing else.

There is a place for higher level/meta packages, but not named "prometheus"
or "prometheus-operator" is all I'm saying.

On Tue, 9 Jun 2020 at 15:43, Stuart Clark  wrote:

> On 09/06/2020 13:15, David Karlsen wrote:
> > +1
> > Single chart for single components, and then an umbrella-chart can
> > bring all of them together - then people can select whatever is most
> > appropriate.
> >
> >
>
> Prometheus Operator & generic Prometheus are two different things, and
> the existing Helm repo reflects that.
>
> You can use the various individual Helm charts to install Prometheus,
> Alertmanager, Grafana and various exporters and then manually plumb
> things together.
>
> Alternatively Prometheus Operator mixes in some extra magic using
> slightly customised deployments (using the Prometheus Operator chart) to
> allow decentralised configuration using different CRDs (ServiceMonitors
> for what to scrape, alert rules, instances, etc.)
>
> So both have their place.
>
> --
> 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/CAOs1UmzHcEWp6SaPgE0Rg65PXJer0in%3DBDD0Qha8%3DV%3D%3DMh3gQQ%40mail.gmail.com.

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

[Frederic Branczyk]

I personally think the amount of things happening in these charts is too
big to represent "prometheus". Same goes for the prometheus-operator chart.
Both of these cover a very large surface and as a result issues frequently
get filed against the upstream projects confusing problems with the charts
with the scope of the projects themselves.

If a chart was in the community org then it should really only deploy and
configure Prometheus in my opinion. Meta charts that configure multiple
sub-charts would be ok, but under a different name (which is why we called
the project that integrates the two worlds tightly with each other
kube-prometheus ).

On Thu, 4 Jun 2020 at 23:50, Mingchin Hsieh  wrote:

> Hi guys,
>
> I am one of Helm Prometheus chart maintainers:
>
> https://github.com/helm/charts/blob/master/stable/prometheus/Chart.yaml#L18
>
> I hope I could help to move Helm Prometheus chart for looking new home. If
> after deprecation date, I will host it on my personal repo.
>
> Best,
> Ming
>
> On Tuesday, March 31, 2020 at 11:38:58 AM UTC+8, Naseem Ullah wrote:
>>
>> As per the helm charts stable repo deprecation timeline
>> , the various
>> prometheus related helm charts such as prometheus
>> ,
>>  prometheus-operator
>> ,
>> prometheus-adapter
>> ,
>> prometheus-node-exporter
>>  
>> and
>> the various other exporters will require a new home and none more fitting
>> than https://github.com/prometheus-community.We have had successful
>> migrations of the sort with other CNCF projects, namely Jaeger (
>> https://github.com/jaegertracing/helm-charts)  and Fluent Bit(
>> https://github.com/fluent/helm-charts).
>>
> --
> 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/53909810-686f-4550-977a-4f1c721dc8fao%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/CAOs1UmwkV8vMu%2BgEZ0kHNnJXMER%2BuNboSr_WxKnAWnv2J40gmA%40mail.gmail.com.

Re: [prometheus-developers] Call for Consensus: node_exporter 1.0.0 release

[Frederic Branczyk]

I think it’s your call to release 1.0, so if you feel it’s right then go
ahead :)

I do think we should make sure we do our best not to have inconsistencies
or possible breaking changes, so Julien’s PR about the config consistency
should probably be included.

On Fri 24. Apr 2020 at 01:20, Julien Pivotto  wrote:

> On 24 Apr 01:14, Bjoern Rabenstein wrote:
> > On 23.04.20 13:40, Richard Hartmann wrote:
> > >
> > > Should the maintainers (Ben & Fish) be allowed to release without
> > > waiting for the audit to finish?
> >
> > If that's their wish, yes, sure.
> >
> > Under the described circumstances, I don't see a reason to block them.
>
>
> I would however draw the attention to the fact that the current config is
> far from what Prometheus offers (regarding config key names).
>
> I have filled in https://github.com/prometheus/node_exporter/pull/1685
> to make it look similar to what we have in the prometheus server.
>
> >
> > --
> > 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/20200423231459.GJ2315%40jahnn
> .
>
> --
>  (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/20200423232018.GA1315860%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/CAOs1Umw2OcfqCfmVbLtZCtEPn-m9aJ5Mifae8%2ByMmQM7s29%2BmA%40mail.gmail.com.

Re: [prometheus-developers] Structure of reference and user documentation

[Frederic Branczyk]

I tend to agree with Brian, I don’t think we should change our existing
structure but I’m all for adding more user guide style docs.

No strong opinion on the wording.

On Wed 15. Apr 2020 at 14:53, Brian Brazil 
wrote:

> On Wed, 15 Apr 2020 at 13:44, Richard Hartmann <
> richih.mailingl...@gmail.com> wrote:
>
>> Dear all,
>>
>> currently our documentation is treated largely treated as reference
>> documentation, i.e. useful to look up stuff you already know or at
>> least fundamentally understand. We have a few guides, which do not
>> tell a consistent story of "I have nothing, and I want to have
>> something" i.e. "Hello World!" yet.
>>
>> Reviving a discussion from 2016-ish, I would like to propose that we
>> use our current reference docs as the starting point for actual user
>> documentation and move the reference to a space in which it can
>> continue for looking up stuff people already know and understand.
>>
>> Structure in `docs/` should be retained as far as possible so as not
>> to break incoming links, I suggest copying the same structure and
>> content under `docs/reference/`, and then starting to edit `docs/` to
>> be useful to newcomers.
>>
>
> I am against breaking existing users depending on where our reference docs
> are. I'm also against duplicating our existing reference docs as reference
> docs are not a good base for other types of documentation, and it'd likely
> lead to outdated documentation.
>
> If someone wishes to add tutorials there's an existing Guides section, and
> I'd prefer those looking to expand the docs start there rather trying to
> make reference docs do things that reference docs aren't suited to.
>
>
>> As an editorial discussion, I think the user documentation should be
>> in active voice "you can" and not passive voice "it is possible to".
>>
>
> When you say user documentation, which type of docs are you talking about?
>
> In terms of types of documentation https://documentation.divio.com/
> matches my personal experiences.
>
>
>> The current reference documentation is inconsistent, I don't know if
>> anyone would care to clean it up into completely active or completely
>> passive voice.
>>
>
> Reference documentation is about describing a piece of software, so we
> should be talking about the software in the 3rd person rather than talking
> to the user in the 2nd person. "it is possible to" would be unclear for
> reference documentation, I don't want to know some things that might be
> possible - I want to know exactly how the software behaves.
>
> Brian
>
>
>> We can split out the editorial discussion from this thread if needed.
>>
>>
>> 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%2BgTMqNA4uR-yedUYeWea6ZDc_PWCBQZJEFuFb%2BioAsdmpQ%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/CAHJKeLoaLp1fovYXw3g6gNapCJieRgtMUtjuC6O-zuerLU50hg%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/CAOs1UmzfAyixD7yo8kfWJWf-aDSY5s%3DBy32Zk4u_9jqxk1KLCQ%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] [VOTE] New governance document

[Frederic Branczyk]

Yes

On Thu 20. Feb 2020 at 09:32, 'Matthias Rampke' via Prometheus Developers <
prometheus-developers@googlegroups.com> wrote:

> Yes
>
> On Thu, 20 Feb 2020, 06:32 Julien Pivotto,  wrote:
>
>> Yes
>>
>> - Original Message -
>> From: Richard Hartmann 
>> To: Prometheus Developers 
>> Sent: Wed, 19 Feb 2020 21:43:52 +0100 (CET)
>> Subject: [prometheus-developers] [VOTE] New governance document
>>
>> Dear all,
>>
>> I am hereby calling for a vote on merging
>> https://github.com/prometheus/docs/pull/1552 at commit
>> de2266c36d8a2ea1f139f97632808e12b354bb76.
>>
>> References and discussion can be found in said PR and in the email
>> thread "Pre-vote feedback on proposed governance changes" on
>> prometheus-team (not visible to the public).
>>
>> This vote will run until 2020-02-26 23:59 UTC or when supermajority
>> has been reached, whichever comes first.
>>
>>
>> Please note that while we are voting in public, only Prometheus team
>> members are eligible to vote.
>>
>>
>> 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%2BgTHNk%3DORUiU%3DKucKtgKDUtSEfGv%2BQVLFKB-d0sVc%2ByBNQ%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/1227202491.1267.1582176757771.JavaMail.zimbra%40inuits.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/CAFU3N5VNYDB14FwhqKsnOgB3vVUh%2B%3DZMNRHis46rWPZBpLmuEQ%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/CAOs1Umx7FjbZxLPXuKGmEcJF9tm1%3D8dK0S85uDosjVR-5tVPHg%40mail.gmail.com.

Re: [prometheus-developers] Moving "official" JIRA Alertmanager integration (github.com/free/jiralert) to prometheus-community Organization.

[Frederic Branczyk]

Fully agree with Matthias. Happy to have this in -community!

On Mon 17. Feb 2020 at 10:57, Bartłomiej Płotka  wrote:

> cc Alin (:
>
> On Mon, 17 Feb 2020 at 09:42, Matthias Rampke  wrote:
>
>> +1 given the prominence of "warning alert = ticket" in SRE lore, having a
>> building block available for this in -community is a good thing.
>>
>> /MR
>>
>> On Sun, Feb 16, 2020 at 11:08 AM Bartłomiej Płotka 
>> wrote:
>>
>>> Hi,
>>>
>>> As per https://github.com/prometheus-community/community/issues/6 I
>>> would like to propose moving https://github.com/free/jiralert project
>>> to the promethus-community organization.
>>>
>>> I am a maintainer of the Jiralert and I am happy to continue those
>>> duties once moved to prometheus-community org. Initial author, Alin
>>>  approved the idea as well. Of course, if
>>> anyone wants to help us in maintaining Jiralert, let us know. (:
>>>
>>> I believe it makes sense to host in our common community org as this is
>>> official JIRA integration for Alertmanager as per
>>> https://prometheus.io/docs/operating/integrations/#alertmanager-webhook-receiver.
>>> Reasons are: more visibility and collaborating with other community
>>> projects on best-maintaining practices etc
>>>
>>> Any objections? (:
>>>
>>> Kind Regards,
>>> Bartek
>>>
>>> --
>>> 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/CAMssQwaP_uB%3DHzkuFPXqNhtXaPmM8YxuvLvSLUMrLJk_89QfoA%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/CAMssQwY%2B3WMUUCEmaqpF422JTMXLYFFpoAXUn-6j%2B8S8VvyoFA%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/CAOs1Umxaa7oy2JXs0%2Bnif6yVT924wE-UxPvC5Q2WPkHu2KLkAA%40mail.gmail.com.

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

[Frederic Branczyk]

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.