Re: [VOTE] PIP-219: Support full scan and trim ledger

[Cong Zhao]

+1(non-binding)

Thanks,
Cong

On 2022/11/01 14:28:14 linlin wrote:
> Hi folks,
> 
> I'd like to start a vote for the PIP-219: Support full scan and trim ledger
> (
> https://github.com/apache/pulsar/issues/18128)
> 
> The discussion can be found here:
> https://lists.apache.org/thread/wy8sqs2fdmw3kcdfos7t1ztpccfdmv72
> 
> Best regards.
> 
> linlin
> 

Re: Request a site ID and tracking code for Apache Pulsar

[tison]

Hi Martijn,

Thank you!
Best,
tison.


Martijn Visser  于2022年11月7日周一 16:44写道：

> Hi Tison,
>
> It most certainly is but I haven't had the time yet to reply yet. My
> apologies!
>
> Here's the tracking code for Pulsar. The code will need to be integrated in
> any page you want to track by adding it before the  tag. You can
> find the results at https://analytics.apache.org
>
> 
> 
>   var _paq = window._paq = window._paq || [];
>   /* tracker methods like "setCustomDimension" should be called before
>   "trackPageView" */
>   /* We explicitly disable cookie tracking to avoid privacy issues */
>   _paq.push(['disableCookies']);
>   _paq.push(['trackPageView']);
>   _paq.push(['enableLinkTracking']);
>   (function() {
> var u="https://analytics.apache.org/";;
> _paq.push(['setTrackerUrl', u+'matomo.php']);
> _paq.push(['setSiteId', '32']);
> var d=document, g=d.createElement('script'),
> s=d.getElementsByTagName('script')[0];
> g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
>   })();
> 
> 
>
> Best regards,
>
> Martijn
>
> Op ma 7 nov. 2022 om 09:17 schreef tison :
>
> > Hi,
> >
> > Is here the correct place to send this request to?
> >
> > Best,
> > tison.
> >
> >
> > Dave Fisher  于2022年11月2日周三 00:36写道：
> >
> > > - privacy.
> > >
> > > THANK YOU!
> > >
> > > Sent from my iPhone
> > >
> > > > On Nov 1, 2022, at 9:21 AM, tison  wrote:
> > > >
> > > > Hi Privacy Team,
> > > >
> > > > As proposed in https://github.com/apache/pulsar/issues/15664, the
> > Apache
> > > > Pulsar community is actively migrating from Google Analytics to the
> > > Matomo
> > > > solution.
> > > >
> > > > Reading from https://privacy.apache.org/matomo/, I send this email
> to
> > > > request a site ID and tracking code for Apache Pulsar. I think this
> > > setting
> > > > is public and the motivation is provided.
> > > >
> > > > dev@pulsar.a.o in cc. Please correct me if more prerequisites are
> > > needed.
> > > >
> > > > Best,
> > > > tison.
> > >
> > >
> >
>

Re: [PIP-214][broker]Add broker level metrics statistics and expose to prometheus discussion

[Asaf Mesika]

I'm reposting my comment from the PR as this requires further discussion to
reach an agreement.

---

You have decided to re-use the same metric name, but with removing the
namespace dimension. So we would do something like this in case we turn on
topic-level metrics:

pulsar_rate_in{host="brokerA"} - broker-level rate in
pulsar_rate_in{host="brokerA" namespace="ns1" topic="topic10"} - topic
level rate in

This creates duplicates when users will use it.
Say you wanted to see your cluster rate in, you would do something like
sum(pulsar_rate_in), but this sum two things:

   1. Topic level rate in, across all brokers.
   2. Broker level rate in, across all brokers

So, in effect, the rate would be doubled.

The idea is that the metric is divided into one granularity level, be it
(namespace, topic) or (namespace) so that sum by any dimension they wish.
You can't report two granularity levels of any metric under the same name.

Your previous version of adding another metric name and explicitly stating
its broker-level metric pulsar_broker_rate_in makes more sense.

IMO, it must be changed back, unless I'm missing something.

-


Yang, please note that doing what you suggested


If the user uses the following query, there will be no double rate:
> sum(pulsar_rate_in{namespace=""})



IMO is not a valid user experience for a Pulsar user. People don't do this
stuff (attribute=""), and we don't expect them to know this small detail
when authoring queries.


In theory, this should not be the concern of Pulsar at all - making the
aggregation since it can be done using TSDB like Prometheus recording rules
- but I do understand that emitting so many time series is inherently a
Pulsar issue. I accept this as a workaround for now.

I hope the work researched here
 will
yield a better long-term solution.


Thanks,


Asaf

On Mon, Oct 24, 2022 at 10:06 PM Michael Marshall 
wrote:

> I think this feature is already available out of the box, as Penghui
> suggests. You can get metrics per broker summing them up over the
> `instance` label or the `kubernetes_pod_name` label. These labels are
> added not by the broker, but instead by the prometheus scrape
> definition.
>
> Also, you are correct that there are some metrics that are always 0, e.g.:
>
> pulsar_topics_count{cluster="my-cluster"} 0
>
> The motivation for those metrics is provided here [0], though I'm not
> sure it is good motivation.
>
> Thanks,
> Michael
>
> [0]
> https://github.com/apache/pulsar/blob/6d6665e296e6714801048dee1292e3a07abb5cc1/pulsar-broker/src/main/java/org/apache/pulsar/broker/stats/prometheus/NamespaceStatsAggregator.java#L306-L307
>
> On Sun, Oct 23, 2022 at 8:52 PM PengHui Li  wrote:
> >
> > I support the motivation.
> >
> > When I read the document of Prometheus
> > I see "A label with an empty label value is considered equivalent to a
> > label that does not exist." [0]
> > Can we just keep the value of the topic and namespace label empty?
> > And here is a blog that introduced how to deal with the empty label [1]
> >
> > If this can work. We don't need to add new indicator names.
> > Otherwise, we might need "pulsar_tenant_*" ,"pulsar_namespace_*",
> > "pulsar_cluster_*" in the future.
> >
> > [0] https://prometheus.io/docs/concepts/data_model/
> > [1]
> >
> https://medium.com/pareture/query-results-where-label-is-not-present-in-prometheus-e1176320575d
> >
> > Thanks,
> > Penghui
> >
> > On Sun, Oct 23, 2022 at 6:14 PM Asaf Mesika 
> wrote:
> >
> > > One thing to note: You mentioned a PIP number but I'm not sure this is
> the
> > > right process you follow here for that.
> > >
> > >
> > > On Sun, Oct 23, 2022 at 1:12 PM Asaf Mesika 
> wrote:
> > >
> > > > The suggestion makes sense to me as well. I've also reviewed your PR.
> > > >
> > > > On Sun, Oct 23, 2022 at 8:43 AM Haiting Jiang <
> jianghait...@gmail.com>
> > > > wrote:
> > > >
> > > >> +1
> > > >> Makes sense to me.
> > > >>
> > > >> Thanks,
> > > >> Haiting
> > > >>
> > > >> On Sat, Oct 22, 2022 at 3:59 AM yang yijun 
> wrote:
> > > >> >
> > > >> > Hi,I have a suggestion to improve the broker.
> > > >> >
> > > >> > For detailed improvement instructions, please refer to issue:
> > > >> > https://github.com/apache/pulsar/issues/18056
> > > >> >
> > > >> > For detailed source code change, please refer to PR:
> > > >> > https://github.com/apache/pulsar/pull/18116
> > > >>
> > > >
> > >
>

Re: [DISCUSS] Release Pulsar 2.9.4

[mattison chao]

Thanks for volunteering to be the release manager


Best,
Mattison

On Fri, 4 Nov 2022 at 16:28, Haiting Jiang  wrote:

> +1
>
> Haiting
>
> On Fri, Nov 4, 2022 at 1:42 PM houxiaoyu  wrote:
> >
> > +1
> >
> > Best,
> > Xiaoyu Hou
> >
> > 丛搏  于2022年11月3日周四 14:01写道：
> >
> > > Hello, Pulsar community:
> > >
> > > I'd like to propose releasing Apache Pulsar 2.9.4. It's been about
> > > three months since 2.9.3 was released.
> > >
> > > There are 123 PRs [0] needed to cherry-pick in branch-2.9. I will
> > > cherry-pick these PRs for branch-2.9. Exclude some PRs that merge
> > > directly into branch-2.9.
> > >
> > > There are 33 PRs [1] opened. I'll follow up on each of those PRs to
> > > see if they will be completed soon or will need to be pushed to 2.9.5
> > >
> > > If you have any important fixes or any questions, please reply to this
> > > email, and we will evaluate whether to include them in 2.9.4
> > >
> > > Thanks,
> > > Bo
> > > [0] -
> > >
> https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.4+-label%3Acherry-picked%2Fbranch-2.9+is%3Amerged
> > > [1] -
> > >
> https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.4+is%3Aopen
> > > I will
> > >
>

Re: [DISCUSS] PIP-211: Introduce offload throttling

[Jiuming Tao]

> One alternative would be to throttle offload in the write path instead of 
> adding additional logic to the read path in managed ledgers.

This is really a feasible method.
But we need to make changes in FileSystem and BlobStore offloaders, event 
custom offloaders. I think this is not universal.

> One simple way to do this is to to limit how many threads can write offloaded 
> ledgers. This is the same way that reading of offloaded ledgers are already 
> “throttled” by that thread count defaulting to 2.

Yes, the offloader thread count is defaulting to 2, but, it does not 
effectively limit traffic. If the reading rate of BK is very fast, it also 
leads to high CPU/Memory/Network usage

Thanks,
Tao Jiuming

> 2022年11月2日 上午1:43，Dave Fisher  写道：
> 
> One alternative would be to throttle offload in the write path instead of 
> adding additional logic to the read path in managed ledgers.
> 
> One simple way to do this is to to limit how many threads can write offloaded 
> ledgers. This is the same way that reading of offloaded ledgers are already 
> “throttled” by that thread count defaulting to 2.
> 
> Regards,
> Dave
> 
> Sent from my iPhone
> 
>> On Nov 1, 2022, at 10:27 AM, Jiuming Tao  
>> wrote:
>> 
>> Hi pulsar community,
>> 
>> I opened a PIP to discuss: PIP-211: Introduce offload throttling
>> 
>> PIP link: https://github.com/apache/pulsar/issues/18004 
>> 
>> 
>> Thanks,
>> Tao Jiuming
> 

Re: [DISCUSS] PIP-211: Introduce offload throttling

[Michael Marshall]

This PIP is similar to autorecovery throttling. I think the feature
makes sense for the same reasons that throttling autorecovery makes
sense.

Tangentially, can we decouple writes to tiered storage from the broker
hosting the topic being offloaded? An independent service could write
to tiered storage without impacting the broker and could easily scale
as with the work. The primary complication for the service would be
figuring out which ledgers to offload. Perhaps the managed ledger
could "offer" ledgers up that need to be offloaded, and the new
service would only need to consume those events.

Although, a new service would complicate the pulsar deployment.

Thanks,
Michael

On Mon, Nov 7, 2022 at 10:30 AM Jiuming Tao
 wrote:
>
> > One alternative would be to throttle offload in the write path instead of 
> > adding additional logic to the read path in managed ledgers.
>
> This is really a feasible method.
> But we need to make changes in FileSystem and BlobStore offloaders, event 
> custom offloaders. I think this is not universal.
>
> > One simple way to do this is to to limit how many threads can write 
> > offloaded ledgers. This is the same way that reading of offloaded ledgers 
> > are already “throttled” by that thread count defaulting to 2.
>
> Yes, the offloader thread count is defaulting to 2, but, it does not 
> effectively limit traffic. If the reading rate of BK is very fast, it also 
> leads to high CPU/Memory/Network usage
>
> Thanks,
> Tao Jiuming
>
> > 2022年11月2日 上午1:43，Dave Fisher  写道：
> >
> > One alternative would be to throttle offload in the write path instead of 
> > adding additional logic to the read path in managed ledgers.
> >
> > One simple way to do this is to to limit how many threads can write 
> > offloaded ledgers. This is the same way that reading of offloaded ledgers 
> > are already “throttled” by that thread count defaulting to 2.
> >
> > Regards,
> > Dave
> >
> > Sent from my iPhone
> >
> >> On Nov 1, 2022, at 10:27 AM, Jiuming Tao  
> >> wrote:
> >>
> >> Hi pulsar community,
> >>
> >> I opened a PIP to discuss: PIP-211: Introduce offload throttling
> >>
> >> PIP link: https://github.com/apache/pulsar/issues/18004 
> >> 
> >>
> >> Thanks,
> >> Tao Jiuming
> >
>

Re: [PIP-214][broker]Add broker level metrics statistics and expose to prometheus discussion

[PengHui Li]

Hi Asaf,

Agree with your point.
+1 for the new indicator name solution.

Penghui

> On Nov 7, 2022, at 17:26, Asaf Mesika  wrote:
> 
> I'm reposting my comment from the PR as this requires further discussion to
> reach an agreement.
> 
> ---
> 
> You have decided to re-use the same metric name, but with removing the
> namespace dimension. So we would do something like this in case we turn on
> topic-level metrics:
> 
> pulsar_rate_in{host="brokerA"} - broker-level rate in
> pulsar_rate_in{host="brokerA" namespace="ns1" topic="topic10"} - topic
> level rate in
> 
> This creates duplicates when users will use it.
> Say you wanted to see your cluster rate in, you would do something like
> sum(pulsar_rate_in), but this sum two things:
> 
>   1. Topic level rate in, across all brokers.
>   2. Broker level rate in, across all brokers
> 
> So, in effect, the rate would be doubled.
> 
> The idea is that the metric is divided into one granularity level, be it
> (namespace, topic) or (namespace) so that sum by any dimension they wish.
> You can't report two granularity levels of any metric under the same name.
> 
> Your previous version of adding another metric name and explicitly stating
> its broker-level metric pulsar_broker_rate_in makes more sense.
> 
> IMO, it must be changed back, unless I'm missing something.
> 
> -
> 
> 
> Yang, please note that doing what you suggested
> 
> 
> If the user uses the following query, there will be no double rate:
>> sum(pulsar_rate_in{namespace=""})
> 
> 
> 
> IMO is not a valid user experience for a Pulsar user. People don't do this
> stuff (attribute=""), and we don't expect them to know this small detail
> when authoring queries.
> 
> 
> In theory, this should not be the concern of Pulsar at all - making the
> aggregation since it can be done using TSDB like Prometheus recording rules
> - but I do understand that emitting so many time series is inherently a
> Pulsar issue. I accept this as a workaround for now.
> 
> I hope the work researched here
>  will
> yield a better long-term solution.
> 
> 
> Thanks,
> 
> 
> Asaf
> 
> On Mon, Oct 24, 2022 at 10:06 PM Michael Marshall 
> wrote:
> 
>> I think this feature is already available out of the box, as Penghui
>> suggests. You can get metrics per broker summing them up over the
>> `instance` label or the `kubernetes_pod_name` label. These labels are
>> added not by the broker, but instead by the prometheus scrape
>> definition.
>> 
>> Also, you are correct that there are some metrics that are always 0, e.g.:
>> 
>> pulsar_topics_count{cluster="my-cluster"} 0
>> 
>> The motivation for those metrics is provided here [0], though I'm not
>> sure it is good motivation.
>> 
>> Thanks,
>> Michael
>> 
>> [0]
>> https://github.com/apache/pulsar/blob/6d6665e296e6714801048dee1292e3a07abb5cc1/pulsar-broker/src/main/java/org/apache/pulsar/broker/stats/prometheus/NamespaceStatsAggregator.java#L306-L307
>> 
>> On Sun, Oct 23, 2022 at 8:52 PM PengHui Li  wrote:
>>> 
>>> I support the motivation.
>>> 
>>> When I read the document of Prometheus
>>> I see "A label with an empty label value is considered equivalent to a
>>> label that does not exist." [0]
>>> Can we just keep the value of the topic and namespace label empty?
>>> And here is a blog that introduced how to deal with the empty label [1]
>>> 
>>> If this can work. We don't need to add new indicator names.
>>> Otherwise, we might need "pulsar_tenant_*" ,"pulsar_namespace_*",
>>> "pulsar_cluster_*" in the future.
>>> 
>>> [0] https://prometheus.io/docs/concepts/data_model/
>>> [1]
>>> 
>> https://medium.com/pareture/query-results-where-label-is-not-present-in-prometheus-e1176320575d
>>> 
>>> Thanks,
>>> Penghui
>>> 
>>> On Sun, Oct 23, 2022 at 6:14 PM Asaf Mesika 
>> wrote:
>>> 
 One thing to note: You mentioned a PIP number but I'm not sure this is
>> the
 right process you follow here for that.
 
 
 On Sun, Oct 23, 2022 at 1:12 PM Asaf Mesika 
>> wrote:
 
> The suggestion makes sense to me as well. I've also reviewed your PR.
> 
> On Sun, Oct 23, 2022 at 8:43 AM Haiting Jiang <
>> jianghait...@gmail.com>
> wrote:
> 
>> +1
>> Makes sense to me.
>> 
>> Thanks,
>> Haiting
>> 
>> On Sat, Oct 22, 2022 at 3:59 AM yang yijun 
>> wrote:
>>> 
>>> Hi,I have a suggestion to improve the broker.
>>> 
>>> For detailed improvement instructions, please refer to issue:
>>> https://github.com/apache/pulsar/issues/18056
>>> 
>>> For detailed source code change, please refer to PR:
>>> https://github.com/apache/pulsar/pull/18116
>> 
> 
 
>> 

Re: [DISCUSS] Release Pulsar 2.9.4

[lordcheng10]

+1

mattison chao  于2022年11月7日周一 20:01写道：

> Thanks for volunteering to be the release manager
>
>
> Best,
> Mattison
>
> On Fri, 4 Nov 2022 at 16:28, Haiting Jiang  wrote:
>
> > +1
> >
> > Haiting
> >
> > On Fri, Nov 4, 2022 at 1:42 PM houxiaoyu  wrote:
> > >
> > > +1
> > >
> > > Best,
> > > Xiaoyu Hou
> > >
> > > 丛搏  于2022年11月3日周四 14:01写道：
> > >
> > > > Hello, Pulsar community:
> > > >
> > > > I'd like to propose releasing Apache Pulsar 2.9.4. It's been about
> > > > three months since 2.9.3 was released.
> > > >
> > > > There are 123 PRs [0] needed to cherry-pick in branch-2.9. I will
> > > > cherry-pick these PRs for branch-2.9. Exclude some PRs that merge
> > > > directly into branch-2.9.
> > > >
> > > > There are 33 PRs [1] opened. I'll follow up on each of those PRs to
> > > > see if they will be completed soon or will need to be pushed to 2.9.5
> > > >
> > > > If you have any important fixes or any questions, please reply to
> this
> > > > email, and we will evaluate whether to include them in 2.9.4
> > > >
> > > > Thanks,
> > > > Bo
> > > > [0] -
> > > >
> >
> https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.4+-label%3Acherry-picked%2Fbranch-2.9+is%3Amerged
> > > > [1] -
> > > >
> >
> https://github.com/apache/pulsar/pulls?q=is%3Apr+label%3Arelease%2F2.9.4+is%3Aopen
> > > > I will
> > > >
> >
>

Re: [VOTE] PIP-219: Support full scan and trim ledger

[Hang Chen]

+1 (binding)

Thanks,
Hang

Cong Zhao  于2022年11月7日周一 16:35写道：
>
> +1(non-binding)
>
> Thanks,
> Cong
>
> On 2022/11/01 14:28:14 linlin wrote:
> > Hi folks,
> >
> > I'd like to start a vote for the PIP-219: Support full scan and trim ledger
> > (
> > https://github.com/apache/pulsar/issues/18128)
> >
> > The discussion can be found here:
> > https://lists.apache.org/thread/wy8sqs2fdmw3kcdfos7t1ztpccfdmv72
> >
> > Best regards.
> >
> > linlin
> >

Re: [VOTE] PIP-219: Support full scan and trim ledger

[Haiting Jiang]

+1 binding

Thanks
Haiting

On Tue, Nov 8, 2022 at 11:13 AM Hang Chen  wrote:
>
> +1 (binding)
>
> Thanks,
> Hang
>
> Cong Zhao  于2022年11月7日周一 16:35写道：
> >
> > +1(non-binding)
> >
> > Thanks,
> > Cong
> >
> > On 2022/11/01 14:28:14 linlin wrote:
> > > Hi folks,
> > >
> > > I'd like to start a vote for the PIP-219: Support full scan and trim 
> > > ledger
> > > (
> > > https://github.com/apache/pulsar/issues/18128)
> > >
> > > The discussion can be found here:
> > > https://lists.apache.org/thread/wy8sqs2fdmw3kcdfos7t1ztpccfdmv72
> > >
> > > Best regards.
> > >
> > > linlin
> > >

[GitHub] [pulsar] mnit016 added a comment to the discussion: Why pulsar retention quota must exceed configured backlog quota

[GitBox]

GitHub user mnit016 added a comment to the discussion: Why pulsar retention 
quota must exceed configured backlog quota

Hello @Jason918 , @michaeljmarshall , but I still confused, could you please 
explain for me why backlog quota couldn't exceed the retention? Is there any 
risk if we set backlog quota larger than retention?

GitHub link: 
https://github.com/apache/pulsar/discussions/17697#discussioncomment-4082549


This is an automatically sent email for dev@pulsar.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@pulsar.apache.org

Pulsar Summit Asia 2022 is coming! Check the schedule and register now for free!

[Sherlock Xu]

Hi Apache Pulsar community members,

Pulsar Summit Asia 2022  will be 
hosted virtually on November 19th and 20th, 2022. This two-day virtual event 
will feature 36 sessions by developers, engineers, architects, and 
technologists from ByteDance, Huawei, Tencent, Nippon Telegraph and Telephone 
Corporation (NTT) Software Innovation Center, Yum China, Netease, vivo, WeChat, 
Nutanix, StreamNative, and many more! Read this blog 

 to see details.

Check the schedule  and 
register now for free 
!

See you soon in Pulsar Summit Asia 2022!

Best,
Sherlock

Re: [PIP-214][broker]Add broker level metrics statistics and expose to prometheus discussion

[Michael Marshall]

I agree with your point, too, Asaf. Thanks for posting it on the mailing list.

- Michael

On Mon, Nov 7, 2022 at 6:38 PM PengHui Li  wrote:
>
> Hi Asaf,
>
> Agree with your point.
> +1 for the new indicator name solution.
>
> Penghui
>
> > On Nov 7, 2022, at 17:26, Asaf Mesika  wrote:
> >
> > I'm reposting my comment from the PR as this requires further discussion to
> > reach an agreement.
> >
> > ---
> >
> > You have decided to re-use the same metric name, but with removing the
> > namespace dimension. So we would do something like this in case we turn on
> > topic-level metrics:
> >
> > pulsar_rate_in{host="brokerA"} - broker-level rate in
> > pulsar_rate_in{host="brokerA" namespace="ns1" topic="topic10"} - topic
> > level rate in
> >
> > This creates duplicates when users will use it.
> > Say you wanted to see your cluster rate in, you would do something like
> > sum(pulsar_rate_in), but this sum two things:
> >
> >   1. Topic level rate in, across all brokers.
> >   2. Broker level rate in, across all brokers
> >
> > So, in effect, the rate would be doubled.
> >
> > The idea is that the metric is divided into one granularity level, be it
> > (namespace, topic) or (namespace) so that sum by any dimension they wish.
> > You can't report two granularity levels of any metric under the same name.
> >
> > Your previous version of adding another metric name and explicitly stating
> > its broker-level metric pulsar_broker_rate_in makes more sense.
> >
> > IMO, it must be changed back, unless I'm missing something.
> >
> > -
> >
> >
> > Yang, please note that doing what you suggested
> >
> >
> > If the user uses the following query, there will be no double rate:
> >> sum(pulsar_rate_in{namespace=""})
> >
> >
> >
> > IMO is not a valid user experience for a Pulsar user. People don't do this
> > stuff (attribute=""), and we don't expect them to know this small detail
> > when authoring queries.
> >
> >
> > In theory, this should not be the concern of Pulsar at all - making the
> > aggregation since it can be done using TSDB like Prometheus recording rules
> > - but I do understand that emitting so many time series is inherently a
> > Pulsar issue. I accept this as a workaround for now.
> >
> > I hope the work researched here
> >  will
> > yield a better long-term solution.
> >
> >
> > Thanks,
> >
> >
> > Asaf
> >
> > On Mon, Oct 24, 2022 at 10:06 PM Michael Marshall 
> > wrote:
> >
> >> I think this feature is already available out of the box, as Penghui
> >> suggests. You can get metrics per broker summing them up over the
> >> `instance` label or the `kubernetes_pod_name` label. These labels are
> >> added not by the broker, but instead by the prometheus scrape
> >> definition.
> >>
> >> Also, you are correct that there are some metrics that are always 0, e.g.:
> >>
> >> pulsar_topics_count{cluster="my-cluster"} 0
> >>
> >> The motivation for those metrics is provided here [0], though I'm not
> >> sure it is good motivation.
> >>
> >> Thanks,
> >> Michael
> >>
> >> [0]
> >> https://github.com/apache/pulsar/blob/6d6665e296e6714801048dee1292e3a07abb5cc1/pulsar-broker/src/main/java/org/apache/pulsar/broker/stats/prometheus/NamespaceStatsAggregator.java#L306-L307
> >>
> >> On Sun, Oct 23, 2022 at 8:52 PM PengHui Li  wrote:
> >>>
> >>> I support the motivation.
> >>>
> >>> When I read the document of Prometheus
> >>> I see "A label with an empty label value is considered equivalent to a
> >>> label that does not exist." [0]
> >>> Can we just keep the value of the topic and namespace label empty?
> >>> And here is a blog that introduced how to deal with the empty label [1]
> >>>
> >>> If this can work. We don't need to add new indicator names.
> >>> Otherwise, we might need "pulsar_tenant_*" ,"pulsar_namespace_*",
> >>> "pulsar_cluster_*" in the future.
> >>>
> >>> [0] https://prometheus.io/docs/concepts/data_model/
> >>> [1]
> >>>
> >> https://medium.com/pareture/query-results-where-label-is-not-present-in-prometheus-e1176320575d
> >>>
> >>> Thanks,
> >>> Penghui
> >>>
> >>> On Sun, Oct 23, 2022 at 6:14 PM Asaf Mesika 
> >> wrote:
> >>>
>  One thing to note: You mentioned a PIP number but I'm not sure this is
> >> the
>  right process you follow here for that.
> 
> 
>  On Sun, Oct 23, 2022 at 1:12 PM Asaf Mesika 
> >> wrote:
> 
> > The suggestion makes sense to me as well. I've also reviewed your PR.
> >
> > On Sun, Oct 23, 2022 at 8:43 AM Haiting Jiang <
> >> jianghait...@gmail.com>
> > wrote:
> >
> >> +1
> >> Makes sense to me.
> >>
> >> Thanks,
> >> Haiting
> >>
> >> On Sat, Oct 22, 2022 at 3:59 AM yang yijun 
> >> wrote:
> >>>
> >>> Hi,I have a suggestion to improve the broker.
> >>>
> >>> For detailed improvement instructions, please refer to issue:
> >>> https://github.com/apache/pulsar/issues/18056
> >>>
> >>> For detailed source co

[GitHub] [pulsar] leizhiyuan added a comment to the discussion: sometimes broker send messages to consumer,but consumer can not receive

[GitBox]

GitHub user leizhiyuan added a comment to the discussion: sometimes broker send 
messages to consumer,but consumer can not receive

```
   Future writeAndFlushPromise =
cnx.getCommandSender().sendMessagesToConsumer(consumerId, 
topicName, subscription, partitionIdx,
entries, batchSizes, batchIndexesAcks, 
redeliveryTracker, epoch);
writeAndFlushPromise.addListener(status -> {
// only increment counters after the messages have been 
successfully written to the TCP/IP connection
if (status.isSuccess()) {
msgOut.recordMultipleEvents(totalMessages, totalBytes);
msgOutCounter.add(totalMessages);
bytesOutCounter.add(totalBytes);
chunkedMessageRate.recordMultipleEvents(totalChunkedMessages, 
0);
}
});
```

maybe this write fail

GitHub link: 
https://github.com/apache/pulsar/discussions/18377#discussioncomment-4083271


This is an automatically sent email for dev@pulsar.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@pulsar.apache.org

[GitHub] [pulsar] michaeljmarshall added a comment to the discussion: struggling with pulsar functions in kubernetes

[GitBox]

GitHub user michaeljmarshall added a comment to the discussion: struggling with 
pulsar functions in kubernetes

Thanks, that is helpful. I looked closer at the function worker integration in 
the helm chart, because you're enabling tls in the broker, the helm chart 
should be adding `tlsTrustCertsFilePath` to the broker's config map. I haven't 
verified, but I would expect that to get put into the function runtime. Can you 
share the error you're observing in the function?

GitHub link: 
https://github.com/apache/pulsar/discussions/18332#discussioncomment-4083293


This is an automatically sent email for dev@pulsar.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@pulsar.apache.org

[GitHub] [pulsar] TheDungNTU edited a discussion: [Pulsar JVM Dashboard] Zookeeper show No Data on direct memory

[GitBox]

GitHub user TheDungNTU edited a discussion: [Pulsar JVM Dashboard]  Zookeeper 
show No Data on direct memory


**Describe the bug**

To monitor a Pulsar cluster, I used grafana and in the Pulsar JVM dashboard, 
Zookeeper Direct Memory is show No Data. While other dashboards have data such 
as Bookie, Broker, Recovery.

I want to know why Zookeeper Metrics has no data for direct memory. I 
researched the document but did not find information about zookeeper metrics. 
Can you help me?

**Zookeeper**
![image](https://user-images.githubusercontent.com/56428954/200501163-e78fe91b-0539-4b8b-a445-a6a459cce168.png)

**Broker**
![image](https://user-images.githubusercontent.com/56428954/200501097-99692ea4-cba6-4b06-8264-94af463a14ed.png)

**Recovery**
![image](https://user-images.githubusercontent.com/56428954/200501235-b37c8d69-8ad0-4026-81d3-c8bcb9d33dbe.png)

**Grafana Overview**
![image](https://user-images.githubusercontent.com/56428954/200501319-143203e6-f690-4483-940b-11dc345fa2c7.png)









GitHub link: https://github.com/apache/pulsar/discussions/18382


This is an automatically sent email for dev@pulsar.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@pulsar.apache.org

[GitHub] [pulsar] TheDungNTU edited a discussion: [Pulsar JVM Dashboard] Zookeeper show No Data on column direct memory

[GitBox]

GitHub user TheDungNTU edited a discussion: [Pulsar JVM Dashboard]  Zookeeper 
show No Data on column direct memory


**Describe the bug**

To monitor a Pulsar cluster, I used grafana and in the Pulsar JVM dashboard, 
Zookeeper Direct Memory is show No Data. While other dashboards have data such 
as Bookie, Broker, Recovery.

I want to know why Zookeeper Metrics has no data for direct memory. I 
researched the document but did not find information about zookeeper metrics. 
Can you help me?

**Zookeeper**
![image](https://user-images.githubusercontent.com/56428954/200501163-e78fe91b-0539-4b8b-a445-a6a459cce168.png)

**Broker**
![image](https://user-images.githubusercontent.com/56428954/200501097-99692ea4-cba6-4b06-8264-94af463a14ed.png)

**Recovery**
![image](https://user-images.githubusercontent.com/56428954/200501235-b37c8d69-8ad0-4026-81d3-c8bcb9d33dbe.png)

**Grafana Overview**
![image](https://user-images.githubusercontent.com/56428954/200501319-143203e6-f690-4483-940b-11dc345fa2c7.png)









GitHub link: https://github.com/apache/pulsar/discussions/18382


This is an automatically sent email for dev@pulsar.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@pulsar.apache.org

[GitHub] [pulsar] TheDungNTU edited a discussion: [Pulsar JVM Dashboard] Zookeeper show No Data on column direct memory ?

[GitBox]

GitHub user TheDungNTU edited a discussion: [Pulsar JVM Dashboard]  Zookeeper 
show No Data on column direct memory ?


**Describe the bug**

To monitor a Pulsar cluster, I used grafana and in the Pulsar JVM dashboard, 
Zookeeper Direct Memory is show No Data. While other dashboards have data such 
as Bookie, Broker, Recovery.

I want to know why Zookeeper Metrics has no data for direct memory. I 
researched the document but did not find information about zookeeper metrics. 
Can you help me?

**Zookeeper**
![image](https://user-images.githubusercontent.com/56428954/200501163-e78fe91b-0539-4b8b-a445-a6a459cce168.png)

**Broker**
![image](https://user-images.githubusercontent.com/56428954/200501097-99692ea4-cba6-4b06-8264-94af463a14ed.png)

**Recovery**
![image](https://user-images.githubusercontent.com/56428954/200501235-b37c8d69-8ad0-4026-81d3-c8bcb9d33dbe.png)

**Grafana Overview**
![image](https://user-images.githubusercontent.com/56428954/200501319-143203e6-f690-4483-940b-11dc345fa2c7.png)









GitHub link: https://github.com/apache/pulsar/discussions/18382


This is an automatically sent email for dev@pulsar.apache.org.
To unsubscribe, please send an email to: dev-unsubscr...@pulsar.apache.org