[MB4] Exposing messaging metrics

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[MB4] Exposing messaging metrics

Asanka Abeyweera
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Exposing messaging metrics

Asitha Nanayakkara
Hi Asanaka,

Shall we add the number of canceled out database operations under database as a well?

Regards,
Asitha

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?


--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: <a href="tel:+94%2071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Associate Technical Lead
Mob: +94 77 853 0682
https://wso2.com/signature


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Exposing messaging metrics

Hasitha Hiranya
In reply to this post by Asanka Abeyweera
Hi Asanka,

I think we also need to provide

1. publishing message rate by a publisher (publisher channel)
2. subscribing message rate by a consumer (consumer channel)
3. acknowledgement rate by a consumer  (consumer channel)

These stats are important when come to fine-tuning MB to deliver max performance. 

Thanks

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?




--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Exposing messaging metrics

Isuru Perera
Hi Asanka,

+1 for Using Dropwizard Metrics. I believe you can still continue to use Carbon Metrics [1], which is a wrapper for Dropwizard Metrics, including OSGi support, standard Carbon YAML configuration, Easy configuration support for multiple reporters, Support for dynamically enable/disable metrics.

[1] https://github.com/wso2/carbon-metrics

On Mon, Jan 22, 2018 at 10:21 AM, Hasitha Hiranya <[hidden email]> wrote:
Hi Asanka,

I think we also need to provide

1. publishing message rate by a publisher (publisher channel)
2. subscribing message rate by a consumer (consumer channel)
3. acknowledgement rate by a consumer  (consumer channel)

These stats are important when come to fine-tuning MB to deliver max performance. 

Thanks

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?


--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com




--
Isuru Perera
Technical Lead | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

about.me/chrishantha

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Exposing messaging metrics

Asanka Abeyweera
Hi Isuru,

Can we use carbon-metrics in a nonOSGI environment?

On Mon, Jan 22, 2018 at 11:38 AM, Isuru Perera <[hidden email]> wrote:
Hi Asanka,

+1 for Using Dropwizard Metrics. I believe you can still continue to use Carbon Metrics [1], which is a wrapper for Dropwizard Metrics, including OSGi support, standard Carbon YAML configuration, Easy configuration support for multiple reporters, Support for dynamically enable/disable metrics.

[1] https://github.com/wso2/carbon-metrics

On Mon, Jan 22, 2018 at 10:21 AM, Hasitha Hiranya <[hidden email]> wrote:
Hi Asanka,

I think we also need to provide

1. publishing message rate by a publisher (publisher channel)
2. subscribing message rate by a consumer (consumer channel)
3. acknowledgement rate by a consumer  (consumer channel)

These stats are important when come to fine-tuning MB to deliver max performance. 

Thanks

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?


--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com




--
Isuru Perera
Technical Lead | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

about.me/chrishantha



--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: +94 712228648



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Exposing messaging metrics

Isuru Perera
Hi,

Yes, it can be used in non-OSGi environment. Basically, you can create the Metrics Service and manage it in your code.

On Mon, Jan 22, 2018 at 11:44 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi Isuru,

Can we use carbon-metrics in a nonOSGI environment?

On Mon, Jan 22, 2018 at 11:38 AM, Isuru Perera <[hidden email]> wrote:
Hi Asanka,

+1 for Using Dropwizard Metrics. I believe you can still continue to use Carbon Metrics [1], which is a wrapper for Dropwizard Metrics, including OSGi support, standard Carbon YAML configuration, Easy configuration support for multiple reporters, Support for dynamically enable/disable metrics.

[1] https://github.com/wso2/carbon-metrics

On Mon, Jan 22, 2018 at 10:21 AM, Hasitha Hiranya <[hidden email]> wrote:
Hi Asanka,

I think we also need to provide

1. publishing message rate by a publisher (publisher channel)
2. subscribing message rate by a consumer (consumer channel)
3. acknowledgement rate by a consumer  (consumer channel)

These stats are important when come to fine-tuning MB to deliver max performance. 

Thanks

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?


--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Hasitha Abeykoon
Associate Technical LeadWSO2, Inc.; http://wso2.com




--
Isuru Perera
Technical Lead | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

about.me/chrishantha



--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648





--
Isuru Perera
Technical Lead | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

about.me/chrishantha

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Exposing messaging metrics

Gihan Anuruddha
In reply to this post by Asanka Abeyweera
Hi Asanka,

Do you have a plan to expose above information through REST API? 

Regards,
Gihan

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?


--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
W.G. Gihan Anuruddha
Associate Technical Lead | WSO2, Inc.

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Exposing messaging metrics

Asitha Nanayakkara
Hi Gihan,

We might be able to expose the metrics over HTTP using their build in http-reporter. See reporting via HTTP in [1]
Currently, we are using metrics version 2.3.7 coming from the carbon-metrics component. Not sure whether this feature is supported in that version.


On Wed, Jan 24, 2018 at 6:42 PM, Gihan Anuruddha <[hidden email]> wrote:
Hi Asanka,

Do you have a plan to expose above information through REST API? 

Regards,
Gihan

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?


--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
W.G. Gihan Anuruddha
Associate Technical Lead | WSO2, Inc.

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Associate Technical Lead
Mob: <a href="tel:+94%2077%20853%200682" value="+94778530682" target="_blank">+94 77 853 0682
https://wso2.com/signature


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Exposing messaging metrics

Pamod Sylvester
What would look better is to have a co-relation between the subscription channel vs the number of messages dispatched.

For durable topics this would be inherent. For other message domains such as queues and shared durable subscriptions this would be an important stat 

Also with these stats can we offer the capability to identify slow subscriptions? this will also bring value. For instance if a particular queue has a slow subscriber and if that could be identified from the stats, this could ring an alarm to rectify the potential bottleneck. 

