[prometheus-developers] [announcement] Non-Google mirror of mailing lists

[Daniel Trüssel]

Hi

If you have moral and ethical concerns about using Google Groups, there 
is now an alternative for you: a mirror of the mailing lists at 
mail-archive.com. Sadly it's read-only.


prometheus-users

web: https://www.mail-archive.com/prometheus-users@googlegroups.com/

rss: 
https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.xml


prometheus-developers

web: https://www.mail-archive.com/prometheus-developers@googlegroups.com/

rss: 
https://www.mail-archive.com/prometheus-developers@googlegroups.com/maillist.xml


prometheus-announce

web: https://www.mail-archive.com/prometheus-announce@googlegroups.com/

rss: 
https://www.mail-archive.com/prometheus-announce@googlegroups.com/maillist.xml


(thanks to Tobias Schmidt  for support)

kind regards

Daniel

--
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/c92d48b8-c1c0-cbd7-67ad-cfc52195ae22%40airmail.cc.

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

[Julius Volz]

I'm with Björn and Brian on keeping the CHANGELOG.md manually curated. You
need to understand all relevant changes since the last release anyway as
the release shepherd, and it's much easier and less overall overhead to
weigh everything centrally in the end than trying to get everyone to
formulate changelog entries for every PR that in the end result in a
cohesive whole.

On Mon, Feb 17, 2020 at 4:13 PM Łukasz Mierzwa  wrote:

> Adopting one of many variants of semantic commits and using one of many
> tools that generates a changelog from it can save some time there.
> Examples: example: https://www.conventionalcommits.org/,
> https://keepachangelog.com/
> Going that path is easier if one uses commit message linter, to ensure all
> comit messages follow required format -
> https://github.com/conventional-changelog/commitlint
>
> That being said from a purely user oriented perspectice I always find it
> useful when changelog includes a section that gives me a human readable
> overview of what's included in given release, that is difficult to automate
> but can be added on top of automated changelog.
>
> On Monday, 17 February 2020 15:06:42 UTC, Björn Rabenstein wrote:
>>
>> Just my 2¢:
>>
>> I'm firmly in the camp of hand-creating the CHANGELOG. I do so many
>> editorial work on it that a pre-populated CHANGELOG might easily
>> create more work than it saves. I do have to understand anyway what
>> each change is doing as we are supposed to filter out changes that are
>> not user-visible/-impacting (which could as well be that a
>> user-visible change was introduced with its corresponding CHANGELOG
>> entry, but later it was removed again before a release happened).
>>
>> I'm essentially doing what Brian is doing when I cut a release. I only
>> found that problematic after releases were procrastinated for too long
>> and the CHANGELOG exploded. With the fixed cadence in
>> prometheus/prometheus, that isn't really a problem anymore (but 2.16.0
>> was a biggie nevertheless).
>>
>> What is a problem is unclear or incomplete commit and/or PR
>> descriptions. I guess we can all agree to ask for those in reviews.
>>
>> I don't feel strongly about how in detail we want to encourage good
>> commit and PR descriptions. If we put a hint in there to suggest a
>> changelog line if applicable, I'm all for it. If people want a
>> specific keyword to autoextract it, sure, as long as I don't have to
>> use it and it doesn't make it harder to contribute.
>>
>> I would not like to directly edit the CHANGELOG.md file in each PR,
>> for all the reasons already stated.
>>
>> --
>> 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/da403d28-cfad-41c2-8d0b-91168be070f5%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/CA%2BT6Yoxd7SOi%2BMPP%3Dbxmhm67kUy1QK_qECwBR1FkTtKU0%2BGFRg%40mail.gmail.com.

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

[Łukasz Mierzwa]

Adopting one of many variants of semantic commits and using one of many 
tools that generates a changelog from it can save some time there.
Examples: example: https://www.conventionalcommits.org/, 
https://keepachangelog.com/
Going that path is easier if one uses commit message linter, to ensure all 
comit messages follow required format - 
https://github.com/conventional-changelog/commitlint

That being said from a purely user oriented perspectice I always find it 
useful when changelog includes a section that gives me a human readable 
overview of what's included in given release, that is difficult to automate 
but can be added on top of automated changelog.

