On Mon, Jul 15, 2013 at 5:04 PM, Samisa Abeysinghe <[email protected]> wrote:

> OK, got it, same stats to ST from tenants.
>

Yes, we need to modify the component so that in case of a *live deployment
(EnableMetering & IsCloudDeployment props in carbon.xml enabled), we
publish stats to ST space no mater what the tenant's local config is.

Another minor issue I see in the current imply is that the publisher
conifgs has to be set using the UI, this model is not very dev-ops friendly
and also is not ideal when managing conifgs via puppet, need to fix that
too.

>
>
> On Mon, Jul 15, 2013 at 4:59 PM, Amila Maha Arachchi <[email protected]>wrote:
>
>>
>>
>>
>> On Mon, Jul 15, 2013 at 4:39 PM, Samisa Abeysinghe <[email protected]>wrote:
>>
>>> So we are making the AS WebApp BAM toolkit tenant aware?
>>>
>>
>> No. Current AS WebApp stat publishing component publishes data to
>> tenant's keyspace (it is tenant aware). We need to make it possible to
>> publish to ST's keyspace regardless of whether the tenant wants to
>> publish stats or not (because the aPaaS vendor can only access his i.e.
>> ST keyspace and we want all the stats with us). This is what we do in
>> SLive (publishing to ST's keyspace).
>>
>>
>>
>>>
>>>
>>> On Mon, Jul 15, 2013 at 11:47 AM, Shariq Muhammed <[email protected]>wrote:
>>>
>>>> Hi Samisa,
>>>>
>>>> On Mon, Jul 15, 2013 at 8:12 AM, Samisa Abeysinghe <[email protected]>wrote:
>>>>
>>>>> Are we not re-using what we already have in AS? What are we inventing
>>>>> here?
>>>>>
>>>>
>>>> Yes the plan is to reuse what's been done in AS. However there are some
>>>> changes we need to do to support this in aPaaS space, for example in
>>>> AS tenant's are allowed to publish to an event stream / CF of their choice,
>>>> but in the *live system all stats should be published to a common ST
>>>> space so that we / provider can centrally manage / analyze the statistics
>>>> etc. So we need to incorporate this to the existing component ...
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 12, 2013 at 12:27 PM, Geeth Munasinghe <[email protected]>wrote:
>>>>>
>>>>>>
>>>>>> On Fri, Jul 12, 2013 at 11:26 AM, Shariq Muhammed <[email protected]>wrote:
>>>>>>
>>>>>>> Hi folks,
>>>>>>>
>>>>>>> I was looking into capturing webapp statistics for aPaaS work, and
>>>>>>> came across the webapp.stat.publisher component written by the AS
>>>>>>> team. It uses a tomcat valve [1] and publish a whole heap of stats, the
>>>>>>> list can be found in the class at [2].
>>>>>>>
>>>>>>> The new stat component captures way more data than the usage
>>>>>>> components we had before, only missing piece as of now is the
>>>>>>> request/response bandwidth. What we've done now is to patch tomcat
>>>>>>> RequestInfo.java class, if we can somehow capture the bandwidth also in 
>>>>>>> the
>>>>>>> valve we can get rid of tomcat.patch, tomcat.fragment.dummy bundles
>>>>>>> and a few classes from tomcat.ext bundle in the kernel.
>>>>>>>
>>>>>>> By looking into the tomcat code, it seems we can get the coyote.Request
>>>>>>> (object in RequestInfo) within the valve, but the bandwidth values
>>>>>>> returned are 0.
>>>>>>>
>>>>>>> request.getCoyoteRequest().getBytesRead(); // => 0
>>>>>>> request.getCoyoteRequest().getResponse().getContentWritten() // => 0
>>>>>>>
>>>>>>> But the correct values are returned in the patched RequestInfoclass, so 
>>>>>>> I am still trying to figure out what could be the issue. If we
>>>>>>> can capture this value also at the value we can publish all properties 
>>>>>>> from
>>>>>>> one place.
>>>>>>>
>>>>>>> So first of all I would like to know if it's fine to go ahead with
>>>>>>> this implementation and improve it to cater aPaaS requirements or
>>>>>>> do we need a separate bundle (would be a fork of this one in the end). 
>>>>>>> IMO
>>>>>>> we should use this component and improve it since there is no point 
>>>>>>> having
>>>>>>> 2 bundles doing the same thing.
>>>>>>>
>>>>>>> One concern, the component is designed for per tenant publishing,
>>>>>>> and the tenant chooses whether or not to publish and where to publish. 
>>>>>>> If
>>>>>>> we are to capture stats centrally we need to publish to a ST CF
>>>>>>> regardless of tenant enable or disable statistics, can be done using a
>>>>>>> config option.
>>>>>>>
>>>>>>> @Geeth - Noticed that even after a tenant enable stat publishing
>>>>>>> for webapps, we need to again enable publishing per webapp. IMO the
>>>>>>> model should be that if a tenant enable publishing, stats for all 
>>>>>>> deployed
>>>>>>> webapps should be published and tenant should be given the option
>>>>>>> to disable stats selectively.
>>>>>>>
>>>>>>
>>>>>> Currently we are giving two options for user to enable publishing.
>>>>>> User either can put context param in web.xml to enable statistic or
>>>>>> enable from ui. What we thought was user should be able to enable
>>>>>> stats publishing per webapp rather than publishing for all 
>>>>>> webappsdeployed.
>>>>>>
>>>>>>>
>>>>>>> Thoughts ... ?!
>>>>>>>
>>>>>>> [1] -
>>>>>>> https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/data-agents/org.wso2.carbon.bam.webapp.stat.publisher/src/main/java/org/wso2/carbon/bam/webapp/stat/publisher/WebAppStatisticPublisherValve.java
>>>>>>> [2] -
>>>>>>> https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/data-agents/org.wso2.carbon.bam.webapp.stat.publisher/src/main/java/org/wso2/carbon/bam/webapp/stat/publisher/data/WebappStatEventData.java
>>>>>>>
>>>>>>> --
>>>>>>> Thanks,
>>>>>>> Shariq.
>>>>>>> Phone: +94 777 202 225
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks,
>>>> Shariq.
>>>> Phone: +94 777 202 225
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> *Amila Maharachchi*
>> Senior Technical Lead
>> WSO2, Inc.; http://wso2.com
>>
>> Blog: http://maharachchi.blogspot.com
>> Mobile: +94719371446
>>
>>
>> _______________________________________________
>> 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
>
>


-- 
Thanks,
Shariq.
Phone: +94 777 202 225
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to