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 <[email protected]> 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 <[email protected]>
> 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.
>>
>> [1] http://metrics.dropwizard.io/3.1.0/getting-started/
>>
>> Regards,
>> Asitha
>>
>>
>> On Wed, Jan 24, 2018 at 6:42 PM, Gihan Anuruddha <[email protected]> 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 <[email protected]>
>>> 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?
>>>> [1]. http://isuru-perera.blogspot.com/2014/11/java-performance-mo
>>>> nitoring-libraries.html
>>>> [2]. https://github.com/dropwizard/metrics
>>>>
>>>> --
>>>> Asanka Abeyweera
>>>> Associate Technical Lead
>>>> WSO2 Inc.
>>>>
>>>> Phone: +94 712228648 <071%20222%208648>
>>>> Blog: a5anka.github.io
>>>>
>>>> <https://wso2.com/signature>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> W.G. Gihan Anuruddha
>>> Associate Technical Lead | WSO2, Inc.
>>> M: +94772272595
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> *Asitha Nanayakkara* <http://asitha.github.io/>
>> Associate Technical Lead
>> WSO2, Inc. <http://wso2.com/>
>> Mob: +94 77 853 0682 <+94%2077%20853%200682>
>> [image: https://wso2.com/signature] <https://wso2.com/signature>
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Pamod Sylvester *
>
> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
> cell: +94 77 7779495 <+94%2077%20777%209495>
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: +94 712228648
Blog: a5anka.github.io

<https://wso2.com/signature>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to