You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David kerber <dc...@verizon.net> on 2014/05/14 18:28:46 UTC
Application monitoring
I am working on a small Tomcat servlet to monitor other tomcat-based
applications running on the same physical machine, and am trying to
figure out the best way to communicate between the monitoring app, and
the monitored apps.
My setup has several tomcat instances of a single application, each
running from its own directory, and listening on its own TCP port. So
there is no direct communication between the instances.
I'm trying to monitor various data about the application, not about
tomcat itself or the JVM. So I want to collect such things as the number
of requests it has processed, the last data received, etc, and not
things like memory and cpu usage. It is my app, so I can (and expect to
need to) add methods or servlets to return the information I want to
collect.
My question is, what is the best way to make the request to get the
data? Would URL request from the monitoring app to the monitored app
be appropriate, and then parse the response out for display in a
browser? If so, what java class is likely to be useful for this
communication? I will have all the information needed to connect to the
application instance (server, port, etc), but want it to be portable
across OS types.
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Mark Eggers <it...@yahoo.com>.
On 5/18/2014 2:26 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 5/17/14, 10:58 AM, Mark Eggers wrote:
>> Chris,
>>
>> On 5/16/2014 8:46 AM, Christopher Schultz wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>
>>> Mark,
>>>
>>> On 5/14/14, 1:41 PM, Mark Eggers wrote:
>>>> On Wed, 14 May 2014 12:28:46 -0400, David kerber wrote:
>>>>
>>>>> I am working on a small Tomcat servlet to monitor other
>>>>> tomcat-based applications running on the same physical
>>>>> machine, and am trying to figure out the best way to
>>>>> communicate between the monitoring app, and the monitored
>>>>> apps.
>>>>>
>>>>> My setup has several tomcat instances of a single
>>>>> application, each running from its own directory, and
>>>>> listening on its own TCP port. So there is no direct
>>>>> communication between the instances.
>>>>>
>>>>> I'm trying to monitor various data about the application,
>>>>> not about tomcat itself or the JVM. So I want to collect such
>>>>> things as the number of requests it has processed, the last
>>>>> data received, etc, and not things like memory and cpu usage.
>>>>> It is my app, so I can (and expect to need to) add methods or
>>>>> servlets to return the information I want to collect.
>>>>>
>>>>> My question is, what is the best way to make the request to
>>>>> get the data? Would URL request from the monitoring app to
>>>>> the monitored app be appropriate, and then parse the response
>>>>> out for display in a browser? If so, what java class is
>>>>> likely to be useful for this communication? I will have all
>>>>> the information needed to connect to the application instance
>>>>> (server, port, etc), but want it to be portable across OS
>>>>> types.
>>>>>
>>>>> Thanks!
>>>>
>>>> http://wiki.apache.org/tomcat/FAQ/Monitoring
>>>>
>>>> In particular, item 3. Unfortunately, the sample code seems to
>>>> be missing . . .
>>>
>>> Which is "item 3"? I'd be happy to fix whatever is missing.
>>>
>>> - -chris
>>
>> Example Application Exposing Internals Using JMX
>>
>> at the bottom of the page goes nowhere. More accurately, it goes to
>> a placeholder page.
>
> Aah. NevenCvetkovic added that link, not me, so I dunno what he was
> expecting to put there.
>
> I should probably link to my ApacheCon presentation if I'm not going
> to take some time to update the wiki itself.
>
> - -chris
That might be a good thing.
Now that I have some time, I might sit down and a) go through your
presentation, b) write some sample applications, and c) write a wiki
article on the results of a) and b).
I need to go back and clean up some of the stuff I posted on the wiki as
well - the articles are getting rather dated.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Leon Rosenberg <ro...@gmail.com>.
Hello David,
yes there is. And I sent you two links to blog entries about exactly that.
Did you read them?
regards
Leon
P.S. in the examples the app specific info is monitored directly and not
via jmx, because that saves a lot of overhead, but reading jmx beans is
also supported.
On Mon, May 19, 2014 at 3:01 PM, David kerber <dc...@verizon.net> wrote:
> On 5/19/2014 8:52 AM, Leon Rosenberg wrote:
>
>> David,
>>
>> I already asked you why you are reinventing the wheel, but it seems, for
>> fun, which is a perfectly ok reason though.
>> However, maybe you'll find some insights on how other people do it here:
>> http://blog.anotheria.net/msk/the-complete-moskito-
>> integration-guide-step-6-moskito-control/and
>> here:
>> http://blog.anotheria.net/msk/case-study-monitoring-a-
>> cluster-of-java-daemon-processes/
>>
>
> Leon -
>
> I don't want to re-invent the wheel if there's already something that will
> do what I need, but I don't see what you're getting at. Is there an
> already-existing tool that will let me look into multiple identical but
> independent tomcat apps, read various MBeans from each one and display that
> data in a single window? The data I want to display is
> application-specific, and not generic stuff like heap usage, GC info, etc.
>
> I understand that I should be able to connect to any one app and read its
> MBeans with some standard JMX tool/interface, but that's essentially what
> I'm doing now (though without using JMX) and am trying to get away from.
>
> Dave
>
>
>
>
>> regards
>> Leon
>>
>>
>> On Mon, May 19, 2014 at 2:42 PM, David kerber <dc...@verizon.net>
>> wrote:
>>
>> On 5/19/2014 8:27 AM, Neven Cvetkovic wrote:
>>>
>>> On Mon, May 19, 2014 at 8:11 AM, David kerber <dc...@verizon.net>
>>>> wrote:
>>>>
>>>>
>>>>> I've uploaded code examples and the JmxExample.war:
>>>>>
>>>>> https://wiki.apache.org/tomcat/Example%20Application%
>>>>>> 20Exposing%20Internals%20Using%20JMX
>>>>>>
>>>>>> So, just deploy JmxExample.war to your Tomcat instance, open up JMX
>>>>>> console
>>>>>> through JVisualVM or JConsole, and find the MBean, e.g.
>>>>>> JmxExampleApp:type=Counter
>>>>>>
>>>>>> You will see that the internal instance of MyCounter is exposed
>>>>>> through
>>>>>> JMX, and you will be able to set the name, initial count, reset the
>>>>>> counter, etc...
>>>>>>
>>>>>> The trick was to use @WebListener that registers the MBean instance
>>>>>> with
>>>>>> your MBeanServer upon application deployment. Your MBean instance will
>>>>>> wrap
>>>>>> around any of your application internals you would with to expose.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> What kind of performance hit does this "wrapper" cause? A couple
>>>> of my
>>>>
>>>>> app's instances take more than 4M transactions per day, up to several
>>>>> hundred per second at peak times. So I can't afford much added work
>>>>> per
>>>>> request.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> Hey David,
>>>>>
>>>>
>>>> Well, that depends what do you do for every transaction (request). In
>>>> the
>>>> above example with @WebListener, the app's performance should not be
>>>> affected significantly, all it does it registers a JMX MBean at app
>>>> deployment, and exposes the attributes and operations (getters/setters +
>>>> other public methods) to JMX clients invoke this MBean. Once you
>>>> undeploy
>>>> the app, it unregisters the MBean.
>>>>
>>>>
>>> Ok, that sounds promising. I was worried that every request might have
>>> to
>>> go through the filter/wrapper before getting to my core processing code.
>>> If the MBean classes only need to make (for example) getCounter() calls
>>> into my app's existing counters when needed, then that shouldn't be a
>>> problem.
>>>
>>>
>>>
>>>
>>> Sure, performance will depend on how often you call JMX, and that might
>>>> shave few OS cycles away from standard app operations (4M tx per day),
>>>> if
>>>> for example you want to make JMX calls every microsecond/second to plot
>>>> some charts, etc... that might put a dent in your app performance.
>>>>
>>>> Few questions for you:
>>>> - What kind of attributes/operations would you like to expose in your
>>>> application, by using JMX?
>>>>
>>>>
>>> I am already keeping some counters and other information and exposing it
>>> through a browser interface into each instance (a .jsp). But as the
>>> number
>>> of instances has grown from 3 to 12, monitoring each instance's status
>>> has
>>> become burdensome. Hence my desire to consolidate the monitoring of all
>>> instances into a single location, and present the same information
>>> through
>>> the new interface I'm discussing here. That data plus some startup
>>> parameters (the location of each app's various resources mostly) are all
>>> that I am looking to expose for now.
>>>
>>>
>>>
>>> - What would you like to manage using JMX?
>>>
>>>>
>>>>
>>> If by "managing", you mean controlling (changing settings, etc), I don't
>>> plan on doing any of that. At least not for now.
>>>
>>>
>>>
>>>
>>> It would be great to get some performance metrics and see how that
>>>> affects
>>>> your application!
>>>>
>>>> Keep us posted :)
>>>>
>>>> Cheers!
>>>> n.
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Application monitoring
Posted by David kerber <dc...@verizon.net>.
On 5/19/2014 8:52 AM, Leon Rosenberg wrote:
> David,
>
> I already asked you why you are reinventing the wheel, but it seems, for
> fun, which is a perfectly ok reason though.
> However, maybe you'll find some insights on how other people do it here:
> http://blog.anotheria.net/msk/the-complete-moskito-integration-guide-step-6-moskito-control/and
> here:
> http://blog.anotheria.net/msk/case-study-monitoring-a-cluster-of-java-daemon-processes/
Leon -
I don't want to re-invent the wheel if there's already something that
will do what I need, but I don't see what you're getting at. Is there
an already-existing tool that will let me look into multiple identical
but independent tomcat apps, read various MBeans from each one and
display that data in a single window? The data I want to display is
application-specific, and not generic stuff like heap usage, GC info, etc.
I understand that I should be able to connect to any one app and read
its MBeans with some standard JMX tool/interface, but that's essentially
what I'm doing now (though without using JMX) and am trying to get away
from.
Dave
>
> regards
> Leon
>
>
> On Mon, May 19, 2014 at 2:42 PM, David kerber <dc...@verizon.net> wrote:
>
>> On 5/19/2014 8:27 AM, Neven Cvetkovic wrote:
>>
>>> On Mon, May 19, 2014 at 8:11 AM, David kerber <dc...@verizon.net>
>>> wrote:
>>>
>>>>
>>>> I've uploaded code examples and the JmxExample.war:
>>>>
>>>>> https://wiki.apache.org/tomcat/Example%20Application%
>>>>> 20Exposing%20Internals%20Using%20JMX
>>>>>
>>>>> So, just deploy JmxExample.war to your Tomcat instance, open up JMX
>>>>> console
>>>>> through JVisualVM or JConsole, and find the MBean, e.g.
>>>>> JmxExampleApp:type=Counter
>>>>>
>>>>> You will see that the internal instance of MyCounter is exposed through
>>>>> JMX, and you will be able to set the name, initial count, reset the
>>>>> counter, etc...
>>>>>
>>>>> The trick was to use @WebListener that registers the MBean instance with
>>>>> your MBeanServer upon application deployment. Your MBean instance will
>>>>> wrap
>>>>> around any of your application internals you would with to expose.
>>>>>
>>>>
>>>>
>>>>
>>> What kind of performance hit does this "wrapper" cause? A couple of my
>>>> app's instances take more than 4M transactions per day, up to several
>>>> hundred per second at peak times. So I can't afford much added work per
>>>> request.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> Hey David,
>>>
>>> Well, that depends what do you do for every transaction (request). In the
>>> above example with @WebListener, the app's performance should not be
>>> affected significantly, all it does it registers a JMX MBean at app
>>> deployment, and exposes the attributes and operations (getters/setters +
>>> other public methods) to JMX clients invoke this MBean. Once you undeploy
>>> the app, it unregisters the MBean.
>>>
>>
>> Ok, that sounds promising. I was worried that every request might have to
>> go through the filter/wrapper before getting to my core processing code.
>> If the MBean classes only need to make (for example) getCounter() calls
>> into my app's existing counters when needed, then that shouldn't be a
>> problem.
>>
>>
>>
>>
>>> Sure, performance will depend on how often you call JMX, and that might
>>> shave few OS cycles away from standard app operations (4M tx per day), if
>>> for example you want to make JMX calls every microsecond/second to plot
>>> some charts, etc... that might put a dent in your app performance.
>>>
>>> Few questions for you:
>>> - What kind of attributes/operations would you like to expose in your
>>> application, by using JMX?
>>>
>>
>> I am already keeping some counters and other information and exposing it
>> through a browser interface into each instance (a .jsp). But as the number
>> of instances has grown from 3 to 12, monitoring each instance's status has
>> become burdensome. Hence my desire to consolidate the monitoring of all
>> instances into a single location, and present the same information through
>> the new interface I'm discussing here. That data plus some startup
>> parameters (the location of each app's various resources mostly) are all
>> that I am looking to expose for now.
>>
>>
>>
>> - What would you like to manage using JMX?
>>>
>>
>> If by "managing", you mean controlling (changing settings, etc), I don't
>> plan on doing any of that. At least not for now.
>>
>>
>>
>>
>>> It would be great to get some performance metrics and see how that affects
>>> your application!
>>>
>>> Keep us posted :)
>>>
>>> Cheers!
>>> n.
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Leon Rosenberg <ro...@gmail.com>.
David,
I already asked you why you are reinventing the wheel, but it seems, for
fun, which is a perfectly ok reason though.
However, maybe you'll find some insights on how other people do it here:
http://blog.anotheria.net/msk/the-complete-moskito-integration-guide-step-6-moskito-control/and
here:
http://blog.anotheria.net/msk/case-study-monitoring-a-cluster-of-java-daemon-processes/
regards
Leon
On Mon, May 19, 2014 at 2:42 PM, David kerber <dc...@verizon.net> wrote:
> On 5/19/2014 8:27 AM, Neven Cvetkovic wrote:
>
>> On Mon, May 19, 2014 at 8:11 AM, David kerber <dc...@verizon.net>
>> wrote:
>>
>>>
>>> I've uploaded code examples and the JmxExample.war:
>>>
>>>> https://wiki.apache.org/tomcat/Example%20Application%
>>>> 20Exposing%20Internals%20Using%20JMX
>>>>
>>>> So, just deploy JmxExample.war to your Tomcat instance, open up JMX
>>>> console
>>>> through JVisualVM or JConsole, and find the MBean, e.g.
>>>> JmxExampleApp:type=Counter
>>>>
>>>> You will see that the internal instance of MyCounter is exposed through
>>>> JMX, and you will be able to set the name, initial count, reset the
>>>> counter, etc...
>>>>
>>>> The trick was to use @WebListener that registers the MBean instance with
>>>> your MBeanServer upon application deployment. Your MBean instance will
>>>> wrap
>>>> around any of your application internals you would with to expose.
>>>>
>>>
>>>
>>>
>> What kind of performance hit does this "wrapper" cause? A couple of my
>>> app's instances take more than 4M transactions per day, up to several
>>> hundred per second at peak times. So I can't afford much added work per
>>> request.
>>>
>>> Thanks!
>>>
>>>
>>> Hey David,
>>
>> Well, that depends what do you do for every transaction (request). In the
>> above example with @WebListener, the app's performance should not be
>> affected significantly, all it does it registers a JMX MBean at app
>> deployment, and exposes the attributes and operations (getters/setters +
>> other public methods) to JMX clients invoke this MBean. Once you undeploy
>> the app, it unregisters the MBean.
>>
>
> Ok, that sounds promising. I was worried that every request might have to
> go through the filter/wrapper before getting to my core processing code.
> If the MBean classes only need to make (for example) getCounter() calls
> into my app's existing counters when needed, then that shouldn't be a
> problem.
>
>
>
>
>> Sure, performance will depend on how often you call JMX, and that might
>> shave few OS cycles away from standard app operations (4M tx per day), if
>> for example you want to make JMX calls every microsecond/second to plot
>> some charts, etc... that might put a dent in your app performance.
>>
>> Few questions for you:
>> - What kind of attributes/operations would you like to expose in your
>> application, by using JMX?
>>
>
> I am already keeping some counters and other information and exposing it
> through a browser interface into each instance (a .jsp). But as the number
> of instances has grown from 3 to 12, monitoring each instance's status has
> become burdensome. Hence my desire to consolidate the monitoring of all
> instances into a single location, and present the same information through
> the new interface I'm discussing here. That data plus some startup
> parameters (the location of each app's various resources mostly) are all
> that I am looking to expose for now.
>
>
>
> - What would you like to manage using JMX?
>>
>
> If by "managing", you mean controlling (changing settings, etc), I don't
> plan on doing any of that. At least not for now.
>
>
>
>
>> It would be great to get some performance metrics and see how that affects
>> your application!
>>
>> Keep us posted :)
>>
>> Cheers!
>> n.
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Application monitoring
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 5/19/14, 8:42 AM, David kerber wrote:
> On 5/19/2014 8:27 AM, Neven Cvetkovic wrote:
>> On Mon, May 19, 2014 at 8:11 AM, David kerber
>> <dc...@verizon.net> wrote:
>>>
>>> I've uploaded code examples and the JmxExample.war:
>>>> https://wiki.apache.org/tomcat/Example%20Application%
>>>> 20Exposing%20Internals%20Using%20JMX
>>>>
>>>> So, just deploy JmxExample.war to your Tomcat instance, open
>>>> up JMX console through JVisualVM or JConsole, and find the
>>>> MBean, e.g. JmxExampleApp:type=Counter
>>>>
>>>> You will see that the internal instance of MyCounter is
>>>> exposed through JMX, and you will be able to set the name,
>>>> initial count, reset the counter, etc...
>>>>
>>>> The trick was to use @WebListener that registers the MBean
>>>> instance with your MBeanServer upon application deployment.
>>>> Your MBean instance will wrap around any of your application
>>>> internals you would with to expose.
>>>
>>>
>>
>>> What kind of performance hit does this "wrapper" cause? A
>>> couple of my app's instances take more than 4M transactions per
>>> day, up to several hundred per second at peak times. So I
>>> can't afford much added work per request.
>>>
>>> Thanks!
>>>
>>>
>> Hey David,
>>
>> Well, that depends what do you do for every transaction
>> (request). In the above example with @WebListener, the app's
>> performance should not be affected significantly, all it does it
>> registers a JMX MBean at app deployment, and exposes the
>> attributes and operations (getters/setters + other public
>> methods) to JMX clients invoke this MBean. Once you undeploy the
>> app, it unregisters the MBean.
>
> Ok, that sounds promising. I was worried that every request might
> have to go through the filter/wrapper before getting to my core
> processing code. If the MBean classes only need to make (for
> example) getCounter() calls into my app's existing counters when
> needed, then that shouldn't be a problem.
This is entirely up to you and your requirements. For instance, if you
need to update some stats with every transaction, then yes you'll
probably need to take a bit of a performance hit to execute the code
to do such work.
If you already have whatever information you want to be made available
via JMX, then all you have to do it fetch it each time someone
requests the data (e.g. no additional work per transaction).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTen1kAAoJEBzwKT+lPKRYFBMP/ju6liFYRz0ofwH8zTciz4i+
t6sJ6gvmEZCraXnuCCClGW+geMQhRvTzv6v/PaCvZQW0/rmY/UQCreW1Yk1EaFw/
bWFnqFHSz9K7QJjiYpEe9aKBmUlOnGy0TFT21mrC5mpXUdz2YpVUl6CK/0Kbj5c7
NmUZ2R3rn7Vg4J1Dk0yglz03bQzIcRzwR0lD+mLyR9rduTyF3hidCiEKZ5uIIcqR
yHEr8cCk6lW/YKkt0c+5fLzez0842FXJR/tjU+cO/T/HM44d0bPZDV+4d9vYBQm2
DBX8u3DWvNF8Gh9EpzpMatFkjLpofusu2TzX9v67cxKXoSrUnRPWIhww/lCmfFP/
bv9ZXWLkYRouB0uAWhuLvMEOz6aLfeHcIRDH+92GhpVbwXwzreahHmDBx13sakqK
N3or7l1afcL66axw+tcYefuiDvOV8SO/clRUwc5XtfAv2CWBaPTqxbaMcJ7u9EOQ
ygp0+I7IZ62kYPeJ2PKwOx4RC0IQtTKYeE67d79xChTDPU30UWvZiFObKuozrDfM
/7BMD+iO145RyjXYoPjjOqY9kbQqTBHqqqOB0e2+slPJivz93DmAqmTws9/5J3I1
N4SGSH094pTfsb7NMmsr5JmoASJNRcaBRjDE7UtR5zP83eUX3UeFfnvPaYeuXJbo
O8xxdCMNkZBagpBs4c/V
=jUCP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by David kerber <dc...@verizon.net>.
On 5/19/2014 8:27 AM, Neven Cvetkovic wrote:
> On Mon, May 19, 2014 at 8:11 AM, David kerber <dc...@verizon.net> wrote:
>>
>> I've uploaded code examples and the JmxExample.war:
>>> https://wiki.apache.org/tomcat/Example%20Application%
>>> 20Exposing%20Internals%20Using%20JMX
>>>
>>> So, just deploy JmxExample.war to your Tomcat instance, open up JMX
>>> console
>>> through JVisualVM or JConsole, and find the MBean, e.g.
>>> JmxExampleApp:type=Counter
>>>
>>> You will see that the internal instance of MyCounter is exposed through
>>> JMX, and you will be able to set the name, initial count, reset the
>>> counter, etc...
>>>
>>> The trick was to use @WebListener that registers the MBean instance with
>>> your MBeanServer upon application deployment. Your MBean instance will
>>> wrap
>>> around any of your application internals you would with to expose.
>>
>>
>
>> What kind of performance hit does this "wrapper" cause? A couple of my
>> app's instances take more than 4M transactions per day, up to several
>> hundred per second at peak times. So I can't afford much added work per
>> request.
>>
>> Thanks!
>>
>>
> Hey David,
>
> Well, that depends what do you do for every transaction (request). In the
> above example with @WebListener, the app's performance should not be
> affected significantly, all it does it registers a JMX MBean at app
> deployment, and exposes the attributes and operations (getters/setters +
> other public methods) to JMX clients invoke this MBean. Once you undeploy
> the app, it unregisters the MBean.
Ok, that sounds promising. I was worried that every request might have
to go through the filter/wrapper before getting to my core processing
code. If the MBean classes only need to make (for example) getCounter()
calls into my app's existing counters when needed, then that shouldn't
be a problem.
>
> Sure, performance will depend on how often you call JMX, and that might
> shave few OS cycles away from standard app operations (4M tx per day), if
> for example you want to make JMX calls every microsecond/second to plot
> some charts, etc... that might put a dent in your app performance.
>
> Few questions for you:
> - What kind of attributes/operations would you like to expose in your
> application, by using JMX?
I am already keeping some counters and other information and exposing it
through a browser interface into each instance (a .jsp). But as the
number of instances has grown from 3 to 12, monitoring each instance's
status has become burdensome. Hence my desire to consolidate the
monitoring of all instances into a single location, and present the same
information through the new interface I'm discussing here. That data
plus some startup parameters (the location of each app's various
resources mostly) are all that I am looking to expose for now.
> - What would you like to manage using JMX?
If by "managing", you mean controlling (changing settings, etc), I don't
plan on doing any of that. At least not for now.
>
> It would be great to get some performance metrics and see how that affects
> your application!
>
> Keep us posted :)
>
> Cheers!
> n.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Neven Cvetkovic <ne...@gmail.com>.
On Mon, May 19, 2014 at 8:11 AM, David kerber <dc...@verizon.net> wrote:
>
> I've uploaded code examples and the JmxExample.war:
>> https://wiki.apache.org/tomcat/Example%20Application%
>> 20Exposing%20Internals%20Using%20JMX
>>
>> So, just deploy JmxExample.war to your Tomcat instance, open up JMX
>> console
>> through JVisualVM or JConsole, and find the MBean, e.g.
>> JmxExampleApp:type=Counter
>>
>> You will see that the internal instance of MyCounter is exposed through
>> JMX, and you will be able to set the name, initial count, reset the
>> counter, etc...
>>
>> The trick was to use @WebListener that registers the MBean instance with
>> your MBeanServer upon application deployment. Your MBean instance will
>> wrap
>> around any of your application internals you would with to expose.
>
>
> What kind of performance hit does this "wrapper" cause? A couple of my
> app's instances take more than 4M transactions per day, up to several
> hundred per second at peak times. So I can't afford much added work per
> request.
>
> Thanks!
>
>
Hey David,
Well, that depends what do you do for every transaction (request). In the
above example with @WebListener, the app's performance should not be
affected significantly, all it does it registers a JMX MBean at app
deployment, and exposes the attributes and operations (getters/setters +
other public methods) to JMX clients invoke this MBean. Once you undeploy
the app, it unregisters the MBean.
Sure, performance will depend on how often you call JMX, and that might
shave few OS cycles away from standard app operations (4M tx per day), if
for example you want to make JMX calls every microsecond/second to plot
some charts, etc... that might put a dent in your app performance.
Few questions for you:
- What kind of attributes/operations would you like to expose in your
application, by using JMX?
- What would you like to manage using JMX?
It would be great to get some performance metrics and see how that affects
your application!
Keep us posted :)
Cheers!
n.
Re: Application monitoring
Posted by David kerber <dc...@verizon.net>.
On 5/19/2014 3:23 AM, Neven Cvetkovic wrote:
> On Sun, May 18, 2014 at 11:26 PM, Neven Cvetkovic <neven.cvetkovic@gmail.com
>> wrote:
>
>>
...
>>
>> Chris thanks for the reminder, I will fix the missing page with the
>> example I wrote, back then.
>>
>> I thought I have published that already.
>>
> I've uploaded code examples and the JmxExample.war:
> https://wiki.apache.org/tomcat/Example%20Application%20Exposing%20Internals%20Using%20JMX
>
> So, just deploy JmxExample.war to your Tomcat instance, open up JMX console
> through JVisualVM or JConsole, and find the MBean, e.g.
> JmxExampleApp:type=Counter
>
> You will see that the internal instance of MyCounter is exposed through
> JMX, and you will be able to set the name, initial count, reset the
> counter, etc...
>
> The trick was to use @WebListener that registers the MBean instance with
> your MBeanServer upon application deployment. Your MBean instance will wrap
> around any of your application internals you would with to expose.
>
> Hope that helps!
What kind of performance hit does this "wrapper" cause? A couple of my
app's instances take more than 4M transactions per day, up to several
hundred per second at peak times. So I can't afford much added work per
request.
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Neven Cvetkovic <ne...@gmail.com>.
On Sun, May 18, 2014 at 11:26 PM, Neven Cvetkovic <neven.cvetkovic@gmail.com
> wrote:
>
> > >> Which is "item 3"? I'd be happy to fix whatever is missing.
> > >>
> > >> - -chris
> > >
> > > Example Application Exposing Internals Using JMX
> > >
> > > at the bottom of the page goes nowhere. More accurately, it goes to
> > > a placeholder page.
> >
> > Aah. NevenCvetkovic added that link, not me, so I dunno what he was
> > expecting to put there.
> >
>
> Chris thanks for the reminder, I will fix the missing page with the
> example I wrote, back then.
>
> I thought I have published that already.
>
I've uploaded code examples and the JmxExample.war:
https://wiki.apache.org/tomcat/Example%20Application%20Exposing%20Internals%20Using%20JMX
So, just deploy JmxExample.war to your Tomcat instance, open up JMX console
through JVisualVM or JConsole, and find the MBean, e.g.
JmxExampleApp:type=Counter
You will see that the internal instance of MyCounter is exposed through
JMX, and you will be able to set the name, initial count, reset the
counter, etc...
The trick was to use @WebListener that registers the MBean instance with
your MBeanServer upon application deployment. Your MBean instance will wrap
around any of your application internals you would with to expose.
Hope that helps!
Cheers!
Neven
Re: Application monitoring
Posted by Neven Cvetkovic <ne...@gmail.com>.
> >> Which is "item 3"? I'd be happy to fix whatever is missing.
> >>
> >> - -chris
> >
> > Example Application Exposing Internals Using JMX
> >
> > at the bottom of the page goes nowhere. More accurately, it goes to
> > a placeholder page.
>
> Aah. NevenCvetkovic added that link, not me, so I dunno what he was
> expecting to put there.
>
Chris thanks for the reminder, I will fix the missing page with the example
I wrote, back then.
I thought I have published that already.
Re: Application monitoring
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 5/17/14, 10:58 AM, Mark Eggers wrote:
> Chris,
>
> On 5/16/2014 8:46 AM, Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Mark,
>>
>> On 5/14/14, 1:41 PM, Mark Eggers wrote:
>>> On Wed, 14 May 2014 12:28:46 -0400, David kerber wrote:
>>>
>>>> I am working on a small Tomcat servlet to monitor other
>>>> tomcat-based applications running on the same physical
>>>> machine, and am trying to figure out the best way to
>>>> communicate between the monitoring app, and the monitored
>>>> apps.
>>>>
>>>> My setup has several tomcat instances of a single
>>>> application, each running from its own directory, and
>>>> listening on its own TCP port. So there is no direct
>>>> communication between the instances.
>>>>
>>>> I'm trying to monitor various data about the application,
>>>> not about tomcat itself or the JVM. So I want to collect such
>>>> things as the number of requests it has processed, the last
>>>> data received, etc, and not things like memory and cpu usage.
>>>> It is my app, so I can (and expect to need to) add methods or
>>>> servlets to return the information I want to collect.
>>>>
>>>> My question is, what is the best way to make the request to
>>>> get the data? Would URL request from the monitoring app to
>>>> the monitored app be appropriate, and then parse the response
>>>> out for display in a browser? If so, what java class is
>>>> likely to be useful for this communication? I will have all
>>>> the information needed to connect to the application instance
>>>> (server, port, etc), but want it to be portable across OS
>>>> types.
>>>>
>>>> Thanks!
>>>
>>> http://wiki.apache.org/tomcat/FAQ/Monitoring
>>>
>>> In particular, item 3. Unfortunately, the sample code seems to
>>> be missing . . .
>>
>> Which is "item 3"? I'd be happy to fix whatever is missing.
>>
>> - -chris
>
> Example Application Exposing Internals Using JMX
>
> at the bottom of the page goes nowhere. More accurately, it goes to
> a placeholder page.
Aah. NevenCvetkovic added that link, not me, so I dunno what he was
expecting to put there.
I should probably link to my ApacheCon presentation if I'm not going
to take some time to update the wiki itself.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTeSWGAAoJEBzwKT+lPKRYyFYP/iBJGwEDqWRCu8Lv5Bt/OTzr
W4GOxbLV5Kkp6GBE+XaUWbwo+Mpz2+NkrtJ6HBjSpG8AtONDxH98GDGe2RWaV0d9
1pVGhRzBMOHnohVjJ+3s4KK0fKrzO/fmSYu/qgZBlGwZy/8Pw3tWMmXwFP5uOSDK
Q7qchK54Na7WWvEd3hoOCz9tSXUX+VU+rCxHKlLDaH6f4oDsnXaA/DWWSxIGuuBj
7+TUBp43Rg/WDDBnrlBjdaTqpXvrdQ81Ys+nXJIeeJucOpKDaQi3MBhOt9jYnU3L
VhHzLdS3pZGhx9kM+4TBaA2Hr3wbEn6RhF50EEgJSwqYqbxu6ZC/GBwNBPy9m0Yx
wOKSoHO1UVHxa9nAv5ovhP5tvDdN66CxlcekHUhFev6QnPS+pdpQYQxisbWpr1HH
p0QJjRqWpACqyLygEuYgaZ7kZbIF3PXh9BEDadvqcMjwVvJB1JGB6aU1e0FEkt67
YryB4iUTAcZ0aKut0BJdv3Hf0EYBzR7xo7Ug5jQVtNhVYG3pSHT1gJEG3r107uNH
Hgl554cYTNWGaLBQJs27BfxT7K2LnXld4aTTgKGfnsEwRFaOzHN0f32ZC76cAoY0
dO2fEtzxALD6fGgSbv1LRohum04lHr7kztUU21TDfvhBjou/v+wcQ3BK05YQLf5O
Rf6Ux+9kPA29Rae5X/nW
=Wogo
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Mark Eggers <it...@yahoo.com>.
Chris,
On 5/16/2014 8:46 AM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 5/14/14, 1:41 PM, Mark Eggers wrote:
>> On Wed, 14 May 2014 12:28:46 -0400, David kerber wrote:
>>
>>> I am working on a small Tomcat servlet to monitor other
>>> tomcat-based applications running on the same physical machine,
>>> and am trying to figure out the best way to communicate between
>>> the monitoring app, and the monitored apps.
>>>
>>> My setup has several tomcat instances of a single application,
>>> each running from its own directory, and listening on its own TCP
>>> port. So there is no direct communication between the
>>> instances.
>>>
>>> I'm trying to monitor various data about the application, not
>>> about tomcat itself or the JVM. So I want to collect such things
>>> as the number of requests it has processed, the last data
>>> received, etc, and not things like memory and cpu usage. It is
>>> my app, so I can (and expect to need to) add methods or servlets
>>> to return the information I want to collect.
>>>
>>> My question is, what is the best way to make the request to get
>>> the data? Would URL request from the monitoring app to the
>>> monitored app be appropriate, and then parse the response out for
>>> display in a browser? If so, what java class is likely to be
>>> useful for this communication? I will have all the information
>>> needed to connect to the application instance (server, port,
>>> etc), but want it to be portable across OS types.
>>>
>>> Thanks!
>>
>> http://wiki.apache.org/tomcat/FAQ/Monitoring
>>
>> In particular, item 3. Unfortunately, the sample code seems to be
>> missing . . .
>
> Which is "item 3"? I'd be happy to fix whatever is missing.
>
> - -chris
Example Application Exposing Internals Using JMX
at the bottom of the page goes nowhere. More accurately, it goes to a
placeholder page.
. . . . just my two cents
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 5/14/14, 1:41 PM, Mark Eggers wrote:
> On Wed, 14 May 2014 12:28:46 -0400, David kerber wrote:
>
>> I am working on a small Tomcat servlet to monitor other
>> tomcat-based applications running on the same physical machine,
>> and am trying to figure out the best way to communicate between
>> the monitoring app, and the monitored apps.
>>
>> My setup has several tomcat instances of a single application,
>> each running from its own directory, and listening on its own TCP
>> port. So there is no direct communication between the
>> instances.
>>
>> I'm trying to monitor various data about the application, not
>> about tomcat itself or the JVM. So I want to collect such things
>> as the number of requests it has processed, the last data
>> received, etc, and not things like memory and cpu usage. It is
>> my app, so I can (and expect to need to) add methods or servlets
>> to return the information I want to collect.
>>
>> My question is, what is the best way to make the request to get
>> the data? Would URL request from the monitoring app to the
>> monitored app be appropriate, and then parse the response out for
>> display in a browser? If so, what java class is likely to be
>> useful for this communication? I will have all the information
>> needed to connect to the application instance (server, port,
>> etc), but want it to be portable across OS types.
>>
>> Thanks!
>
> http://wiki.apache.org/tomcat/FAQ/Monitoring
>
> In particular, item 3. Unfortunately, the sample code seems to be
> missing . . .
Which is "item 3"? I'd be happy to fix whatever is missing.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTdjLiAAoJEBzwKT+lPKRYKK0P/37LoZHwXvDX/jQ/CNXoC85P
WpqyFkowFVG5M5XGNhnAvYIBgCuHD0lteur4M0+ovhYJky1LyzoPfK78L+aEAaMG
9MtCKH9wAIz9hNfQdYSw8EBE8pHzQ9xmnqrl2LqVtFkUq1SVQaCNQ7PH/s6dsq0C
ZElWzyCv8AcLZRQ0P5cWR4URA4EE26i4v5/WRzs5JddJFF7KcqLfdFsFQRR8EBCf
J8nBOJvFhtsbXSLZFeLmzJt4Cpmu1jfaAnkCGu/iJHqlnN6pqsRJMcciYOivfWd6
5krVvOL/7+UbO0gmsu3qCzjbgbKWBlwleaNMRcR+VSUDHaVUVAdVzNIWIqFzAk7V
AM07bWOl/pE3+SbOav+ckJN9nhTUeQUvEsmvPSKx78N2CGJvZw080dLzlQu4kxMN
TEGvOrhOmxy2SJMQ1VMVRRKxiG/mIpMJDZxB7SxaWvw7Y7STkkgz+rn3fAh0guQa
HiGEQSEuoRuD65PojSMXiZUEmT58OZkjYvqckjFkdedRUQSS7QB1FagkRRHB5uZ5
Q4v75AHiyLBCjdHSEJDnpOQbTMPnJEiT3iy8kQZtpH3SoDL4EWg9m9H5eZkfVKaL
+XgjDvfIXnZ2PD7I+rVGukkWz/wrv3OBVWwRSacdQZSa96z5JnAH9lwepL+Zm9M0
U7CtgDY30Q22fYqJFP7F
=IIse
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Mark Eggers <it...@yahoo.com>.
On Wed, 14 May 2014 12:28:46 -0400, David kerber wrote:
> I am working on a small Tomcat servlet to monitor other tomcat-based
> applications running on the same physical machine, and am trying to
> figure out the best way to communicate between the monitoring app, and
> the monitored apps.
>
> My setup has several tomcat instances of a single application, each
> running from its own directory, and listening on its own TCP port. So
> there is no direct communication between the instances.
>
> I'm trying to monitor various data about the application, not about
> tomcat itself or the JVM. So I want to collect such things as the number
> of requests it has processed, the last data received, etc, and not
> things like memory and cpu usage. It is my app, so I can (and expect to
> need to) add methods or servlets to return the information I want to
> collect.
>
> My question is, what is the best way to make the request to get the
> data? Would URL request from the monitoring app to the monitored app
> be appropriate, and then parse the response out for display in a
> browser? If so, what java class is likely to be useful for this
> communication? I will have all the information needed to connect to the
> application instance (server, port, etc), but want it to be portable
> across OS types.
>
> Thanks!
http://wiki.apache.org/tomcat/FAQ/Monitoring
In particular, item 3. Unfortunately, the sample code seems to be
missing . . .
. . . . just my two cents
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 5/16/14, 11:12 AM, David kerber wrote:
> On 5/15/2014 9:57 AM, Leon Rosenberg wrote:
>> Hello David,
>>
>> I will not ask you why you are reinventing the wheel (ok, I lied,
>> why are you reinventing the wheel?). You have multiple options
>> available: 1) You could use jmx and publish your information as
>> jmx beans. 2) You could use rmi between you 'collector' and the
>> target apps. 3) You could use simple http (preferably json), but
>> in that case I would advice to setup a separate collector for
>> it.
>>
>> For any of the above options there are numbers of classes and
>> utilities you can use. For example jersey as jax-rs
>> implementation is perfect for exchange of json data, for rmi you
>> could use DistributeMe ( http://www.distributeme.org) or
>> spring-remote, and so on.
>>
>> But yet again, why reinventing the wheel?
>
> I'm not trying to. Your responses above are the exact kinds of
> information I was looking for: how to communicate between my app
> that displays the information, and the monitored apps.
>
> Now I just need to look into how to use jmx, rmi and json to figure
> out which will serve my needs the best. My goal here is to be able
> to click on a browser bookmark and after logging in, have all the
> information from these dozen apps displayed in an organized table,
> so I don't have to do anything more than scroll down the page to
> see them all.
>
> They are all OS-agnostic, I presume?
I've done a presentation about how to do this with JMX. Since you are
using a persistent server that is already running Java, you could
maintain a persistent JMX connection with each of the servers to
monitor, and so some of the tools mentioned within are probably less
relevant, but here it is:
http://people.apache.org/~schultz/ApacheCon%20NA%202014/Monitoring%20Apache%20Tomcat%20with%20JMX.pdf
That will show you what information you can get from Tomcat (e.g.
request counts) as well as how to publish whatever information you
want to make available from your own web application.
If you write something cool, consider sticking it up on the wiki or
something.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTdjOAAAoJEBzwKT+lPKRYBLQP/i4n8gy+7vE2ydGd302Qh9RY
ZXFjLUJZt4HiBm3OYQLGOMb3mSgcyYE32CFwmgNPUv5zrJdIlkBgymPBh1JN4fXk
KjWpX6uFKBzKVVa+p0IWCwQ0dGq1xvE01g2UcitivUiwV3O1FlXdOn/qOGtWvLqS
Q02VB0NrUxE3Y+HUGA6pufthhApyFQ81Vl+XUy7suh2k42WsITBed4nQBot5RE5u
NjaZS4pLYoL/t1q0Q2pFo+z/INZAjs1FsX750sMaOfLfwVDI7c4Hp1zjO74CpWfV
zOoSNQtcC96QYSILL90eBs2qT/lpc+/HPK6KFZJy6U2H29E83VKrUG58jjT5Khjv
JDPSVz1aidFKJqt3mrrw2FwiewwlVo1z39MFLtGgc/z12BnAwrwdnsE2j0teC0kZ
hq9+GxUUebLb7N3jyKHlRUpWHTEtAsfoYMppYEV+x1IFSKvEwuIv/xDHHGqq+5jx
27BOA3xPc7QTjCnpBhqU8CQFuohp+zKeo8qU+MxEkOgBYHCx7xYPwSWYDg1w/hMF
a30g126eh9aMMrMeCc0NuhPwKe1pescko6IgLgvshKMBNTM7vO4kp7CBaqkY52bw
roQxvNIKk5S8ki9biHtmTOLYTQjqZ2byzKM4bgI16aiQsSK13S4iVu7jxeq6IBc0
C0R7koNee6WgzEETFX0B
=DTAc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by David kerber <dc...@verizon.net>.
On 5/15/2014 9:57 AM, Leon Rosenberg wrote:
> Hello David,
>
> I will not ask you why you are reinventing the wheel (ok, I lied, why are
> you reinventing the wheel?).
> You have multiple options available:
> 1) You could use jmx and publish your information as jmx beans.
> 2) You could use rmi between you 'collector' and the target apps.
> 3) You could use simple http (preferably json), but in that case I would
> advice to setup a separate collector for it.
>
> For any of the above options there are numbers of classes and utilities you
> can use. For example jersey as jax-rs implementation is perfect for
> exchange of json data, for rmi you could use DistributeMe (
> http://www.distributeme.org) or spring-remote, and so on.
>
> But yet again, why reinventing the wheel?
I'm not trying to. Your responses above are the exact kinds of
information I was looking for: how to communicate between my app that
displays the information, and the monitored apps.
Now I just need to look into how to use jmx, rmi and json to figure out
which will serve my needs the best. My goal here is to be able to click
on a browser bookmark and after logging in, have all the information
from these dozen apps displayed in an organized table, so I don't have
to do anything more than scroll down the page to see them all.
They are all OS-agnostic, I presume?
Thanks!
>
> regards
> Leon
>
>
>
> On Wed, May 14, 2014 at 6:28 PM, David kerber <dc...@verizon.net> wrote:
>
>> I am working on a small Tomcat servlet to monitor other tomcat-based
>> applications running on the same physical machine, and am trying to figure
>> out the best way to communicate between the monitoring app, and the
>> monitored apps.
>>
>> My setup has several tomcat instances of a single application, each
>> running from its own directory, and listening on its own TCP port. So
>> there is no direct communication between the instances.
>>
>> I'm trying to monitor various data about the application, not about tomcat
>> itself or the JVM. So I want to collect such things as the number of
>> requests it has processed, the last data received, etc, and not things like
>> memory and cpu usage. It is my app, so I can (and expect to need to) add
>> methods or servlets to return the information I want to collect.
>>
>> My question is, what is the best way to make the request to get the data?
>> Would URL request from the monitoring app to the monitored app be
>> appropriate, and then parse the response out for display in a browser? If
>> so, what java class is likely to be useful for this communication? I will
>> have all the information needed to connect to the application instance
>> (server, port, etc), but want it to be portable across OS types.
>>
>> Thanks!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by P Manchanda <ma...@yahoo.com>.
Thanks Leon
>> 1) You could use jmx and publish your information as jmx beans.
That was the first thought I had. I would prefer using JMX beans, so that i can leverage any JMX tool like JConsole or JVisualVM
___________________
Thks & brgds
P Manchanda
--------------------------------------------
On Thu, 15/5/14, Leon Rosenberg <ro...@gmail.com> wrote:
Subject: Re: Application monitoring
To: "Tomcat Users List" <us...@tomcat.apache.org>
Date: Thursday, 15 May, 2014, 19:27
Hello David,
I will not ask you why you are reinventing the wheel (ok, I
lied, why are
you reinventing the wheel?).
You have multiple options available:
1) You could use jmx and publish your information as jmx
beans.
2) You could use rmi between you 'collector' and the target
apps.
3) You could use simple http (preferably json), but in that
case I would
advice to setup a separate collector for it.
For any of the above options there are numbers of classes
and utilities you
can use. For example jersey as jax-rs implementation is
perfect for
exchange of json data, for rmi you could use DistributeMe (
http://www.distributeme.org) or spring-remote, and so
on.
But yet again, why reinventing the wheel?
regards
Leon
On Wed, May 14, 2014 at 6:28 PM, David kerber <dc...@verizon.net>
wrote:
> I am working on a small Tomcat servlet to monitor other
tomcat-based
> applications running on the same physical machine, and
am trying to figure
> out the best way to communicate between the monitoring
app, and the
> monitored apps.
>
> My setup has several tomcat instances of a single
application, each
> running from its own directory, and listening on its
own TCP port. So
> there is no direct communication between the
instances.
>
> I'm trying to monitor various data about the
application, not about tomcat
> itself or the JVM. So I want to collect such things as
the number of
> requests it has processed, the last data received, etc,
and not things like
> memory and cpu usage. It is my app, so I can (and
expect to need to) add
> methods or servlets to return the information I want to
collect.
>
> My question is, what is the best way to make the
request to get the data?
> Would URL request from the monitoring app
to the monitored app be
> appropriate, and then parse the response out for
display in a browser? If
> so, what java class is likely to be useful for this
communication? I will
> have all the information needed to connect to the
application instance
> (server, port, etc), but want it to be portable across
OS types.
>
> Thanks!
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Application monitoring
Posted by Leon Rosenberg <ro...@gmail.com>.
Hello David,
I will not ask you why you are reinventing the wheel (ok, I lied, why are
you reinventing the wheel?).
You have multiple options available:
1) You could use jmx and publish your information as jmx beans.
2) You could use rmi between you 'collector' and the target apps.
3) You could use simple http (preferably json), but in that case I would
advice to setup a separate collector for it.
For any of the above options there are numbers of classes and utilities you
can use. For example jersey as jax-rs implementation is perfect for
exchange of json data, for rmi you could use DistributeMe (
http://www.distributeme.org) or spring-remote, and so on.
But yet again, why reinventing the wheel?
regards
Leon
On Wed, May 14, 2014 at 6:28 PM, David kerber <dc...@verizon.net> wrote:
> I am working on a small Tomcat servlet to monitor other tomcat-based
> applications running on the same physical machine, and am trying to figure
> out the best way to communicate between the monitoring app, and the
> monitored apps.
>
> My setup has several tomcat instances of a single application, each
> running from its own directory, and listening on its own TCP port. So
> there is no direct communication between the instances.
>
> I'm trying to monitor various data about the application, not about tomcat
> itself or the JVM. So I want to collect such things as the number of
> requests it has processed, the last data received, etc, and not things like
> memory and cpu usage. It is my app, so I can (and expect to need to) add
> methods or servlets to return the information I want to collect.
>
> My question is, what is the best way to make the request to get the data?
> Would URL request from the monitoring app to the monitored app be
> appropriate, and then parse the response out for display in a browser? If
> so, what java class is likely to be useful for this communication? I will
> have all the information needed to connect to the application instance
> (server, port, etc), but want it to be portable across OS types.
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>