Complete information, including everything in tpstats, is available for your monitoring systems via JMX. For production clusters, it is essential you at least collect the JMX stats, if not alarm on various problems (such as backed up stages).
b On Wed, Sep 22, 2010 at 6:47 AM, Carl Bruecken <carl.bruec...@corp.aol.com> wrote: > On 9/22/10 9:37 AM, Jonathan Ellis wrote: >> >> it's easy to tell from tpstats which stage(s) are overloaded >> >> On Wed, Sep 22, 2010 at 8:29 AM, Carl Bruecken >> <carl.bruec...@corp.aol.com> wrote: >>> >>> With current implementation, it's impossible to tell from logs what the >>> message types (verb) were dropped. I read this was changed for spamming, >>> but I think the behavior should be configurable, either aggregate counts >>> of >>> dropped messages or log individual occurrences with the message verb. >>> >>> One suggestion is to pass message into >>> MessagingService.incrementDroppedMessages and have a configuration item >>> or >>> system property indicate the behavior. >>> >> >> > It's generally transient/bursty. By the time I get around to checking > tpstats the active/pending counts are all back to 0 and I have no record as > to what occured. >