Can we also show in general the round trip latency avg per queue/topic ? starting from the time the message arrived at the broker to the time it was delivered to the subscription. 

Thanks,
Pamod

On Thu, Jan 25, 2018 at 8:36 AM, Asitha Nanayakkara <[hidden email]> wrote:
Hi Gihan,

We might be able to expose the metrics over HTTP using their build in http-reporter. See reporting via HTTP in [1]
Currently, we are using metrics version 2.3.7 coming from the carbon-metrics component. Not sure whether this feature is supported in that version.


On Wed, Jan 24, 2018 at 6:42 PM, Gihan Anuruddha <[hidden email]> wrote:
Hi Asanka,

Do you have a plan to expose above information through REST API? 

Regards,
Gihan

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?


--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
W.G. Gihan Anuruddha
Associate Technical Lead | WSO2, Inc.

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Associate Technical Lead
Mob: <a href="tel:+94%2077%20853%200682" value="+94778530682" target="_blank">+94 77 853 0682
https://wso2.com/signature


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: +94 77 7779495

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [MB4] Exposing messaging metrics

Asanka Abeyweera
Hi Pamod,

We have currently implemented only the static messaging metrics which are mentioned below.
  • Total number of messages held in memory
  • Total number of message published
  • Global message publishing rate
  • Total number of message acknowledgments
  • Global message acknowledging rate
  • Total number of message rejections
  • Global message rejection rate
  • Total number of open AMQP channels
  • Total number of open AMQP connection
  • Total number of active consumers
  • Database message read latency
  • Database message read rate
  • Database message read count
  • Database message write latency
  • Database message write rate
  • Database message write count
  • Database message delete latency
  • Database message delete rate
  • Database message delete count
The dynamic parameters like messages dispatched for consumer, we will implement after evaluating the metrics library support and performance impact on the broker. In the curent version of the metrics we have to define a static metric even for the dynamic metrics. But in metrics version 5.x, they have tagging support which perfectly matches our requirement. But we will evaluate and see what we can do with metrics 3.x. Following is the dynamic messaging metrics we have in mind.
  • Number of messages held in memory for a given queue
  • Message publish count/rate for a given routing key
  • Message acknowledge count/rate for a given queue
  • Message publish count/rate for a channel
  • Message acknowledge count/rate for a given channel/consumer
  • Latency introduced in inbound pipeline for a message
  • Latency introduced in data persistence for a message
  • Number of canceled out database operations due to caching layer
I think we can identify slow subscribers from that information. I think showing the complete round trip time or latency is not practical due to the queueing effect. But we can show the latency we are introducing in different stages which we can use to get an idea about the total latency. WDYT?


On Sun, Jan 28, 2018 at 7:49 PM, Pamod Sylvester <[hidden email]> wrote:
What would look better is to have a co-relation between the subscription channel vs the number of messages dispatched.

For durable topics this would be inherent. For other message domains such as queues and shared durable subscriptions this would be an important stat 

Also with these stats can we offer the capability to identify slow subscriptions? this will also bring value. For instance if a particular queue has a slow subscriber and if that could be identified from the stats, this could ring an alarm to rectify the potential bottleneck. 

Can we also show in general the round trip latency avg per queue/topic ? starting from the time the message arrived at the broker to the time it was delivered to the subscription. 

Thanks,
Pamod

On Thu, Jan 25, 2018 at 8:36 AM, Asitha Nanayakkara <[hidden email]> wrote:
Hi Gihan,

We might be able to expose the metrics over HTTP using their build in http-reporter. See reporting via HTTP in [1]
Currently, we are using metrics version 2.3.7 coming from the carbon-metrics component. Not sure whether this feature is supported in that version.


On Wed, Jan 24, 2018 at 6:42 PM, Gihan Anuruddha <[hidden email]> wrote:
Hi Asanka,

Do you have a plan to expose above information through REST API? 

Regards,
Gihan

On Mon, Jan 22, 2018 at 10:09 AM, Asanka Abeyweera <[hidden email]> wrote:
Hi all,

We need to expose messaging metrics to provide information about the broker state. We are planning to expose following messaging metrics.
  • Queue
    • Number of messages
    • Number of messages in a specific queue*
    • Number of subscribers for a specific queue*
    • Total messages published (enqueued)
    • Number of messages published to a queue*
    • Total messages acknowledged (dequeued)
    • Number of messages acknowledged in a queue*
  • Exchanges
    • Total messages published
    • Number of messages published with a certain routing key*
  • Subscriptions
    • Total subscribers
    • Number of pending messages*
    • Total messages fetched*
    • Total messages acknowledged*
    • Total messages rejected*
  • Database
    • Read latency
    • Write latency
    • Delete latency
    • Read throughput
    • Write throughput
    • Delete throughput
  • Broker
    • Messages in inbound netty pipeline
    • Messages in data cache layer

* - We will have to evaluate calculating dynamic metrics since it can depend on the library support and performance impact on the broker.

Please suggest other messaging metrics we need to expose.

The metric calculation should not have a considerable negative impact on the broker performance. We are planning to use the Metrics library [1] since it is known to have a low footprint on the performance.

WDYT?


--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: <a href="tel:071%20222%208648" value="+94712228648" target="_blank">+94 712228648



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
W.G. Gihan Anuruddha
Associate Technical Lead | WSO2, Inc.

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Associate Technical Lead
Mob: <a href="tel:+94%2077%20853%200682" value="+94778530682" target="_blank">+94 77 853 0682
https://wso2.com/signature


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Pamod Sylvester 
WSO2 Inc.; http://wso2.com
cell: <a href="tel:+94%2077%20777%209495" value="+94777779495" target="_blank">+94 77 7779495

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: +94 712228648



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture