I haven't thought about it. I agree with Samisa in this case. Gokul's suggestion is valid. We can maintain a common service statistics stream as adding separate streams only confuse the user more but not that effective for the cost.
* Maninda Edirisooriya* Software Engineer *WSO2, Inc. *lean.enterprise.middleware. *Blog* : http://maninda.blogspot.com/ *Phone* : +94 777603226 On Wed, Aug 7, 2013 at 6:08 AM, Samisa Abeysinghe <[email protected]> wrote: > Though there could be different types of services, there has to be common > set of data items that we monitor across them - becuase, after all they are > all "services". > > You could give room to customize, but 80/20 rule would apply. > If the common set of data monitored and dashboard provided are useful, 80% > of the time, they would be used as they are. If not, it would be deemed not > user friendly. > If we make 20% the main use case, it will be naturally not user friendly > anyway. > > After all, what is really missing in this thread is what stats exactly are > we monitoring? And how will those be presented? What are the common cases? > Can we be a bit more concrete and composite please? > > > On Mon, Aug 5, 2013 at 11:57 AM, Maninda Edirisooriya <[email protected]>wrote: > >> Hi Gokul, >> >> My idea is that there may be different types of services in a single AS >> instance. So each type should be uniquely monitored in both activity-wise >> and statistics-wise. Thats why we need per-service monitoring facility. And >> yes, we may need to monitor statistics of all the services. Then we can >> simply union the column families related to all streams contain statistics >> data in Hive. If the user think that is too complicated he can point all >> the service statistics to a single column family or even to a single >> stream. To help that feature we can simply provide a default stream name >> and a version for all the service statistics configuration UIs in each. So >> if the user just want to publish to the default stream he can simply click >> the "Enable Service Statistics" button which will by default pointed to the >> default stream. If he wants to configure it differently, he can click a >> button like "Configure" and go to the configuration UI. >> >> * >> Maninda Edirisooriya* >> Software Engineer >> *WSO2, Inc. >> *lean.enterprise.middleware. >> >> *Blog* : http://maninda.blogspot.com/ >> *Phone* : +94 777603226 >> >> >> On Mon, Aug 5, 2013 at 11:14 AM, Balakrishnan Gokulakrishnan < >> [email protected]> wrote: >> >>> Hi Maninda, >>> >>> +1, I agree that it should be possible for certain apps/services to be >>> monitored in a different manner to others. But does this mean we are moving >>> away from our present model? What I mean to ask is how will the new model >>> address the situation where there is a requirement for an overall view on >>> request/response counts, faults, latency etc. My concern is that this might >>> make it more difficult on the BAM presentation side, having to deal with >>> data from a number of streams. May I suggest in addition to the revamped >>> model we also include a reduced version of the current model which will >>> allow capture of certain metrics which will enable the user to get a rough >>> overall view, while some features such as SOAP message dumping could be >>> moved to the per-service model? It's a question of balancing granularity I >>> believe. It will also help not having to set up statistics collection and >>> BAM server details for each and every service that gets deployed when there >>> is a need just to monitor the overall scenario. >>> >>> WDYT? >>> >>> Gokul. >>> >>> On 31 July 2013 18:00, Maninda Edirisooriya <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> At present Service Statistics and Activity Service data are configured >>>> to be published at a single global location. That means all the service >>>> statistics data should go to a single stream and all the activity data >>>> should also go to a single stream. >>>> >>>> But in practice the user may host different types of apps in an AS >>>> instance that are used for different purposes. So one set of apps may need >>>> to be monitored separately for statistics. (for e.g., sales application >>>> should be monitored in a different stream than the stock level controlling >>>> service statistics stream, as their fields are different and use cases are >>>> different) Similarly only some services need to be monitored for activities >>>> with full SOAP header and SOAP body. And each service should be able to >>>> maintain its own stream for keeping messages for logging purpose or >>>> activity monitoring purpose. And the services need to be monitored, should >>>> be configured individually. >>>> >>>> I think this requirement is same for the Web App monitoring. When web >>>> app activities are monitored not all the web app data are interested. If >>>> all web app data are going to the same column family with different stream >>>> versions still the large column family will effect the performance of the >>>> Hive query / Cassandra operation. So each web app should be possible to be >>>> monitored individually with its own stream. >>>> >>>> Therefore, other than configuring each monitoring configuration (i.e., >>>> service stats, activity service, web app stats) in a global location in >>>> WSO2 AS, it is better to configure each service / web app individually. We >>>> can include a button like the "Enable Service Statistics" button per >>>> service / web app and when selected, the monitoring configuration UI should >>>> appear in the same page or should direct to a configuration page unique for >>>> each service / web app. It is fine to maintain a global configuration page >>>> for BAM connection credentials and connection parameters, as every stream >>>> should is assumed to be going to the same BAM server. >>>> >>>> If we are planning to deal with multiple BAM servers with a single AS, >>>> the configuration page should be configured to different BAM servers each >>>> having a unique name. When a service / web app is going to be configured >>>> for publishing, the BAM server can be selected from the existing set of BAM >>>> servers configured in the global location. >>>> * >>>> Maninda Edirisooriya* >>>> Software Engineer >>>> *WSO2, Inc. >>>> *lean.enterprise.middleware. >>>> >>>> *Blog* : http://maninda.blogspot.com/ >>>> *Phone* : +94 777603226 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Balakrishnan Gokulakrishnan* >>> Software Engineer, >>> WSO2, Inc.; http://wso2.com >>> >>> Twitter: http://twitter.com/gokulbs >>> Mobile: +94775935789 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
