On Thu, Jun 9, 2016 at 7:10 PM, Isuru Perera <[email protected]> wrote:
> Hi, > > On Thu, Jun 9, 2016 at 5:30 PM, Gihan Anuruddha <[email protected]> wrote: > >> Initially we thought about that. But then we decided to go with normal >> Mbean expose due following reasons. >> 1. To minimize depend on external repositories. >> > carbon-metrics is recommended for exposing these kind of values. DAS > already has carbon-metrics, so I don't think this is an issue. > Carbon-metrics currently budndle into DAS at the product p2 level. It's not using in carbon-analytics repo or carbon-event-processing repo level. As I mentioned in an earlier, these are DAS specific debug level Mbeans. We are using JDK provided methods to define Mbeans which only takes 5 lines. So that's why we don't want to add an extra repo dependency to carbon-analytics repo. 2. To list the analytics subdomain under org.wso2.carbon domain. >> > You can use a meaningful names metrics. You can use a common prefix > analytics metrics. > Please look attached image. That's how currently Mbean listed in carbon server. IMO we should follow that without creating a new domain. 3. I couldn't find a way to expose operations. >> > Instead of exposing operations, shall we try to use Gauges with some > formatted name with your parameters. For example, you can use following > names for getRemainingBufferCapacityInBytes(int tenantId) and > int getCurrentQueueSize(int tenantId). > > org.wso2.carbon.analytics.<tenant-id>.disruptor.remaining-buffer-size > org.wso2.carbon.analytics.<tenant-id>.disruptor.current-queue-size > > This will add more metrics, as there are gauges for every tenant. But I > think that should be fine. If you use Metrics, you can also get historical > data, which is very useful if you want to debug an issue happened in the > past (may be few mins ago). > We don't want to store any of these informations. If we want, then easily we can use our DAL. The main objective is to expose these Mbean to get current value to debug the situation. To achieve above suggested mbean pattern, then we have to add some more classes to monitor tenant creation and this will complicate our existing simple implementation. Also, this will add Mbeans unnecessarily to the system. > > Even the metrics library is available these kinds of requirements. > Therefore I think we must use it and try to avoid implementing separate > MBeans for any requirements that can be done with Metrics. > IMO, we don't have a use case to use metrics in here. > > Thanks! > > > >> Regards, >> Gihan >> >> On Thu, Jun 9, 2016 at 5:09 PM, Isuru Perera <[email protected]> wrote: >> >>> Any reason for not using Carbon Metrics? >>> >>> On Thu, Jun 9, 2016 at 5:00 PM, Gihan Anuruddha <[email protected]> wrote: >>> >>>> Hi All, >>>> >>>> We have added a couple of MBeans for DAS to expose some debug level >>>> information. These Mbeans will list under org.wso2.carbon.analytics >>>> subdomain. >>>> >>>> EVENT_COUNTER [int getCurrentCount()]- This will count all the events >>>> that received to DAS regardless of steam or tenant. We want to add this per >>>> tenant per stream. But in order to do that we need to add a Map to >>>> event persistence path and that might add extra delay to the event saving >>>> critical path. Because of that we thought of adding only a counter ( >>>> AtomicLong). >>>> >>>> RECEIVER_REMAINING_QUEUE_BUFFER_SIZE_IN_BYTES >>>> [ >>>> long getRemainingBufferCapacityInBytes(int tenantId), >>>> int getCurrentQueueSize(int tenantId)] >>>> - You can use this Mbean to get remaining buffer size in disruptor and >>>> current queue size. >>>> >>>> LAST_PROCESSED_TIMESTAMP[long getLastProcessedTimestamp(int tenantId, >>>> String id, boolean primary)] >>>> - This will return last saved incremental processed timestamp for >>>> given spark table. >>>> >>>> ANALYTICS_SCRIPT_LAST_EXECUTION_START_TIME[long >>>> getScriptLastExecutionStartTime(int tenantId, String scriptName)] >>>> - This will return latest execution start time of the given Spark >>>> script. >>>> >>>> Please let me know any other information that you think better expose >>>> through Mbeans. >>>> >>>> Regards, >>>> Gihan >>>> >>>> -- >>>> W.G. Gihan Anuruddha >>>> Senior Software Engineer | WSO2, Inc. >>>> M: +94772272595 >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> W.G. Gihan Anuruddha >> Senior Software Engineer | WSO2, Inc. >> M: +94772272595 >> >> _______________________________________________ >> 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 > > -- W.G. Gihan Anuruddha Senior Software Engineer | WSO2, Inc. M: +94772272595
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
