I only have two requests... 1) make the interface/page/whatever easily queried (via Perl preferably) and 2)make it part of the standard jboss distribution.
For monitoring I'm going to want to write a plugin for whatever monitoring tool I use in order to collect statistical information as well as detect status (I'll be happy to write/contribute one for NetSaint). Brian Macy Rhett Aultman wrote: > 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 > > > >N???޵隊X???'???u???)??Y?\?g?????????Á¿??b?H zG(?? %?,?ׯzZ)??홨??x%??In?,u?Þ–?fz{e??l???q???z?m????X???(?? ~??zw??X?????b?????,?ׯzZ)??? ------------------------------------------------------- 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
