Hi Shammi, As you said ESB and MB analytics developing as features where we build analytics product with DAS features. Artifacts (dashboard design, gadgets, event receivers, execution plan) bundle as car file in the feature. Installation of feature copies necessary artifacts to the relevant location. So end user should be able to install both features into single DAS instance.
Cheers! On Thu, Jun 2, 2016 at 2:59 AM, Shammi Jayasinghe <[email protected]> wrote: > Hi , > > When it comes to providing a solution for an end user, Most of the cases > we are using MB with another product such as ESB. Since ESB also comes with > esb analytics, at the end User should be able to have ESB analytics and MB > analytics in the same DAS dashboard. Then he will be able to get the max > output of this feature like if there is a delay in the flow, he will be > able to pinpoint it. > > Have we thought about that capability and is there any special design we > should have to be capable for that ? > > Thanks > shammi > > On Thu, May 26, 2016 at 1:51 AM, Indika Sampath <[email protected]> wrote: > >> Hi All, >> >> This is an open discussion about message broker analytics for the carbon >> 5 based message broker release and explain design of analytics story. >> >> *Existing design* >> Message broker 3.0.0 and 3.1.0 has couple of stats publishing using >> carbon-metrics library. These stats can be found in Management console -> >> Monitor -> Messaging Metrics. Below are those stats. >> >> - Number of messages in inbound/outbound disruptor >> - Total publisher/subscribers/channels >> - Received and sent message rates >> - DB read/write time and rate >> >> These information are specific to node itself. If I explain it more, >> let's say there are two nodes in the cluster, user has to log into each >> node and look into details of that particular node. There is no aggregated >> view or navigation. >> >> *Propose design* >> Message broker analytic is going to handle as separate distribution >> (analytics-mb with necessary WSO2 DAS features) according to the platform >> story. Dash broad organized with different filters such as cluster, nodes, >> queues, topics and time range. Below general view going to be present in >> each filter level. Ex: total connections of cluster/ total connection of >> given node/ total connection of given queue or topic etc. >> >> - Total connections >> - Total messages >> - Message size distribution >> - Total publishers/subscribers >> - Enqueue messages >> - Dequeue messages >> - Total Message rejection/ Messages moved to DLC (error rates can be >> calculate) >> - Inbound/outbound throughput >> - Inbound/outbound latency >> - DB read/write time and rate >> >> Our plan is to trigger alerts based on these data with WSO2 CEP and ML in >> later phase. >> >> We are planing to use same carbon-metrics library to publish data to >> analytics-mb. DAS data publisher capability is added to carbon-metrics >> 2.0.0. But there is limitation identified in carbon-metrics 2.0.0. It can >> use to publish data with exposed API such as meter, counter, timer, >> histogram and gauges. These data always distinguished by the name field. >> >> public static Meter meter(String name, Level level, Level... levels) >> public static Counter counter(String name, Level level, Level... levels) >> public static Timer timer(String name, Level level) >> public static Histogram histogram(String name, Level level, Level... >> levels) >> public static <T> void gauge(String name, Level level, Gauge<T> gauge) >> >> But for us, it is essential to have more than one field to query >> different filters in DAS. For an example: query total connections of >> cluster/ query total connection of given node/ query total connections for >> given queue/topic. We should always need to pass node and queue/topic >> details when publishing data to DAS which make filtering more easier. >> >> We would like to suggest to do necessary changes in carbon-metric 2.0.0 >> implementation to cater for above requirement as well. >> >> Your thoughts are welcome. >> >> Cheers! >> >> -- >> Indika Sampath >> Senior Software Engineer >> WSO2 Inc. >> http://wso2.com >> >> Phone: +94 716 424 744 >> Blog: http://indikasampath.blogspot.com/ >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Best Regards, > > * Shammi Jayasinghe* > > > *Technical Lead* > *WSO2, Inc.* > *+1-812-391-7730 <%2B1-812-391-7730>* > *+1-812-327-3505 <%2B1-812-327-3505>* > > *http://shammijayasinghe.blogspot.com > <http://shammijayasinghe.blogspot.com>* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Indika Sampath Senior Software Engineer WSO2 Inc. http://wso2.com Phone: +94 716 424 744 Blog: http://indikasampath.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
