|This is of course useful as well but not quite what I was after. I'm more
|interested in being able to plug in a monitor to a "live" system, to be
|able to easily visualize which parts of the system take up the most
|execution time, which users/groups are accessing them and how often, and
|break it down to application/bean or even method level. This should allow
|the admin/developer to identify the parts of the system that should be
|considered for increased optimization and find potential bottlenecks. I
|think it's valuable to be able to monitor a deployed application in its
|normal usage scenario. This is something you will want to do if you plan on
|hosting services, for example.
right on. Hosting services ala loudcloud rely on a "metrics" layer that can
enable them to diagnose their installation.
As you move to "preventive" automated management as opposed to "reactive"
human management this is needed.
what do I mean? reactive is "my, slow response time from our clients... huh
the machine is down, what is going on? send someone"... that is human
intensive and doesn't scale AT ALL. It is OK for small IT operations
though.
Preventive is "hey, an event was raised that the load on this application is
going above the limit of 3seconds per invocation" that means we need to fire
an email to the guy owning the machine so he can purchase a couple more.
This can be done automatically and solve problems before they occur. A must
in ASP/ISP settings imho.
This is the direction we want to go in. There won't be **any** competition
there, due to price policies :))))
Metrics and management, both automated, are the key to that
marc
|
|Anyhow, there are probably more than one part of the architecture that can
|publish interesting results to the same metrics topic. Invocation layer was
|just the most obvious one so I decided to give it a shot first.
|
|-- Juha
|
|
|>
|>/Rickard
|>
|>--
|>Rickard �berg
|>
|>Email: [EMAIL PROTECTED]
|>http://www.telkel.com
|>http://www.jboss.org
|>http://www.dreambean.com
|>
|>
|
|
|
