Gaaa! I swore up, down, and sideways I'd have an MBean written for that, and I've
just had a really bad run in my personal time that's kept me from it. I'm trying to
get that packaged up this weekend.
-----Original Message-----
From: Michael Bartmann [mailto:[EMAIL PROTECTED]]
Sent: Sat 9/21/2002 8:49 AM
To: [EMAIL PROTECTED]
Cc:
Subject: [JBoss-dev] Health monitoring
Everybody heathy?
If you operate a 24*7 production plant with a server like JBoss,
you shurely care about the "health" of your server. Now in theory
this is nearly trivial: we have JMX and friends.
Any kind of monitoring can be done with it, but do we do? Of course
a lot of aspects are application specific, and for the rest of it
you may like to pull myserver:8080/jmx-console.
I still have some - trivial - thoughts about what could be done on the
server side to faciliate things; and I post my thoughts here to
collect some of your opinions on this (you care about health, do you?).
1) Threadcount
For me this is more or less a linux problem, allthough I found
questionable things even on NT4. The problem is that the current
thread count reported by the JVM is garbage. The best thing i can think
of is traversing the threaddump and counting threads on the fly.
2) Thread usage
If you are not an expert on every single part of JBoss, it might be
a detectives work to find out where all those nice threads in the
threaddump come from.
This is even more criticall, as we migrate to centrally managed thread
pools, where its more easy to do it wrong (not naming them appropriate).
Thread creation (and even pooling) doesn't come at no cost. I think
it might be affordable to do some more bookkeeping (factory?)
about how and when and from which part of the system (stacktrace?)
threads get allocated. This information - if accessible via JMX - should
give you a warm feeling.
3) Memory usage
I don't understand much of the JVM heap structure but I know of tools
(e.g. JProbe) which which can provide you with information about each
and every living object on the heap. These tools do at least use the
JVM debugging API, I don't know if they need modified native classes
to do so. If you do know, please let me know.
4) History
The current JBoss measures for counting threads and memory usage don't
keep a history about thread usage in the past. With a monitoring tool
online all the time we could solve the problem on the client side.
It should be trivial to support this through a collection MBean on the
server side. The interesting part comes with the persitence of this
information? What to do after some crash (out of memory)?
Perhaps log4j is the solution? Or do you favor database storage?
(Even that could be done with log4j and appropriate Logger/Appender setup.
5) Caches, pools and such
I would prefer more control on caches, pools and containers. If everything
is "done right" (with SoftReferences?) we should not fear out of memory due
to bad configuration.
But as I noticed on this list these aspects are on the TODO for Matrix2
anyway.
Ok, just me 2c, curious about what you think,
Michael Bartmann
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
^){([8bAzE&z
y!yޞm)r[ zٚXX^hgX( ~zwilqzlX)ߣۢ z
