You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Viet Nguyen <vh...@gmail.com> on 2007/12/05 22:36:48 UTC
[DISCUSS] Moving the Monitoring Plugin Into Trunk
Hi All,
There has been a lot of work done on the monitoring plugin lately. I
think it is now time to move it from sandbox into trunk, in time for
the 2.1 release. I am unsure
of the timeline for 2.1, but I feel as though the monitoring plugin
should be moved to trunk around this time, so that the little kinks
can be worked out before it is
too late for the release. Erik and I have worked together along with
the help of many others to provide a monitoring collecting agent and
monitoring portlet.
To briefly go over what the monitoring plugin can do:
-monitor multiple servers
-securely connects to remote servers that are monitored (via MEJB and
encryption of the password using Geronimo's EncryptionManager)
-keeps an on going history of user-chosen statistics
-provides the ability to view current and past statistics
-customizable graphs (e.g. I can choose which stats I want to graph,
and much more)
-the ability to group certain graphs together into what we call a
"view." The idea is to allow an administrator to view only those
graphs that he cares about...all in one place!
-editable server, graphs, and views option
-provides the ability to keep track of any mbean that is declared as a
StatisticsProvider
-administrator can custom define the elapsed time period before each
snapshot is taken
-everything is packaged into plugins (separate plugins and a bundled
plugin with both pieces), so deploying is made easier
I hope that some of you can take some time to test out the plugin
which can be pulled from sandbox at
http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and
provide
some feedback. If there are no objections, I hope that a committer can
soon move the monitoring plugin into trunk. One of the new features
that I would like to see listed
for the 2.1 release is this monitoring plugin. I believe it will
attract a lot of attention and users.
Thanks,
Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Joe Bohn <jo...@earthlink.net>.
I think it would be great to get this in for 2.1. I agree that we
should get it in as soon as possible to smooth out any rough edges
before we deliver 2.1.
Joe
Viet Nguyen wrote:
> Hi All,
>
> There has been a lot of work done on the monitoring plugin lately. I
> think it is now time to move it from sandbox into trunk, in time for
> the 2.1 release. I am unsure
> of the timeline for 2.1, but I feel as though the monitoring plugin
> should be moved to trunk around this time, so that the little kinks
> can be worked out before it is
> too late for the release. Erik and I have worked together along with
> the help of many others to provide a monitoring collecting agent and
> monitoring portlet.
>
> To briefly go over what the monitoring plugin can do:
> -monitor multiple servers
> -securely connects to remote servers that are monitored (via MEJB and
> encryption of the password using Geronimo's EncryptionManager)
> -keeps an on going history of user-chosen statistics
> -provides the ability to view current and past statistics
> -customizable graphs (e.g. I can choose which stats I want to graph,
> and much more)
> -the ability to group certain graphs together into what we call a
> "view." The idea is to allow an administrator to view only those
> graphs that he cares about...all in one place!
> -editable server, graphs, and views option
> -provides the ability to keep track of any mbean that is declared as a
> StatisticsProvider
> -administrator can custom define the elapsed time period before each
> snapshot is taken
> -everything is packaged into plugins (separate plugins and a bundled
> plugin with both pieces), so deploying is made easier
>
> I hope that some of you can take some time to test out the plugin
> which can be pulled from sandbox at
> http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and
> provide
> some feedback. If there are no objections, I hope that a committer can
> soon move the monitoring plugin into trunk. One of the new features
> that I would like to see listed
> for the 2.1 release is this monitoring plugin. I believe it will
> attract a lot of attention and users.
>
> Thanks,
> Viet
>
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by "Erik B. Craig" <ec...@apache.org>.
+1
I am definitely in favor of this, and would also like to see this make
it to trunk before the 2.1 branch occurs.
It would be great if we could get a few extra pairs of eyes to take a
look at things and make sure it's all peachy.
Thanks,
Erik B. Craig
ecraig@apache.org
Viet Nguyen wrote:
> Hi All,
>
> There has been a lot of work done on the monitoring plugin lately. I
> think it is now time to move it from sandbox into trunk, in time for
> the 2.1 release. I am unsure
> of the timeline for 2.1, but I feel as though the monitoring plugin
> should be moved to trunk around this time, so that the little kinks
> can be worked out before it is
> too late for the release. Erik and I have worked together along with
> the help of many others to provide a monitoring collecting agent and
> monitoring portlet.
>
> To briefly go over what the monitoring plugin can do:
> -monitor multiple servers
> -securely connects to remote servers that are monitored (via MEJB and
> encryption of the password using Geronimo's EncryptionManager)
> -keeps an on going history of user-chosen statistics
> -provides the ability to view current and past statistics
> -customizable graphs (e.g. I can choose which stats I want to graph,
> and much more)
> -the ability to group certain graphs together into what we call a
> "view." The idea is to allow an administrator to view only those
> graphs that he cares about...all in one place!
> -editable server, graphs, and views option
> -provides the ability to keep track of any mbean that is declared as a
> StatisticsProvider
> -administrator can custom define the elapsed time period before each
> snapshot is taken
> -everything is packaged into plugins (separate plugins and a bundled
> plugin with both pieces), so deploying is made easier
>
> I hope that some of you can take some time to test out the plugin
> which can be pulled from sandbox at
> http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and
> provide
> some feedback. If there are no objections, I hope that a committer can
> soon move the monitoring plugin into trunk. One of the new features
> that I would like to see listed
> for the 2.1 release is this monitoring plugin. I believe it will
> attract a lot of attention and users.
>
> Thanks,
> Viet
>
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
+1
Jacek
On Dec 5, 2007 10:36 PM, Viet Nguyen <vh...@gmail.com> wrote:
> Hi All,
>
> There has been a lot of work done on the monitoring plugin lately. I
> think it is now time to move it from sandbox into trunk, in time for
> the 2.1 release. I am unsure
> of the timeline for 2.1, but I feel as though the monitoring plugin
> should be moved to trunk around this time, so that the little kinks
> can be worked out before it is
> too late for the release. Erik and I have worked together along with
> the help of many others to provide a monitoring collecting agent and
> monitoring portlet.
>
> To briefly go over what the monitoring plugin can do:
> -monitor multiple servers
> -securely connects to remote servers that are monitored (via MEJB and
> encryption of the password using Geronimo's EncryptionManager)
> -keeps an on going history of user-chosen statistics
> -provides the ability to view current and past statistics
> -customizable graphs (e.g. I can choose which stats I want to graph,
> and much more)
> -the ability to group certain graphs together into what we call a
> "view." The idea is to allow an administrator to view only those
> graphs that he cares about...all in one place!
> -editable server, graphs, and views option
> -provides the ability to keep track of any mbean that is declared as a
> StatisticsProvider
> -administrator can custom define the elapsed time period before each
> snapshot is taken
> -everything is packaged into plugins (separate plugins and a bundled
> plugin with both pieces), so deploying is made easier
>
> I hope that some of you can take some time to test out the plugin
> which can be pulled from sandbox at
> http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and
> provide
> some feedback. If there are no objections, I hope that a committer can
> soon move the monitoring plugin into trunk. One of the new features
> that I would like to see listed
> for the 2.1 release is this monitoring plugin. I believe it will
> attract a lot of attention and users.
>
> Thanks,
> Viet
>
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Jeff Genender <jg...@apache.org>.
Never mind...yes looks like MEJB is a requirement.
Jeff
Jeff Genender wrote:
> Isn't the JSR 77 spec JMX based?
>
> Jeff
>
> Viet Nguyen wrote:
>> Yes, with the current implementation we have, OpenEJB is a
>> prerequisite. JMX is a good solution too, but I wanted to follow the
>> JSR 77 spec, which tells us to communicate with the server through the
>> usage of MEJB, which is why OpenEJB is needed in this case.
>>
>> --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Jeff Genender <jg...@apache.org>.
Isn't the JSR 77 spec JMX based?
Jeff
Viet Nguyen wrote:
> Yes, with the current implementation we have, OpenEJB is a
> prerequisite. JMX is a good solution too, but I wanted to follow the
> JSR 77 spec, which tells us to communicate with the server through the
> usage of MEJB, which is why OpenEJB is needed in this case.
>
> --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
We definitely need such an adapter interface. This will allow us to
not corrupt the target instance, e.g. a minimal server, by installing
openejb.
Thanks
Anita
--- Jeff Genender <jg...@apache.org> wrote:
> So I think we are kind of caught in a catch 22 here...
>
> The issue is, the server is pluggable for the most part. People
> may/may
> not want EJB, but definitely want the management capabilities.
>
> Whats your thought on an adapter interface that provides for full
> JSR-77
> compatibility, thus requiring EJB, or a switch that allows for pure
> JMX
> remoting? This would allow for compliance or be able to leverage the
> management without EJB if so desired.
>
> Thoughts?
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Jeff Genender <jg...@apache.org>.
I certainly believe it deserves a spot in trunk...this is an enhancement
to what we don't have before. That's progress...and its pretty darn
cool too ;-)
I definitely don't want my ideas to hold up its movement...just food for
thought for down the road.
Jeff
Viet Nguyen wrote:
>> Whats your thought on an adapter interface that provides for full JSR-77
>> compatibility, thus requiring EJB, or a switch that allows for pure JMX
>> remoting? This would allow for compliance or be able to leverage the
>> management without EJB if so desired.
>>
>> Thoughts?
>
> There are goods and bads to both sides to this. If we strictly follow
> JSR 77, which means we will use MEJB and are forced to have OpenEJB as
> a pre-req, we won't have to worry if our architecture is good or not
> (I hope this is right), because we're following a standard for
> monitoring and management. On the flip side, if we use JMX to get a
> hold of the statistics, we will be able to monitor any type of server.
> Doesn't necessarily have to be a Geronimo server either, as long as we
> can connect to it via JMX, which I think is a huge plus.
>
> With that said, I think if we decide to take the alternative JMX path,
> it can be changed later (even though this was originally how we
> implemented it). I think the important thing now, is to determine
> whether or not the monitoring plugin merits a place in trunk.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Dec 6, 2007, at 12:45 PM, Viet Nguyen wrote:
> There are goods and bads to both sides to this. If we strictly follow
> JSR 77, which means we will use MEJB and are forced to have OpenEJB as
> a pre-req, we won't have to worry if our architecture is good or not
> (I hope this is right), because we're following a standard for
> monitoring and management. On the flip side, if we use JMX to get a
> hold of the statistics, we will be able to monitor any type of server.
I'm aware that some commercial servers make sure that they support
JSR-77 as they have to. Unfortunately, JSR-77 can be heavy and the
commercial servers, *they who must not be named*, use lighter weight
stuff under the covers and use their statistics for monitoring and
make JSR-77 available for those that want to code to it. JSR-77 is a
required implementation but not the only way to do it.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Viet Nguyen <vh...@gmail.com>.
> Whats your thought on an adapter interface that provides for full JSR-77
> compatibility, thus requiring EJB, or a switch that allows for pure JMX
> remoting? This would allow for compliance or be able to leverage the
> management without EJB if so desired.
>
> Thoughts?
There are goods and bads to both sides to this. If we strictly follow
JSR 77, which means we will use MEJB and are forced to have OpenEJB as
a pre-req, we won't have to worry if our architecture is good or not
(I hope this is right), because we're following a standard for
monitoring and management. On the flip side, if we use JMX to get a
hold of the statistics, we will be able to monitor any type of server.
Doesn't necessarily have to be a Geronimo server either, as long as we
can connect to it via JMX, which I think is a huge plus.
With that said, I think if we decide to take the alternative JMX path,
it can be changed later (even though this was originally how we
implemented it). I think the important thing now, is to determine
whether or not the monitoring plugin merits a place in trunk.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Jeff Genender <jg...@apache.org>.
So I think we are kind of caught in a catch 22 here...
The issue is, the server is pluggable for the most part. People may/may
not want EJB, but definitely want the management capabilities.
Whats your thought on an adapter interface that provides for full JSR-77
compatibility, thus requiring EJB, or a switch that allows for pure JMX
remoting? This would allow for compliance or be able to leverage the
management without EJB if so desired.
Thoughts?
Viet Nguyen wrote:
> Yes, with the current implementation we have, OpenEJB is a
> prerequisite. JMX is a good solution too, but I wanted to follow the
> JSR 77 spec, which tells us to communicate with the server through the
> usage of MEJB, which is why OpenEJB is needed in this case.
>
> --Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Viet Nguyen <vh...@gmail.com>.
Yes, with the current implementation we have, OpenEJB is a
prerequisite. JMX is a good solution too, but I wanted to follow the
JSR 77 spec, which tells us to communicate with the server through the
usage of MEJB, which is why OpenEJB is needed in this case.
--Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 6, 2007, at 1:27 AM, Viet Nguyen wrote:
> On Dec 5, 2007 9:23 PM, Kevan Miller <ke...@gmail.com> wrote:
>>
>> On Dec 5, 2007, at 9:07 PM, David Jencks wrote:
>>
>>>
>>> On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
>>>
>>>> Viet,
>>>> Thanks for working on the monitoring console. A lot still remains
>>>> to
>>>> be done. There are architectural issues which need to be addressed:
>>>> Currently the agent (aka mrc-server) needs to reside in same jvm
>>>> as
>>>> the server being monitored. It consumes significant DB resources.
>>>
>>> While this might not be ideal (I don't know one way or another) does
>>> this make it useless? I'd be in favor of getting something out
>>> with some useful functionality now, and improving it as it gets
>>> used.
>>
>> I tend to agree.
>>
>> I'd like to give it a whirl. Erik/Viet are the installation
>> instructions?
>
> The installation is pretty simple. Since everything is packaged into
> plugins there are two ways to do it.
> 1a. Just install the bundled (has both server and client) plugin....it
> is monitor-tomcat/monitor-jetty
> 1b. Install the client plugin on a monitoring machine and the
> mrc-server on the server to be monitored.
> 2. Then you add the server to the list of monitored machines via the
> portlet
>
>>
>> You mention MEJB connections. Can you help me understand where the
>> MEJB is running? The local server or the remote servers?
>
> The MEJB connections are done on the remote servers (those that are
> being monitored with the collecting agent). The collecting agent
> authenticates itself by having the client pass in the credentials.
> Then this collecting agent acts as the thin layer between the client
> and the MEJB, with additional functionality.
So, remote servers must have OpenEJB installed? Hmmm. It be really
nice to monitor any Geronimo server... Why aren't we using JMX?
Perhaps I'm missing something? If that's what we have, that's what we
have... Just trying to be sure I understand...
--kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Viet Nguyen <vh...@gmail.com>.
On Dec 5, 2007 9:23 PM, Kevan Miller <ke...@gmail.com> wrote:
>
> On Dec 5, 2007, at 9:07 PM, David Jencks wrote:
>
> >
> > On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
> >
> >> Viet,
> >> Thanks for working on the monitoring console. A lot still remains
> >> to
> >> be done. There are architectural issues which need to be addressed:
> >> Currently the agent (aka mrc-server) needs to reside in same jvm
> >> as
> >> the server being monitored. It consumes significant DB resources.
> >
> > While this might not be ideal (I don't know one way or another) does
> > this make it useless? I'd be in favor of getting something out
> > with some useful functionality now, and improving it as it gets used.
>
> I tend to agree.
>
> I'd like to give it a whirl. Erik/Viet are the installation
> instructions?
The installation is pretty simple. Since everything is packaged into
plugins there are two ways to do it.
1a. Just install the bundled (has both server and client) plugin....it
is monitor-tomcat/monitor-jetty
1b. Install the client plugin on a monitoring machine and the
mrc-server on the server to be monitored.
2. Then you add the server to the list of monitored machines via the portlet
>
> You mention MEJB connections. Can you help me understand where the
> MEJB is running? The local server or the remote servers?
The MEJB connections are done on the remote servers (those that are
being monitored with the collecting agent). The collecting agent
authenticates itself by having the client pass in the credentials.
Then this collecting agent acts as the thin layer between the client
and the MEJB, with additional functionality.
>
> --kevan
>
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 5, 2007, at 9:07 PM, David Jencks wrote:
>
> On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
>
>> Viet,
>> Thanks for working on the monitoring console. A lot still remains
>> to
>> be done. There are architectural issues which need to be addressed:
>> Currently the agent (aka mrc-server) needs to reside in same jvm
>> as
>> the server being monitored. It consumes significant DB resources.
>
> While this might not be ideal (I don't know one way or another) does
> this make it useless? I'd be in favor of getting something out
> with some useful functionality now, and improving it as it gets used.
I tend to agree.
I'd like to give it a whirl. Erik/Viet are the installation
instructions?
You mention MEJB connections. Can you help me understand where the
MEJB is running? The local server or the remote servers?
--kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Dec 6, 2007 5:43 AM, Anita Kulshreshtha <a_...@yahoo.com> wrote:
> Don't I get 24 hours to respond :)
Yes, you *did* ;-) It passed.
Seriously, I'm in favor releasing what we've got so far as that's the
best way to get people (end users and us) engaged in the development
process of the monitoring plugin. It's not ideal, but if there're
people who believe it serves well in some use cases let the puppy go
out and see the sun ;-)
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 5, 2007, at 11:43 PM, Anita Kulshreshtha wrote:
>
>>
>> Anita, can you please technically show why this is not ready or
>> should
>> not be released? Can you explain/show where the graphs are wrong?
>> This
>> may help move things along.
>>
>> Jeff
>
> Don't I get 24 hours to respond :)
We've got lot's of time to discuss. Jeff was just eager to understand
what your concerns are...
--kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
>
> Anita, can you please technically show why this is not ready or
> should
> not be released? Can you explain/show where the graphs are wrong?
> This
> may help move things along.
>
> Jeff
Don't I get 24 hours to respond :)
Thanks
Anita
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Jeff Genender <jg...@apache.org>.
David Jencks wrote:
>
> On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
>
>> Viet,
>> Thanks for working on the monitoring console. A lot still remains to
>> be done. There are architectural issues which need to be addressed:
>> Currently the agent (aka mrc-server) needs to reside in same jvm as
>> the server being monitored. It consumes significant DB resources.
>
> While this might not be ideal (I don't know one way or another) does
> this make it useless? I'd be in favor of getting something out with
> some useful functionality now, and improving it as it gets used.
>
I was going to say the same but you beat me to it.
+1 with your comment...new functionality is the way to go on this. This
is a huge step in the right direction and gives the user more power than
they had before. It may not be perfect but it certainly is wickedly
cool ;-)
Anita, can you please technically show why this is not ready or should
not be released? Can you explain/show where the graphs are wrong? This
may help move things along.
Jeff
> thanks
> david jencks
>
>> The Graph builder plots CountStatistics correctly. It does not
>> provide a way (minor point) to choose/plot both the raw count and the
>> throughput, i.e. count/sec. The graphs for TimeStatistics and
>> BoundedRangeStatistics are wrong. This is a serious shortcoming. I
>> would like it to be fixed before we can talk about releasing it.
>>
>> Thanks
>> Anita
>>
>> --- Viet Nguyen <vh...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> There has been a lot of work done on the monitoring plugin lately. I
>>> think it is now time to move it from sandbox into trunk, in time for
>>> the 2.1 release. I am unsure
>>> of the timeline for 2.1, but I feel as though the monitoring plugin
>>> should be moved to trunk around this time, so that the little kinks
>>> can be worked out before it is
>>> too late for the release. Erik and I have worked together along with
>>> the help of many others to provide a monitoring collecting agent and
>>> monitoring portlet.
>>>
>>> To briefly go over what the monitoring plugin can do:
>>> -monitor multiple servers
>>> -securely connects to remote servers that are monitored (via MEJB and
>>> encryption of the password using Geronimo's EncryptionManager)
>>> -keeps an on going history of user-chosen statistics
>>> -provides the ability to view current and past statistics
>>> -customizable graphs (e.g. I can choose which stats I want to graph,
>>> and much more)
>>> -the ability to group certain graphs together into what we call a
>>> "view." The idea is to allow an administrator to view only those
>>> graphs that he cares about...all in one place!
>>> -editable server, graphs, and views option
>>> -provides the ability to keep track of any mbean that is declared as
>>> a
>>> StatisticsProvider
>>> -administrator can custom define the elapsed time period before each
>>> snapshot is taken
>>> -everything is packaged into plugins (separate plugins and a bundled
>>> plugin with both pieces), so deploying is made easier
>>>
>>> I hope that some of you can take some time to test out the plugin
>>> which can be pulled from sandbox at
>>> http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and
>>> provide
>>> some feedback. If there are no objections, I hope that a committer
>>> can
>>> soon move the monitoring plugin into trunk. One of the new features
>>> that I would like to see listed
>>> for the 2.1 release is this monitoring plugin. I believe it will
>>> attract a lot of attention and users.
>>>
>>> Thanks,
>>> Viet
>>>
>>
>>
>>
>>
>> ____________________________________________________________________________________
>>
>> Looking for last minute shopping deals?
>> Find them fast with Yahoo! Search.
>> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by David Jencks <da...@yahoo.com>.
On Dec 5, 2007, at 4:29 PM, Anita Kulshreshtha wrote:
> Viet,
> Thanks for working on the monitoring console. A lot still
> remains to
> be done. There are architectural issues which need to be addressed:
> Currently the agent (aka mrc-server) needs to reside in same
> jvm as
> the server being monitored. It consumes significant DB resources.
While this might not be ideal (I don't know one way or another) does
this make it useless? I'd be in favor of getting something out with
some useful functionality now, and improving it as it gets used.
thanks
david jencks
> The Graph builder plots CountStatistics correctly. It does not
> provide a way (minor point) to choose/plot both the raw count and the
> throughput, i.e. count/sec. The graphs for TimeStatistics and
> BoundedRangeStatistics are wrong. This is a serious shortcoming. I
> would like it to be fixed before we can talk about releasing it.
>
> Thanks
> Anita
>
> --- Viet Nguyen <vh...@gmail.com> wrote:
>
>> Hi All,
>>
>> There has been a lot of work done on the monitoring plugin lately. I
>> think it is now time to move it from sandbox into trunk, in time for
>> the 2.1 release. I am unsure
>> of the timeline for 2.1, but I feel as though the monitoring plugin
>> should be moved to trunk around this time, so that the little kinks
>> can be worked out before it is
>> too late for the release. Erik and I have worked together along with
>> the help of many others to provide a monitoring collecting agent and
>> monitoring portlet.
>>
>> To briefly go over what the monitoring plugin can do:
>> -monitor multiple servers
>> -securely connects to remote servers that are monitored (via MEJB and
>> encryption of the password using Geronimo's EncryptionManager)
>> -keeps an on going history of user-chosen statistics
>> -provides the ability to view current and past statistics
>> -customizable graphs (e.g. I can choose which stats I want to graph,
>> and much more)
>> -the ability to group certain graphs together into what we call a
>> "view." The idea is to allow an administrator to view only those
>> graphs that he cares about...all in one place!
>> -editable server, graphs, and views option
>> -provides the ability to keep track of any mbean that is declared as
>> a
>> StatisticsProvider
>> -administrator can custom define the elapsed time period before each
>> snapshot is taken
>> -everything is packaged into plugins (separate plugins and a bundled
>> plugin with both pieces), so deploying is made easier
>>
>> I hope that some of you can take some time to test out the plugin
>> which can be pulled from sandbox at
>> http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and
>> provide
>> some feedback. If there are no objections, I hope that a committer
>> can
>> soon move the monitoring plugin into trunk. One of the new features
>> that I would like to see listed
>> for the 2.1 release is this monitoring plugin. I believe it will
>> attract a lot of attention and users.
>>
>> Thanks,
>> Viet
>>
>
>
>
>
> ______________________________________________________________________
> ______________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search. http://tools.search.yahoo.com/
> newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 6, 2007, at 12:01 PM, Viet Nguyen wrote:
> I am still unsure of why having the monitoring plugin in trunk is such
> a bad thing. It is in no way a perfect solution, but once it's in
> trunk we can engage users and other devs to better it. I do not see
> any dominating issues that should keep this plugin outside of trunk.
> Should we vote for this?
No we shouldn't vote... Not while we're discussing the issue. Possible
that there may be a vote later. Just as likely that we'll find a
consensus. Let's make sure we understand each other, first.
--kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Viet Nguyen <vh...@gmail.com>.
I am still unsure of why having the monitoring plugin in trunk is such
a bad thing. It is in no way a perfect solution, but once it's in
trunk we can engage users and other devs to better it. I do not see
any dominating issues that should keep this plugin outside of trunk.
Should we vote for this?
Viet
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by "Erik B. Craig" <ec...@apache.org>.
Kevan Miller wrote:
>
> OK. That's good information. But, IMO, that doesn't necessarily mean
> we shouldn't move the monitoring plugin out of sandbox. It might mean
> that we aren't ready to *release* the monitoring plugin. I don't think
> we're having a *release* discussion -- at least we shouldn't be. We
> can have the discussion that we don't want to hold up a Geronimo 2.1
> release waiting for monitoring plugin problems to be resolved, but I'd
> prefer we discuss without a particular timeline in mind...
>
> IMO, we have the following questions to answer:
>
> 1. Are we ready to move monitoring plugin out of sandbox?
Yes, I definitely believe so, although I might be marginally biased =P
> 2. If yes, then where should we move it to? Should it be in
> server/trunk/plugins or should the monitoring plugin be a subproject.
I was thinking server/trunk/plugins myself... the only other option
would be just straight plugins... however, correct me if I'm wrong on
this, but I believe just /plugins is more for things that can be used
independent of geronimo... which is definitely not the case for the
monitoring plugin currently.
> 3. What bug fixes/new features need to be added to the monitoring
> plugin before it's ready to be released?
The single biggest thing on my mind for this currently is the new
graphing engine that I mentioned, but whether or not it's part of
server/trunk/plugins has no bearing on this getting done.
>
> Anita,
> Your objections seem to be in category 3, but I may be wrong. So, help
> us understand what you're thinking...
>
> --kevan
>
Thanks,
Erik B. Craig
ecraig@apache.org
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by David Jencks <da...@yahoo.com>.
On Dec 6, 2007, at 10:06 AM, Paul McMahan wrote:
>
> On Dec 6, 2007, at 12:45 PM, Kevan Miller wrote:
>
>> 1. Are we ready to move monitoring plugin out of sandbox?
> +1
>
>> 2. If yes, then where should we move it to? Should it be in server/
>> trunk/plugins or should the monitoring plugin be a subproject.
> I would vote for server/trunk/plugins, if for no other reason than
> to synchronize the monitoring plugin release with the server
> release. When the plugin gets to be more mature and can support
> multiple versions of geronimo then maybe we would consider moving
> it to a separate subproject. Also, moving it to trunk ensures that
> it will be included in the plugin catalog (~/.m2/repo/geronimo-
> plugins.xml) when you build trunk and will make it very easy to add
> monitoring to an assembly by just editing that assembly's pom.
I don't have a strong opinion yet on where this should go, but I'd
like to point out that any plugin you build with the car-maven-
plugin, such as the roller or apacheds plugins, will have its
metadata added to your local maven repo's geronimo-plugins.xml
catalog. Similarly, no matter where the plugin is in svn, you can
add it to a maven-built assembly by editing the assemblies pom.
thanks
david jencks
>
>> 3. What bug fixes/new features need to be added to the monitoring
>> plugin before it's ready to be released?
> I agree with Anita that it will need some testing & feedback before
> releasing to the wild. IMO the best way to facilitate that type of
> exposure is to move it into trunk. I think that this new
> monitoring feature is important enough to justify holding up a 2.1
> release if it actually comes down to that.
>
>
> Best wishes,
> Paul
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Paul McMahan <pa...@gmail.com>.
On Dec 6, 2007, at 12:45 PM, Kevan Miller wrote:
> 1. Are we ready to move monitoring plugin out of sandbox?
+1
> 2. If yes, then where should we move it to? Should it be in server/
> trunk/plugins or should the monitoring plugin be a subproject.
I would vote for server/trunk/plugins, if for no other reason than
to synchronize the monitoring plugin release with the server
release. When the plugin gets to be more mature and can support
multiple versions of geronimo then maybe we would consider moving it
to a separate subproject. Also, moving it to trunk ensures that it
will be included in the plugin catalog (~/.m2/repo/geronimo-
plugins.xml) when you build trunk and will make it very easy to add
monitoring to an assembly by just editing that assembly's pom.
> 3. What bug fixes/new features need to be added to the monitoring
> plugin before it's ready to be released?
I agree with Anita that it will need some testing & feedback before
releasing to the wild. IMO the best way to facilitate that type of
exposure is to move it into trunk. I think that this new monitoring
feature is important enough to justify holding up a 2.1 release if it
actually comes down to that.
Best wishes,
Paul
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Prasad Kashyap <go...@gmail.com>.
I'm with Matt on this. Since it is not perfect to everybody's
satisfaction, let us move it to the /plugins tree (at least for now).
Sandbox is definitely not the place for it.
Erik, contrary to your belief, the /plugins tree does not contain only
those plugins that work independent of G. It *mostly* contains
plugins that integrate independent projects (like Liferay, ApacheDS,
roller etc) with G. Now the monitoring plugin does not actually fit
that bill. Neverthless, that is still a step above sandbox, and still
on the road to trunk/plugins. It can still be released with 2.1 and
still available in the plugins catalog for possible installation.
Cheers
Prasad
On Dec 8, 2007 12:00 AM, Matt Hogstrom <ma...@hogstrom.org> wrote:
>
> On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:
>
> >> 2. If yes, then where should we move it to? Should it be in server/
> >> trunk/plugins or should the monitoring plugin be a subproject.
> >
> > I was thinking of plugins..
>
> I'm not sure it really matters where the code goes in the interim.
> Plugins makes sense but I would move it to trunk first. Trunk is
> certainly viable and would likely get more people to look at the code,
> report issues, and most likely ooh and awe about cool looking graphs
> and statistics.
>
> If it turns out that the monitoring bloats the server in an
> unacceptable way, has incorrect statistics or consumes too many
> resources then I would think that moving it to plugins would be a
> reasonable approach.
>
>
>
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Jeff Genender <jg...@apache.org>.
Matt Hogstrom wrote:
> I think the correct decision would be what do
> the users want in terms of it being an integral part of what they do
> they would prefer to not go and install it but have it as part of the
> base install. I'd be ok with either approach. Most AppServers that I
> know of do ship their project with some minimal level of monitoring.
> Perhaps that is the JMXViewer. Although, I'd personally prefer the GUI
> of the console over the viewer but that is personal preferece.
+1...these are my sentiments as well.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Dec 10, 2007, at 8:25 AM, Anita Kulshreshtha wrote:
> I see Monitoring Console as a tool, a standard J2EE Application,
> that has been packaged for a convenient installation in Geronimo. It
> talks to a geronimo specific agent to discover and monitor a geronimo
> instance running elsewhere. I do not see it as an integral part of G,
> and hence prefer /plugins. Its location in svn does not affect the
> convenience of using it. It will always be installed from 'plugins'
> portlet and will be visible as an available plugin.
> But that is just my opinion..
You make a good point. I think the correct decision would be what do
the users want in terms of it being an integral part of what they do
they would prefer to not go and install it but have it as part of the
base install. I'd be ok with either approach. Most AppServers that I
know of do ship their project with some minimal level of monitoring.
Perhaps that is the JMXViewer. Although, I'd personally prefer the
GUI of the console over the viewer but that is personal preferece.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Dec 10, 2007, at 7:18 AM, Jeff Genender wrote:
>
>
> Anita Kulshreshtha wrote:
>> I see Monitoring Console as a tool, a standard J2EE Application,
>> that has been packaged for a convenient installation in Geronimo. It
>> talks to a geronimo specific agent to discover and monitor a geronimo
>> instance running elsewhere. I do not see it as an integral part of G,
>> and hence prefer /plugins. Its location in svn does not affect the
>> convenience of using it. It will always be installed from 'plugins'
>> portlet and will be visible as an available plugin.
>
> IMHO, it should definitely be a plugin (as should everything we ship),
> but I think it should be a plugin that is installed by default. As
> pointed out in another email, monitoring is typically shipped and
> active
> in some form for most other application servers. If most of the users
> find it helpful to have automatically enabled, then its probably good
> that we do so. I would probably suggest as we get closer to a release
> date that we get more input from users on this subject so we can
> make a
> proper and informed decision.
This reflects my sentiments as well.
Regards,
Alan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
--- Jeff Genender <jg...@apache.org> wrote:
>
>
> Anita Kulshreshtha wrote:
> > I see Monitoring Console as a tool, a standard J2EE
> Application,
> > that has been packaged for a convenient installation in Geronimo.
> It
> > talks to a geronimo specific agent to discover and monitor a
> geronimo
> > instance running elsewhere. I do not see it as an integral part of
> G,
> > and hence prefer /plugins. Its location in svn does not affect the
> > convenience of using it. It will always be installed from 'plugins'
> > portlet and will be visible as an available plugin.
>
> IMHO, it should definitely be a plugin (as should everything we
> ship),
> but I think it should be a plugin that is installed by default.
I hear y'all :) If the plugin has to be installed by default,
server/trunk/plugin is the best place for it. I will be moving it
to server/trunk/plugin/monitoring/mconsole and
server/trunk/plugin/monitoring/agent
Viet has been working on fixing problems discussed elsewhere in
this thread. It will be wired into the main build when it is fairly
stable.
Thanks
Anita
As
> pointed out in another email, monitoring is typically shipped and
> active
> in some form for most other application servers. If most of the
> users
> find it helpful to have automatically enabled, then its probably good
> that we do so. I would probably suggest as we get closer to a
> release
> date that we get more input from users on this subject so we can make
> a
> proper and informed decision.
>
> Jeff
>
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Jeff Genender <jg...@apache.org>.
Anita Kulshreshtha wrote:
> I see Monitoring Console as a tool, a standard J2EE Application,
> that has been packaged for a convenient installation in Geronimo. It
> talks to a geronimo specific agent to discover and monitor a geronimo
> instance running elsewhere. I do not see it as an integral part of G,
> and hence prefer /plugins. Its location in svn does not affect the
> convenience of using it. It will always be installed from 'plugins'
> portlet and will be visible as an available plugin.
IMHO, it should definitely be a plugin (as should everything we ship),
but I think it should be a plugin that is installed by default. As
pointed out in another email, monitoring is typically shipped and active
in some form for most other application servers. If most of the users
find it helpful to have automatically enabled, then its probably good
that we do so. I would probably suggest as we get closer to a release
date that we get more input from users on this subject so we can make a
proper and informed decision.
Jeff
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
--- Matt Hogstrom <ma...@hogstrom.org> wrote:
>
> On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:
>
> >> 2. If yes, then where should we move it to? Should it be in
> server/
> >> trunk/plugins or should the monitoring plugin be a subproject.
> >
> > I was thinking of plugins..
>
> I'm not sure it really matters where the code goes in the interim.
> Plugins makes sense but I would move it to trunk first. Trunk is
> certainly viable and would likely get more people to look at the
> code,
> report issues, and most likely ooh and awe about cool looking graphs
>
> and statistics.
>
> If it turns out that the monitoring bloats the server in an
> unacceptable way, has incorrect statistics or consumes too many
> resources then I would think that moving it to plugins would be a
> reasonable approach.
I see Monitoring Console as a tool, a standard J2EE Application,
that has been packaged for a convenient installation in Geronimo. It
talks to a geronimo specific agent to discover and monitor a geronimo
instance running elsewhere. I do not see it as an integral part of G,
and hence prefer /plugins. Its location in svn does not affect the
convenience of using it. It will always be installed from 'plugins'
portlet and will be visible as an available plugin.
But that is just my opinion..
Thanks
Anita
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:
>> 2. If yes, then where should we move it to? Should it be in server/
>> trunk/plugins or should the monitoring plugin be a subproject.
>
> I was thinking of plugins..
I'm not sure it really matters where the code goes in the interim.
Plugins makes sense but I would move it to trunk first. Trunk is
certainly viable and would likely get more people to look at the code,
report issues, and most likely ooh and awe about cool looking graphs
and statistics.
If it turns out that the monitoring bloats the server in an
unacceptable way, has incorrect statistics or consumes too many
resources then I would think that moving it to plugins would be a
reasonable approach.
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 7, 2007, at 9:11 AM, Anita Kulshreshtha wrote:
>
> --- Kevan Miller <ke...@gmail.com> wrote:
>
>>
>> On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote:
>>
>>>
>>> --- Viet Nguyen <vh...@gmail.com> wrote:
>>>
>>>> On Dec 5, 2007 11:36 PM, Anita Kulshreshtha <a_...@yahoo.com>
>>>> wrote:
>>>>> Eric,
> .................................................
>>>
>>> Perhaps I am not making it clear. The graph that is shown as
>>> requestTime for tomcatWebConnector is incorrect. The value returned
>> by
>>> tomcat is count not time. We need to have different methods to
>>> generate
>>> graphs for TimeStatistics, RangeStatistics, and
>>> BoundedRangeStatistics.
>>
>> OK. That's good information.
>
> But a very important one for a user who takes the trouble to install
> the plugins and reads the document about monitoring and statistics.
>
> But, IMO, that doesn't necessarily mean
>>
>> we shouldn't move the monitoring plugin out of sandbox. It might mean
>>
>> that we aren't ready to *release* the monitoring plugin. I don't
>> think
>> we're having a *release* discussion -- at least we shouldn't be.
>
> If the plugin is moved to trunk, as the title of the discussion
> says, does it not get automatically released?
It would be released *when* we release the code in trunk (in this case
with Geronimo 2.1). Until we release, it's under development just like
the rest of the server (and subject to change).
>
>
> We
>> can have the discussion that we don't want to hold up a Geronimo 2.1
>>
>> release waiting for monitoring plugin problems to be resolved, but
>> I'd
>> prefer we discuss without a particular timeline in mind...
>>
>> IMO, we have the following questions to answer:
>>
>> 1. Are we ready to move monitoring plugin out of sandbox?
>
> yes
>
>> 2. If yes, then where should we move it to? Should it be in server/
>> trunk/plugins or should the monitoring plugin be a subproject.
>
> I was thinking of plugins..
>
>> 3. What bug fixes/new features need to be added to the monitoring
>> plugin before it's ready to be released?
>
> We should do the minimum and make sure all the information that is
> displayed is correct, i.e. there is no discrepancy between the raw
> value (displayed on the console) and the graph. We can address the
> fact
> the values themselves are skewed later.
OK. Sounds good. I see you've been generating jira's against the admin
console. I assume they are recording the functions that need to be
fixed?
--kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
--- Kevan Miller <ke...@gmail.com> wrote:
>
> On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote:
>
> >
> > --- Viet Nguyen <vh...@gmail.com> wrote:
> >
> >> On Dec 5, 2007 11:36 PM, Anita Kulshreshtha <a_...@yahoo.com>
> >> wrote:
> >>> Eric,
.................................................
> >
> > Perhaps I am not making it clear. The graph that is shown as
> > requestTime for tomcatWebConnector is incorrect. The value returned
> by
> > tomcat is count not time. We need to have different methods to
> > generate
> > graphs for TimeStatistics, RangeStatistics, and
> > BoundedRangeStatistics.
>
> OK. That's good information.
But a very important one for a user who takes the trouble to install
the plugins and reads the document about monitoring and statistics.
But, IMO, that doesn't necessarily mean
>
> we shouldn't move the monitoring plugin out of sandbox. It might mean
>
> that we aren't ready to *release* the monitoring plugin. I don't
> think
> we're having a *release* discussion -- at least we shouldn't be.
If the plugin is moved to trunk, as the title of the discussion
says, does it not get automatically released?
We
> can have the discussion that we don't want to hold up a Geronimo 2.1
>
> release waiting for monitoring plugin problems to be resolved, but
> I'd
> prefer we discuss without a particular timeline in mind...
>
> IMO, we have the following questions to answer:
>
> 1. Are we ready to move monitoring plugin out of sandbox?
yes
> 2. If yes, then where should we move it to? Should it be in server/
> trunk/plugins or should the monitoring plugin be a subproject.
I was thinking of plugins..
> 3. What bug fixes/new features need to be added to the monitoring
> plugin before it's ready to be released?
We should do the minimum and make sure all the information that is
displayed is correct, i.e. there is no discrepancy between the raw
value (displayed on the console) and the graph. We can address the fact
the values themselves are skewed later.
Thanks
Anita
>
> Anita,
> Your objections seem to be in category 3, but I may be wrong. So,
> help
> us understand what you're thinking...
>
> --kevan
>
>
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 6, 2007, at 7:38 AM, Anita Kulshreshtha wrote:
>
> --- Viet Nguyen <vh...@gmail.com> wrote:
>
>> On Dec 5, 2007 11:36 PM, Anita Kulshreshtha <a_...@yahoo.com>
>> wrote:
>>> Eric,
>>> For this discussion I will use MC for monitoring console (aka
>>> client), and agent for mrc-server. It is possible to use 3 G
>> instances
>>> (I used this method until GERONIMO-3660). G1 with MC on remote or
>> local
>>> m/c, G2 with agent on local m/c, and G3 the instance to be
>> monitored.
>>> This is the ideal solution but will be most difficult to implement
>>> efficiently. The advantage is that the instance to be monitored is
>> not
>>> corrupted in any way.
>>> The second option is to use 2 G instances. G1 with MC on
>> remote or
>>> local m/c, G2 the instance to be monitored. The agent is loaded in
>> G2.
>>> This is what we have now. we need to reduce DB activity. We can
>> improve
>>> upon this as we go.
>>> The TimeSatistics has 4 values named count, max, min and
>> totaltime.
>>> The graph treats count as the current value of time. This is
>> because
>>> the information that it is a TimeStatistics is lost in the DB. All
>> four
>>> values appear as separate statistics, and the graph would draw each
>> one
>>> separately as value, min, max! The same is true for
>>> BoundedRangeStatistics. A single graph should show all 5 values.
>>> More inline..
>> The current implementation only allows for one statistic to be shown
>> at a time on a graph, but if you wanted to have the max or min
>> statistics that could be easily obtained since those numbers are
>> there. I think allowing the admin to graph all 4 values on the same
>> graph is a very useful feature and should definitely be added;
>> However, this is not necessarily a stop ship issue.
>
> Perhaps I am not making it clear. The graph that is shown as
> requestTime for tomcatWebConnector is incorrect. The value returned by
> tomcat is count not time. We need to have different methods to
> generate
> graphs for TimeStatistics, RangeStatistics, and
> BoundedRangeStatistics.
OK. That's good information. But, IMO, that doesn't necessarily mean
we shouldn't move the monitoring plugin out of sandbox. It might mean
that we aren't ready to *release* the monitoring plugin. I don't think
we're having a *release* discussion -- at least we shouldn't be. We
can have the discussion that we don't want to hold up a Geronimo 2.1
release waiting for monitoring plugin problems to be resolved, but I'd
prefer we discuss without a particular timeline in mind...
IMO, we have the following questions to answer:
1. Are we ready to move monitoring plugin out of sandbox?
2. If yes, then where should we move it to? Should it be in server/
trunk/plugins or should the monitoring plugin be a subproject.
3. What bug fixes/new features need to be added to the monitoring
plugin before it's ready to be released?
Anita,
Your objections seem to be in category 3, but I may be wrong. So, help
us understand what you're thinking...
--kevan
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
--- Viet Nguyen <vh...@gmail.com> wrote:
> On Dec 5, 2007 11:36 PM, Anita Kulshreshtha <a_...@yahoo.com>
> wrote:
> > Eric,
> > For this discussion I will use MC for monitoring console (aka
> > client), and agent for mrc-server. It is possible to use 3 G
> instances
> > (I used this method until GERONIMO-3660). G1 with MC on remote or
> local
> > m/c, G2 with agent on local m/c, and G3 the instance to be
> monitored.
> > This is the ideal solution but will be most difficult to implement
> > efficiently. The advantage is that the instance to be monitored is
> not
> > corrupted in any way.
> > The second option is to use 2 G instances. G1 with MC on
> remote or
> > local m/c, G2 the instance to be monitored. The agent is loaded in
> G2.
> > This is what we have now. we need to reduce DB activity. We can
> improve
> > upon this as we go.
> > The TimeSatistics has 4 values named count, max, min and
> totaltime.
> > The graph treats count as the current value of time. This is
> because
> > the information that it is a TimeStatistics is lost in the DB. All
> four
> > values appear as separate statistics, and the graph would draw each
> one
> > separately as value, min, max! The same is true for
> > BoundedRangeStatistics. A single graph should show all 5 values.
> > More inline..
> The current implementation only allows for one statistic to be shown
> at a time on a graph, but if you wanted to have the max or min
> statistics that could be easily obtained since those numbers are
> there. I think allowing the admin to graph all 4 values on the same
> graph is a very useful feature and should definitely be added;
> However, this is not necessarily a stop ship issue.
Perhaps I am not making it clear. The graph that is shown as
requestTime for tomcatWebConnector is incorrect. The value returned by
tomcat is count not time. We need to have different methods to generate
graphs for TimeStatistics, RangeStatistics, and BoundedRangeStatistics.
Thanks
Anita
> >
> >
> > --- "Erik B. Craig" <ec...@apache.org> wrote:
> >
> > > Anita,
> > > You mentioned that the collecting agent running within the same
> jvm
> > > (I.E. under a Geronimo instance being monitored as a plugin) is
> an
> > > issue due to resource consumption... however I am unsure what a
> good
> > >
> > > alternative approach would be? Are you suggesting we have a
> separate
> > >
> > > instance of G to monitor a target instance? Or are you suggesting
> > > that
> > > the mrc-server be a standalone java app that runs in it's own
> JVM?
> >
> > This is a possibility too..
> > >
> > > Currently the graph builder will plot any data being grabbed as
> > > snapshots in any method defined by the user. In the current graph
> > > creation page, the user has the option to differentiate between
> raw
> > > count vs. count/time or even count/some other count. There are a
> lot
> > >
> > > of options configurable by the user.
> > When I added ErrorCount and ErrorCount/sec graphs to a single
> view,
> > The other views got corrupted. This is a minor issue and can be
> easily
> > fixed.
> >
> > Thanks
> > Anita
> >
> > >
> > > Additionally... do you have an example of the graphs for
> > > TimeStatistics or BoundedRangeStatistics being wrong/how they are
> > > wrong?
> > >
> > >
> >
> >
> >
> >
> >
>
____________________________________________________________________________________
> > Looking for last minute shopping deals?
> > Find them fast with Yahoo! Search.
>
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
> >
>
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Viet Nguyen <vh...@gmail.com>.
On Dec 5, 2007 11:36 PM, Anita Kulshreshtha <a_...@yahoo.com> wrote:
> Eric,
> For this discussion I will use MC for monitoring console (aka
> client), and agent for mrc-server. It is possible to use 3 G instances
> (I used this method until GERONIMO-3660). G1 with MC on remote or local
> m/c, G2 with agent on local m/c, and G3 the instance to be monitored.
> This is the ideal solution but will be most difficult to implement
> efficiently. The advantage is that the instance to be monitored is not
> corrupted in any way.
> The second option is to use 2 G instances. G1 with MC on remote or
> local m/c, G2 the instance to be monitored. The agent is loaded in G2.
> This is what we have now. we need to reduce DB activity. We can improve
> upon this as we go.
> The TimeSatistics has 4 values named count, max, min and totaltime.
> The graph treats count as the current value of time. This is because
> the information that it is a TimeStatistics is lost in the DB. All four
> values appear as separate statistics, and the graph would draw each one
> separately as value, min, max! The same is true for
> BoundedRangeStatistics. A single graph should show all 5 values.
> More inline..
The current implementation only allows for one statistic to be shown
at a time on a graph, but if you wanted to have the max or min
statistics that could be easily obtained since those numbers are
there. I think allowing the admin to graph all 4 values on the same
graph is a very useful feature and should definitely be added;
However, this is not necessarily a stop ship issue.
>
>
> --- "Erik B. Craig" <ec...@apache.org> wrote:
>
> > Anita,
> > You mentioned that the collecting agent running within the same jvm
> > (I.E. under a Geronimo instance being monitored as a plugin) is an
> > issue due to resource consumption... however I am unsure what a good
> >
> > alternative approach would be? Are you suggesting we have a separate
> >
> > instance of G to monitor a target instance? Or are you suggesting
> > that
> > the mrc-server be a standalone java app that runs in it's own JVM?
>
> This is a possibility too..
> >
> > Currently the graph builder will plot any data being grabbed as
> > snapshots in any method defined by the user. In the current graph
> > creation page, the user has the option to differentiate between raw
> > count vs. count/time or even count/some other count. There are a lot
> >
> > of options configurable by the user.
> When I added ErrorCount and ErrorCount/sec graphs to a single view,
> The other views got corrupted. This is a minor issue and can be easily
> fixed.
>
> Thanks
> Anita
>
> >
> > Additionally... do you have an example of the graphs for
> > TimeStatistics or BoundedRangeStatistics being wrong/how they are
> > wrong?
> >
> >
>
>
>
>
> ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
Eric,
For this discussion I will use MC for monitoring console (aka
client), and agent for mrc-server. It is possible to use 3 G instances
(I used this method until GERONIMO-3660). G1 with MC on remote or local
m/c, G2 with agent on local m/c, and G3 the instance to be monitored.
This is the ideal solution but will be most difficult to implement
efficiently. The advantage is that the instance to be monitored is not
corrupted in any way.
The second option is to use 2 G instances. G1 with MC on remote or
local m/c, G2 the instance to be monitored. The agent is loaded in G2.
This is what we have now. we need to reduce DB activity. We can improve
upon this as we go.
The TimeSatistics has 4 values named count, max, min and totaltime.
The graph treats count as the current value of time. This is because
the information that it is a TimeStatistics is lost in the DB. All four
values appear as separate statistics, and the graph would draw each one
separately as value, min, max! The same is true for
BoundedRangeStatistics. A single graph should show all 5 values.
More inline..
--- "Erik B. Craig" <ec...@apache.org> wrote:
> Anita,
> You mentioned that the collecting agent running within the same jvm
> (I.E. under a Geronimo instance being monitored as a plugin) is an
> issue due to resource consumption... however I am unsure what a good
>
> alternative approach would be? Are you suggesting we have a separate
>
> instance of G to monitor a target instance? Or are you suggesting
> that
> the mrc-server be a standalone java app that runs in it's own JVM?
This is a possibility too..
>
> Currently the graph builder will plot any data being grabbed as
> snapshots in any method defined by the user. In the current graph
> creation page, the user has the option to differentiate between raw
> count vs. count/time or even count/some other count. There are a lot
>
> of options configurable by the user.
When I added ErrorCount and ErrorCount/sec graphs to a single view,
The other views got corrupted. This is a minor issue and can be easily
fixed.
Thanks
Anita
>
> Additionally... do you have an example of the graphs for
> TimeStatistics or BoundedRangeStatistics being wrong/how they are
> wrong?
>
>
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by "Erik B. Craig" <ec...@apache.org>.
Anita,
You mentioned that the collecting agent running within the same jvm
(I.E. under a Geronimo instance being monitored as a plugin) is an
issue due to resource consumption... however I am unsure what a good
alternative approach would be? Are you suggesting we have a separate
instance of G to monitor a target instance? Or are you suggesting that
the mrc-server be a standalone java app that runs in it's own JVM?
Currently the graph builder will plot any data being grabbed as
snapshots in any method defined by the user. In the current graph
creation page, the user has the option to differentiate between raw
count vs. count/time or even count/some other count. There are a lot
of options configurable by the user.
Additionally... do you have an example of the graphs for
TimeStatistics or BoundedRangeStatistics being wrong/how they are wrong?
On Dec 5, 2007, at 7:29 PM, Anita Kulshreshtha wrote:
> Viet,
> Thanks for working on the monitoring console. A lot still remains to
> be done. There are architectural issues which need to be addressed:
> Currently the agent (aka mrc-server) needs to reside in same jvm as
> the server being monitored. It consumes significant DB resources.
> The Graph builder plots CountStatistics correctly. It does not
> provide a way (minor point) to choose/plot both the raw count and the
> throughput, i.e. count/sec. The graphs for TimeStatistics and
> BoundedRangeStatistics are wrong. This is a serious shortcoming. I
> would like it to be fixed before we can talk about releasing it.
>
> Thanks
> Anita
>
> --- Viet Nguyen <vh...@gmail.com> wrote:
>
>> Hi All,
>>
>> There has been a lot of work done on the monitoring plugin lately. I
>> think it is now time to move it from sandbox into trunk, in time for
>> the 2.1 release. I am unsure
>> of the timeline for 2.1, but I feel as though the monitoring plugin
>> should be moved to trunk around this time, so that the little kinks
>> can be worked out before it is
>> too late for the release. Erik and I have worked together along with
>> the help of many others to provide a monitoring collecting agent and
>> monitoring portlet.
>>
>> To briefly go over what the monitoring plugin can do:
>> -monitor multiple servers
>> -securely connects to remote servers that are monitored (via MEJB and
>> encryption of the password using Geronimo's EncryptionManager)
>> -keeps an on going history of user-chosen statistics
>> -provides the ability to view current and past statistics
>> -customizable graphs (e.g. I can choose which stats I want to graph,
>> and much more)
>> -the ability to group certain graphs together into what we call a
>> "view." The idea is to allow an administrator to view only those
>> graphs that he cares about...all in one place!
>> -editable server, graphs, and views option
>> -provides the ability to keep track of any mbean that is declared as
>> a
>> StatisticsProvider
>> -administrator can custom define the elapsed time period before each
>> snapshot is taken
>> -everything is packaged into plugins (separate plugins and a bundled
>> plugin with both pieces), so deploying is made easier
>>
>> I hope that some of you can take some time to test out the plugin
>> which can be pulled from sandbox at
>> http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and
>> provide
>> some feedback. If there are no objections, I hope that a committer
>> can
>> soon move the monitoring plugin into trunk. One of the new features
>> that I would like to see listed
>> for the 2.1 release is this monitoring plugin. I believe it will
>> attract a lot of attention and users.
>>
>> Thanks,
>> Viet
>>
>
>
>
>
> ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [DISCUSS] Moving the Monitoring Plugin Into Trunk
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
Viet,
Thanks for working on the monitoring console. A lot still remains to
be done. There are architectural issues which need to be addressed:
Currently the agent (aka mrc-server) needs to reside in same jvm as
the server being monitored. It consumes significant DB resources.
The Graph builder plots CountStatistics correctly. It does not
provide a way (minor point) to choose/plot both the raw count and the
throughput, i.e. count/sec. The graphs for TimeStatistics and
BoundedRangeStatistics are wrong. This is a serious shortcoming. I
would like it to be fixed before we can talk about releasing it.
Thanks
Anita
--- Viet Nguyen <vh...@gmail.com> wrote:
> Hi All,
>
> There has been a lot of work done on the monitoring plugin lately. I
> think it is now time to move it from sandbox into trunk, in time for
> the 2.1 release. I am unsure
> of the timeline for 2.1, but I feel as though the monitoring plugin
> should be moved to trunk around this time, so that the little kinks
> can be worked out before it is
> too late for the release. Erik and I have worked together along with
> the help of many others to provide a monitoring collecting agent and
> monitoring portlet.
>
> To briefly go over what the monitoring plugin can do:
> -monitor multiple servers
> -securely connects to remote servers that are monitored (via MEJB and
> encryption of the password using Geronimo's EncryptionManager)
> -keeps an on going history of user-chosen statistics
> -provides the ability to view current and past statistics
> -customizable graphs (e.g. I can choose which stats I want to graph,
> and much more)
> -the ability to group certain graphs together into what we call a
> "view." The idea is to allow an administrator to view only those
> graphs that he cares about...all in one place!
> -editable server, graphs, and views option
> -provides the ability to keep track of any mbean that is declared as
> a
> StatisticsProvider
> -administrator can custom define the elapsed time period before each
> snapshot is taken
> -everything is packaged into plugins (separate plugins and a bundled
> plugin with both pieces), so deploying is made easier
>
> I hope that some of you can take some time to test out the plugin
> which can be pulled from sandbox at
> http://svn.apache.org/repos/asf/geronimo/sandbox/monitoring and
> provide
> some feedback. If there are no objections, I hope that a committer
> can
> soon move the monitoring plugin into trunk. One of the new features
> that I would like to see listed
> for the 2.1 release is this monitoring plugin. I believe it will
> attract a lot of attention and users.
>
> Thanks,
> Viet
>
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping