Hi, As Ramith mentioned, we can use "source" in metrics configuration to identify the node. However, we will have to keep the queue/topic name in the metric name. I believe we can split it in CEP and store the queue/name separately.
Let's define a standard format the metric names and we can use that format for splitting the name. Suho/Anjana, is this approach okay? In current Metrics version, there is no way to support additional attributes for metrics. The next version of Dropwizard Metrics will support adding tags. However there is no release planned. I don't think it will be released anytime soon. On Thu, May 26, 2016 at 2:28 PM, Ramith Jayasinghe <[email protected]> wrote: > I suppose node id can be pre-configured and remains constant through > the run-time. Therefore, we don't need to pass it everywhere. But we > need to pass queue/topic/ etc. > > On Thu, May 26, 2016 at 2:21 PM, 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 > > > > > > -- > Ramith Jayasinghe > Technical Lead > WSO2 Inc., http://wso2.com > lean.enterprise.middleware > > E: [email protected] > P: +94 772534930 > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Isuru Perera Associate Technical Lead | WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware about.me/chrishantha Contact: +IsuruPereraWSO2 <https://www.google.com/+IsuruPereraWSO2/about>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
