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

Reply via email to