Hi Isuru,
Is it possible to turn on/off metrics using a runtime property? Correct me
if I'm wrong, using a system property for metrics you have to restart the
server for metrics to be turned on/off?
-Chintana
On Tue, Jan 27, 2015 at 1:42 AM, Isuru Perera <[email protected]> wrote:
> Hi Paul,
>
> Thanks for the suggestions.
>
> I just had a quick chat with Johann. Since there is some more time for
> next IS release, we can start integrating metrics with IS. I'll set up a
> meeting with IS team.
>
> As you mentioned, it would be great if we can integrate Metrics to ESB. As
> I know, ESB Team is in final stages for 4.9.0 release and I think we will
> have to integrate metrics after ESB 4.9.0 release. Kasun, WDYT?
>
> Thanks!
>
> Best Regards,
>
> On Fri, Jan 23, 2015 at 12:34 PM, Paul Fremantle <[email protected]> wrote:
>
>> I suggest one of the following:
>>
>> * The ESB already has very advanced metrics. So a good test would be to
>> see if we can get all of those easily with the new component. That would
>> quickly get the new component up to a high quality.
>>
>> * The Identity Server market is becoming much more performance sensitive,
>> so metrics in IS would be really valuable.
>>
>> Paul
>>
>> On 23 January 2015 at 06:59, Isuru Perera <[email protected]> wrote:
>>
>>> Hi all,
>>>
>>> This is just a quick update on Metrics integration.
>>>
>>> - We decided to use a separate repository for metrics [1]. The main
>>> reason is that we want to integrate Metrics to upcoming releases and it
>>> will take a longer time for products to use a new Carbon Kernel version.
>>> - Developed a new JDBC Reporter for Metrics [2]
>>> - Now I'm working on a new UI for Metrics visualization. I
>>> experimented with other tools and we decided to have a lightweight UI,
>>> which can be integrated to WSO2 Products. I'm planning to use the data
>>> from
>>> a database and that's the main reason to develop a new JDBC reporter.
>>> I'll
>>> share the details of the UI later.
>>>
>>> Since the core part for Metrics API is ready, we can start integrating
>>> to the products.
>>>
>>> Srinath, please let me know which product to start with. Then we can
>>> discuss with relevant product team.
>>>
>>> Thanks!
>>>
>>> Best Regards,
>>>
>>> [1] https://github.com/wso2/carbon-metrics
>>>
>>> [2]
>>> https://github.com/wso2/carbon-metrics/blob/master/components/org.wso2.carbon.metrics.jdbc.reporter/src/main/java/org/wso2/carbon/metrics/reporter/JDBCReporter.java
>>>
>>> On Tue, Dec 23, 2014 at 3:35 PM, Isuru Perera <[email protected]> wrote:
>>>
>>>> Hi Sameera,
>>>>
>>>> I sent a PR to carbon4-kernel repository [1]. Could you please review
>>>> and merge it? I created CARBON-15115 [2] for that.
>>>>
>>>> Thanks!
>>>>
>>>> [1] https://github.com/wso2/carbon4-kernel/pull/125
>>>> [2] https://wso2.org/jira/browse/CARBON-15115
>>>>
>>>> On Wed, Dec 3, 2014 at 1:53 PM, Ramith Jayasinghe <[email protected]>
>>>> wrote:
>>>>
>>>>> Yep. This needs to be evaluated on loaded environments.
>>>>>
>>>>> On Wed, Dec 3, 2014 at 1:39 PM, Isuru Perera <[email protected]> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have committed what I did so far to the WSO2 SVN scratch area [1].
>>>>>>
>>>>>> There are two components.
>>>>>>
>>>>>> 1. org.wso2.carbon.metrics.manager - Contains the WSO2 Metrics
>>>>>> API, which will be used in the WSO2 platform.
>>>>>> 2. org.wso2.carbon.metrics.impl - The implementation of Metric
>>>>>> Service, which will internally use the Metrics Java Library [2].
>>>>>>
>>>>>> The main reason for having our own API is to introduce the support
>>>>>> for different metrics levels. This will also make sure that we are not
>>>>>> tightly coupled with Metrics Java library.
>>>>>>
>>>>>> The org.wso2.carbon.metrics.manager.MetricManager [3] class has the
>>>>>> main API. This class is similar to the Metrics' MetricRegistry class [4]
>>>>>> and I have taken the helper methods to generate names etc.
>>>>>>
>>>>>> Yesterday, I organized a code review and following are the notes:
>>>>>>
>>>>>> Participants: Azeez, Sameera, Ramith.
>>>>>>
>>>>>> Code review was based on revision 210170 [5]
>>>>>>
>>>>>> - Azeez mentioned that having a global configuration for Level
>>>>>> [6] might not be useful. Since we allow to create different Metrics
>>>>>> with
>>>>>> different levels, we need to have a way to specify level for each
>>>>>> Metric
>>>>>> similar to Log4J. Configurations should be decided initially rather
>>>>>> than
>>>>>> introducing later.
>>>>>> - Ramith asked whether we can support annotations. Metrics [2]
>>>>>> support annotations for Spring with Spring's AOP support. Besides, the
>>>>>> annotation will help to measure up to method level only. It was
>>>>>> decided
>>>>>> that we can use the APIs directly as we can use the given APIs
>>>>>> whenever we
>>>>>> need to measure.
>>>>>> - The use of ConcurrentHashMap need to be reevaluated. The
>>>>>> MetricManager also uses a ConcurrentHashMap similar to MetricRegistry
>>>>>> to
>>>>>> avoid duplicate Metric objects. We must test the Metrics API in high
>>>>>> concurrent scenarios.
>>>>>> - We decided to integrate the metrics components to Carbon Kernel
>>>>>> first. I will start integrating the metrics to Carbon Kernel 4.4 in a
>>>>>> different branch.
>>>>>> - When logging, isErrorEnabled may not be necessary [7], but it's
>>>>>> okay to have it.
>>>>>>
>>>>>> Azeez, Sameera, Ramith, please add if I missed anything.
>>>>>>
>>>>>> In addition to the code review, I had a chat with Srinath yesterday
>>>>>> morning.
>>>>>>
>>>>>> We discussed that we must have a UI for Metrics. I will share the
>>>>>> details on that later.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> [1] https://svn.wso2.org/repos/wso2/scratch/metrics
>>>>>> [2] https://dropwizard.github.io/metrics
>>>>>> [3]
>>>>>> https://svn.wso2.org/repos/wso2/scratch/metrics/components/org.wso2.carbon.metrics.manager/src/main/java/org/wso2/carbon/metrics/manager/MetricManager.java
>>>>>> [4]
>>>>>> https://github.com/dropwizard/metrics/blob/master/metrics-core/src/main/java/com/codahale/metrics/MetricRegistry.java
>>>>>> [5] http://wso2.org/svn/browse/wso2?view=revision&revision=210170
>>>>>> [6]
>>>>>> http://wso2.org/svn/browse/wso2/scratch/metrics/components/org.wso2.carbon.metrics.impl/src/test/resources/metrics.xml?view=markup&pathrev=210170
>>>>>> [7]
>>>>>> http://wso2.org/svn/browse/wso2/scratch/metrics/components/org.wso2.carbon.metrics.manager/src/main/java/org/wso2/carbon/metrics/manager/internal/MetricManagerComponent.java?view=markup&pathrev=210170
>>>>>>
>>>>>> On Tue, Nov 18, 2014 at 12:11 PM, Isuru Perera <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Me & Srinath discussed a bit more on implementation. Following are
>>>>>>> the notes.
>>>>>>>
>>>>>>> - We need to have different levels for each metric similar to
>>>>>>> Log4J levels. The API for metric will have a way to specify the
>>>>>>> level.
>>>>>>> - There should be a way to view historical data. By default, we
>>>>>>> can use a log file.
>>>>>>> - There should be a configuration file for metrics. The enable
>>>>>>> option will be part of the configuration file. But it can be
>>>>>>> overridden by
>>>>>>> a System property.
>>>>>>>
>>>>>>> Srinath,
>>>>>>>
>>>>>>> Please add if I missed anything. Also regarding the reporting
>>>>>>> options, the metrics provides support for Ganglia & Graphite [1]. The
>>>>>>> in-built support for HTTP reporting might not be directly useful for us
>>>>>>> [2]. I will check on these and see how we can get the data.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> [1]
>>>>>>> https://dropwizard.github.io/metrics/3.1.0/getting-started/#other-reporting
>>>>>>> [2]
>>>>>>> https://dropwizard.github.io/metrics/3.1.0/manual/servlets/#manual-servlets
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Nov 18, 2014 at 7:53 AM, Srinath Perera <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Look good Isuru!!
>>>>>>>>
>>>>>>>> On Thu, Nov 13, 2014 at 6:58 PM, Isuru Perera <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I played with following performance libraries.
>>>>>>>>>
>>>>>>>>> - Metrics
>>>>>>>>> - Parfait
>>>>>>>>> - JAMon
>>>>>>>>> - Java Simon
>>>>>>>>> - Perf4J
>>>>>>>>>
>>>>>>>>> I did a simple comparison and blogged [1].
>>>>>>>>>
>>>>>>>>> As Srinath mentioned, the Metrics library is more suitable for
>>>>>>>>> this proposal.
>>>>>>>>>
>>>>>>>>> It supports various measuring instruments like Meters, Counters,
>>>>>>>>> Histograms, Timers etc.
>>>>>>>>>
>>>>>>>>> Metrics supports JMX reporting and we should be able to write our
>>>>>>>>> own reporting implementations easily. We can use a reporting
>>>>>>>>> implementation
>>>>>>>>> to integrate with BAM.
>>>>>>>>>
>>>>>>>>> There is no support to enable/disable metrics. Since this is an
>>>>>>>>> important feature for us, I'm thinking of introducing a custom
>>>>>>>>> component
>>>>>>>>> for performance monitoring.
>>>>>>>>>
>>>>>>>>> The custom component will support to enable/disable performance
>>>>>>>>> monitoring via system property and JMX. The WSO2 components will use
>>>>>>>>> the
>>>>>>>>> new performance monitoring component and we will be using the Metrics
>>>>>>>>> only
>>>>>>>>> inside the new component.
>>>>>>>>>
>>>>>>>>> I'm working on this and for testing we need to select a WSO2
>>>>>>>>> product. I'm thinking of adding the performance probes to WSO2 API
>>>>>>>>> Manager
>>>>>>>>> first. Since WSO2 CEP is also mentioned, we can have a look at that
>>>>>>>>> also.
>>>>>>>>>
>>>>>>>>> Please share any suggestions or feedback.
>>>>>>>>>
>>>>>>>>> I will update the thread once I create the initial design.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> http://isuru-perera.blogspot.com/2014/11/java-performance-monitoring-libraries.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Sep 29, 2014 at 10:00 AM, Srinath Perera <[email protected]
>>>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> Thanks Thomas!!
>>>>>>>>>>
>>>>>>>>>> Paul, I looked at all 3 and really liked what Thomas sent (
>>>>>>>>>> https://dropwizard.github.io/metrics/3.1.0/getting-started/).
>>>>>>>>>> Licence is Apache 2.
>>>>>>>>>>
>>>>>>>>>> I think I will try this out with a training project.
>>>>>>>>>>
>>>>>>>>>> --Srinath
>>>>>>>>>>
>>>>>>>>>> On Sat, Sep 27, 2014 at 11:37 AM, Thomas Wieger <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> please have a look on the metrics lib, which quite nicely
>>>>>>>>>>> provides support for capturing different kinds of statistics. see
>>>>>>>>>>> https://dropwizard.github.io/metrics/3.1.0/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> regards,
>>>>>>>>>>>
>>>>>>>>>>> thomas
>>>>>>>>>>>
>>>>>>>>>>> Am Freitag, 26. September 2014 schrieb Sajith Ravindra :
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> IMHO, CEP is another product where this kind of probes can be
>>>>>>>>>>>> really useful as we have to deal with performance related
>>>>>>>>>>>> requirements. As
>>>>>>>>>>>> there's a major refactoring going on in siddhi I think we can we
>>>>>>>>>>>> plant
>>>>>>>>>>>> probes like this into the Siddhi engine. It will be useful to
>>>>>>>>>>>> evaluate the
>>>>>>>>>>>> re-factored Sindhi engines performance as well as to figure out
>>>>>>>>>>>> performance
>>>>>>>>>>>> bottlenecks in the future.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> *,Sajith Ravindra*
>>>>>>>>>>>> Senior Software Engineer
>>>>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>>
>>>>>>>>>>>> mobile: +94 77 2273550
>>>>>>>>>>>> blog: http://sajithr.blogspot.com/
>>>>>>>>>>>> <http://lk.linkedin.com/pub/shani-ranasinghe/34/111/ab>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Sep 26, 2014 at 8:38 AM, Srinath Perera <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> We have some pretty nice probes already in ESB, that let you
>>>>>>>>>>>>> look into what is going in the same running in production. I
>>>>>>>>>>>>> think we need
>>>>>>>>>>>>> to do this generally and build it to other products. That should
>>>>>>>>>>>>> reduce
>>>>>>>>>>>>> time we spent debugging issues significantly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My proposal is to build a probe Lib that looks like following.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are two kinds of things you need to collect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Throughput at give point of code (how fast calls goes
>>>>>>>>>>>>> though)
>>>>>>>>>>>>> 2. Latency between two points.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We will have two types of Probes. Code would look like
>>>>>>>>>>>>> following.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Probe probe = new Probe("Name", "throughput", timeDuration);
>>>>>>>>>>>>> ..
>>>>>>>>>>>>> probe.recordThroughput();
>>>>>>>>>>>>>
>>>>>>>>>>>>> Probe probe = new Probe("Name", "latency", timeDuration,
>>>>>>>>>>>>> logLevel);
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> long id = probe.startTicking() // this so same probe can be
>>>>>>>>>>>>> used by many threads
>>>>>>>>>>>>> ...
>>>>>>>>>>>>> probe.endTicking(id);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Probe will summarise data over given duration and expose. We
>>>>>>>>>>>>> need
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. JMX bean
>>>>>>>>>>>>> 2. BAM Agent
>>>>>>>>>>>>> 3. Can turn on, off via JMX agent or via System property
>>>>>>>>>>>>> 4. Have Tool Box
>>>>>>>>>>>>> 5. Have in product UI
>>>>>>>>>>>>> 6. Can configured to write data to logs
>>>>>>>>>>>>>
>>>>>>>>>>>>> Each probe should be very small and should be able to create
>>>>>>>>>>>>> thousands without much effect. (e.g. create one for each mediator
>>>>>>>>>>>>> type)
>>>>>>>>>>>>>
>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Srinath
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> ============================
>>>>>>>>>>>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>>>>>>>>>>>>> Site: http://people.apache.org/~hemapani/
>>>>>>>>>>>>> Photos: http://www.flickr.com/photos/hemapani/
>>>>>>>>>>>>> Phone: 0772360902
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Architecture mailing list
>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ============================
>>>>>>>>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>>>>>>>>>> Site: http://people.apache.org/~hemapani/
>>>>>>>>>> Photos: http://www.flickr.com/photos/hemapani/
>>>>>>>>>> Phone: 0772360902
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Architecture mailing list
>>>>>>>>>> [email protected]
>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Isuru Perera
>>>>>>>>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>>>>>>>> Lean . Enterprise . Middleware
>>>>>>>>>
>>>>>>>>> about.me/chrishantha
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ============================
>>>>>>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>>>>>>>> Site: http://people.apache.org/~hemapani/
>>>>>>>> Photos: http://www.flickr.com/photos/hemapani/
>>>>>>>> Phone: 0772360902
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Isuru Perera
>>>>>>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>>>>>> Lean . Enterprise . Middleware
>>>>>>>
>>>>>>> about.me/chrishantha
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Isuru Perera
>>>>>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>>>>> Lean . Enterprise . Middleware
>>>>>>
>>>>>> about.me/chrishantha
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ramith Jayasinghe
>>>>> Technical Lead
>>>>> WSO2 Inc., http://wso2.com
>>>>> lean.enterprise.middleware
>>>>>
>>>>> E: [email protected]
>>>>> P: +94 777542851
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Isuru Perera
>>>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>>> Lean . Enterprise . Middleware
>>>>
>>>> about.me/chrishantha
>>>>
>>>
>>>
>>>
>>> --
>>> Isuru Perera
>>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> about.me/chrishantha
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Paul Fremantle
>> CTO and Co-Founder, WSO2
>> OASIS WS-RX TC Co-chair, Apache Member
>>
>> UK: +44 207 096 0336
>>
>> blog: http://pzf.fremantle.org
>> twitter.com/pzfreo
>> [email protected]
>>
>> wso2.com Lean Enterprise Middleware
>>
>> Disclaimer: This communication may contain privileged or other
>> confidential information and is intended exclusively for the addressee/s.
>> If you are not the intended recipient/s, or believe that you may have
>> received this communication in error, please reply to the sender indicating
>> that fact and delete the copy you received and in addition, you should not
>> print, copy, retransmit, disseminate, or otherwise use the information
>> contained in this communication. Internet communications cannot be
>> guaranteed to be timely, secure, error or virus-free. The sender does not
>> accept liability for any errors or omissions.
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> about.me/chrishantha
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Chintana Wilamuna
Solutions Architect
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
phone: +1 408 429 3321
blog: http://engwar.com/
linkedin: http://www.linkedin.com/in/chintanawilamuna
twitter: twitter.com/std_err
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
