4:46 a.m.
Hi,
as you know we now have shiny new RHQ / JBossON 2 as management
solution of the next century (Ok, I'll stop :-)
Seriously: we can monitor the "bare metal" aspects of running
applications. But I can imagine that it would be
very helpful to go even further and monitor the actual application.
Things like (examples)
- what is the average value of a shopping cart
- how many users are choosing which path in a navigation flow
- how long did a specific action take
- ...
In order to accomplish this, the writer of an application needs to
determine what data he wants from which place. I can imagine
additional annotations like e.g. @Timing on method level to initiate
the data gathering. Seam could then
compute the timing for that method and provide it in some means to
management applications (e.g. in a database table or
Mbean attribute or ...), from where a management application like RHQ
could pick it up.
What do you think?
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
5:23 a.m.
Hi Heiko
We currently having nothing at all like this in Seam, and I think it
could be very useful.
It sounds like this should be a separate jboss-seam-management library
you could deploy inside your app to provide this functionality. This
could define a public API which the management tool could use to
retrieve the management data. It could also optionally persist this
info to a database.
I think we need to get some concrete use cases together to get an idea
of the kind of data a user would want to collect and see how much
impact this would have on the core code.
On 1 Jul 2008, at 10:46, Heiko W.Rupp wrote:
Hi,
as you know we now have shiny new RHQ / JBossON 2 as management
solution of the next century (Ok, I'll stop :-)
Seriously: we can monitor the "bare metal" aspects of running
applications. But I can imagine that it would be
very helpful to go even further and monitor the actual application.
Things like (examples)
- what is the average value of a shopping cart
- how many users are choosing which path in a navigation flow
- how long did a specific action take
- ...
In order to accomplish this, the writer of an application needs to
determine what data he wants from which place. I can imagine
additional annotations like e.g. @Timing on method level to initiate
the data gathering. Seam could then
compute the timing for that method and provide it in some means to
management applications (e.g. in a database table or
Mbean attribute or ...), from where a management application like
RHQ could pick it up.
What do you think?
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei
Muenchen
Handelsregister: Amtsgericht Muenchen HRB 153243
Geschaeftsfuehrer: Brendan Lane, Charlie Peters, Michael Cunningham,
Werner Knoblich
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
9:23 a.m.
Pete,
We currently having nothing at all like this in Seam, and I think
it could be very useful.
Fine :-)
It sounds like this should be a separate jboss-seam-management
library you could deploy inside your app to provide this
Exactly. My initial mail was to start this thought process.
functionality. This could define a public API which the management
tool could use to retrieve the management data. It could also
optionally persist this info to a database.
Yes. We need to be able to determine where the data ends up (in some
deployment descriptor), so that it could work
in environments without database or where the user wants the data in
a different place. I am also not yet completely sure what the best
way for JBossON/RHQ is to gather the data. DB tables sure are
I think we need to get some concrete use cases together to get an
idea of the kind of data a user would want to collect and see how
much impact this would have on the core code.
I definitively see at least two metrics (keyed by the place where
they are applied or some explicit key):
- timing of a method
- count of using some code path
The other thing that I did not mention in my first email is that
JBossON/RHQ also has the possibility to edit config files from a
central location or invoke operations on resources - there might be
some usecases for this as well.
Heiko
10:35 a.m.
> functionality. This could define a public API which the management
> tool could use to retrieve the management data. It could also
> optionally persist this info to a database.
Yes. We need to be able to determine where the data ends up (in some
deployment descriptor), so that it could work
in environments without database or where the user wants the data in a
different place. I am also not yet completely sure what the best way
for JBossON/RHQ is to gather the data. DB tables sure are
Hello,
this slightly touches the idea, I proposed when discussing the
FragmentCache implementation (which I still haven't finished - sorry for
this).
What I did write was a Seam component where any other component can
register a statistic generator. When I want to print statistics of my
application,
I just call this central component and it will call all registered
statistic generator. In that case there are just normal Cache statistics.
I already played around to register the component as a normal JMX to
allow using it with the JMXConsole.
This is a inverse approach as compared to your idea (pulling of
statistics) as opposed to pushing it somewhere (in memory or database).
Still IMHO we should define a common approach here.
Any kind of statistics could be interesting - Response Time, Number of
dialogs, average dialogs per session, ...
Best Regards
Sebastian
1:17 p.m.
Hi,
> Still IMHO we should define a common approach here.
> Any kind of statistics could be interesting - Response
Time, Number
> of dialogs, average dialogs per session, ...
Yeah.
From my point of view (being not too Seam-savvy) it is important
that this stuff is easy to add to an
application to be usable.
The other thing to keep in mind is that Resources that get identified
within the application need to have
an unique key. For metrics, we can define "static" ones meaning that
those are some that are always present
(e.g. stuff like cache hits of a global seam-like cache or average
time spent in the seam interceptors or such).
And then we can have "dynamic" metrics in the sense that they get
determined at runtime like we currently to
for http response time data (this is keyed by the Url where the key
does not need to be known at compile
time).
Heiko
I already played around to register the component as a normal JMX
to allow using it with the JMXConsole.
This is a inverse approach as compared to your idea (pulling of
statistics) as opposed to pushing it somewhere (in memory or
database).
Not really. JBossON / RHQ can read stuff like logfiles, but for
measurement purposes, this is not optimal.
So putting the data into an MBean from where we regularly pull it, is
pretty ok. And with JavaSE5+ having an
MBeanServer in it, this could even be a general approach.
9:06 a.m.
Heiko W.Rupp schrieb:
Hi,
>
> I already played around to register the component as a normal JMX to
> allow using it with the JMXConsole.
>
> This is a inverse approach as compared to your idea (pulling of
> statistics) as opposed to pushing it somewhere (in memory or database).
Not really. JBossON / RHQ can read stuff like logfiles, but for
measurement purposes, this is not optimal.
So putting the data into an MBean from where we regularly pull it, is
pretty ok. And with JavaSE5+ having an
MBeanServer in it, this could even be a general approach.
MBean seams a reasonable
approach, it is quite simple to setup and we
could create a kind of management package in seam where all kind of
mbeans to inform or to manage a seam app are packaged.
From my point of view (being not too Seam-savvy) it is important that
this stuff is easy to add to an
application to be usable.
The other thing to keep in mind is that Resources that get identified
within the application need to have
an unique key. For metrics, we can define "static" ones meaning that
those are some that are always present
(e.g. stuff like cache hits of a global seam-like cache or average time
spent in the seam interceptors or such).
And then we can have "dynamic" metrics in the sense that they get
determined at runtime like we currently to
for http response time data (this is keyed by the Url where the key does
not need to be known at compile
time).
Heiko
Do you want to have real data or reports (as a simple String) for your
JON? I assume real data, as you can place rules etc in JON to react.
In that case, will you create a kind of stub for every metric MBean we
provide or do we need a generic approach, where we define something like:
name: response time
data type: long
A generic approach (as always) requires a larger effort.
Could you provide some use cases, what you want to pull, regularly or
once, raw data (response time) or 'manufactured' data (e.g. average
response time).
Best Regards
Sebastian
5965
days inactive
5979
days old
5 comments
3 participants
participants (3)
-
Heiko W.Rupp -
Pete Muir -
Sebastian Hennebrueder