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

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

Re: [prometheus-developers] [VOTE] New governance document

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 >>

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

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 < >

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

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

Re: [prometheus-developers] Prometheus rules and runtime reload

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

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

> 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

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

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

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

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

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

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 prac

Re: [prometheus-developers] Shipping mixins

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

;, as of v1.4.0 >>>> <https://blog.golang.org/protobuf-apiv2>. >>>> >>>> This surprised me a little, and sounds awesome - but I can't find any >>>> more information about it. Does v1.4.0 generate code for the serialisation >>>> /

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

> 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/fredbra

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

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

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

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,

Re: [prometheus-developers] Standard path for mixins

, 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 li

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

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

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

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

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

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

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

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