On Monday, 17 February 2020 15:06:42 UTC, Björn Rabenstein wrote:
>
> Just my 2¢: 
>
> I'm firmly in the camp of hand-creating the CHANGELOG. I do so many 
> editorial work on it that a pre-populated CHANGELOG might easily 
> create more work than it saves. I do have to understand anyway what 
> each change is doing as we are supposed to filter out changes that are 
> not user-visible/-impacting (which could as well be that a 
> user-visible change was introduced with its corresponding CHANGELOG 
> entry, but later it was removed again before a release happened). 
>
> I'm essentially doing what Brian is doing when I cut a release. I only 
> found that problematic after releases were procrastinated for too long 
> and the CHANGELOG exploded. With the fixed cadence in 
> prometheus/prometheus, that isn't really a problem anymore (but 2.16.0 
> was a biggie nevertheless). 
>
> What is a problem is unclear or incomplete commit and/or PR 
> descriptions. I guess we can all agree to ask for those in reviews. 
>
> I don't feel strongly about how in detail we want to encourage good 
> commit and PR descriptions. If we put a hint in there to suggest a 
> changelog line if applicable, I'm all for it. If people want a 
> specific keyword to autoextract it, sure, as long as I don't have to 
> use it and it doesn't make it harder to contribute. 
>
> I would not like to directly edit the CHANGELOG.md file in each PR, 
> for all the reasons already stated. 
>
> -- 
> 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/da403d28-cfad-41c2-8d0b-91168be070f5%40googlegroups.com.

Re: [prometheus-developers] Prometheus metrics are lost if the prometheus push gateway from different instance is down

[Bjoern Rabenstein]

On 17.02.20 03:10, Rajesh Somasundaram wrote:
> 
> 1) Instance A - running service xyz and its related metrics are pushed to
> push-gateway running in the same instance.
> 2) Instance B - Prometheus is scraping the metrics from Gateway and it is
> visualized in Grafana.
> 
> Issue:
> 
> 1) When the instance A is down, the prometheus lost its previously scraped
> metrics. Ideally, it should have saved the scraped metrics from the gateway
> though when the instance A is down.
>     But it is not happening at my end. Could anyone please help me with that?

Prometheus will for sure save the scraped metrics. It just cannot
ingest up-to-date metrics from the Pushgateway while it is down. So
time series end at the time of the last scrape, and that's probably
what you see in your visualization. That's the intended behavior. You
have to look farther back in time, or do some PromQL tricks with
max_over_time or avg_over_time (see also
https://www.robustperception.io/alerting-on-gauges-in-prometheus-2-0
for a related topic).

In different news, your question isn't really about development of
Prometheus itself. It is a better fit for the prometheus-users mailing
list, see https://groups.google.com/forum/#!forum/prometheus-users

-- 
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/20200217151236.GM2314%40jahnn.

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

[Bjoern Rabenstein]

Just my 2¢:

I'm firmly in the camp of hand-creating the CHANGELOG. I do so many
editorial work on it that a pre-populated CHANGELOG might easily
create more work than it saves. I do have to understand anyway what
each change is doing as we are supposed to filter out changes that are
not user-visible/-impacting (which could as well be that a
user-visible change was introduced with its corresponding CHANGELOG
entry, but later it was removed again before a release happened).

I'm essentially doing what Brian is doing when I cut a release. I only
found that problematic after releases were procrastinated for too long
and the CHANGELOG exploded. With the fixed cadence in
prometheus/prometheus, that isn't really a problem anymore (but 2.16.0
was a biggie nevertheless).

What is a problem is unclear or incomplete commit and/or PR
descriptions. I guess we can all agree to ask for those in reviews.

I don't feel strongly about how in detail we want to encourage good
commit and PR descriptions. If we put a hint in there to suggest a
changelog line if applicable, I'm all for it. If people want a
specific keyword to autoextract it, sure, as long as I don't have to
use it and it doesn't make it harder to contribute.

I would not like to directly edit the CHANGELOG.md file in each PR,
for all the reasons already stated.

-- 
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/20200217150639.GL2314%40jahnn.

[prometheus-developers] Prometheus metrics are lost if the prometheus push gateway from different instance is down

[Rajesh Somasundaram]

Hi All,

I am trying out some custom metrics using the prometheus push gateway 
service in AWS EC2 instance. Below is my use case.

1) Instance A - running service xyz and its related metrics are pushed to 
push-gateway running in the same instance.
2) Instance B - Prometheus is scraping the metrics from Gateway and it is 
visualized in Grafana.

Issue:

1) When the instance A is down, the prometheus lost its previously scraped 
metrics. Ideally, it should have saved the scraped metrics from the gateway 
though when the instance A is down.
But it is not happening at my end. Could anyone please help me with 
that?

Thanks,
Rajesh

-- 
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/f36e725f-7abb-42bd-9302-605f2e09c3f4%40googlegroups.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] Moving "official" JIRA Alertmanager integration (github.com/free/jiralert) to prometheus-community Organization.

[Bartłomiej Płotka]

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.

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

['Matthias Rampke' via Prometheus Developers]

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