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
