tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aurélien Terrestris <>
Subject Re: Monitoring Connections
Date Wed, 04 Nov 2015 08:25:26 GMT
Hi Chris

I still recommend SNMP, maybe I expressed myself incorrectly but Java SNMP
support is made for monitoring. I also provided a bad link, here is the
good one :

When using the right server, the SNMP will also provide alerting, both for
counters and deltas. This is the critical point for large scale teams with
N1 support, although developers often want something else and need more
(logs, instrumentation).

In "Effective Monitoring and Alerting, O'Reilly" we find these definitions
that we already agree, I believe :

"The main purpose of monitoring is to gain near real-time insight into the
current state of the system, in the context of its recent performance"

"The core functionality of an alarm is to trigger on detection of abnormal
timeseries behavior, but the alerting system should also support the
aggregation and conditional suppression of alarms."

In my opinion, SNMP could be more used, and I notice that nobody is talking
about this technology for years on the mailing-list. It's a pity to ignore

best regards

2015-11-03 16:05 GMT+01:00 Christopher Schultz <

> Aurelien,
> On 11/2/15 5:54 PM, Aurélien Terrestris wrote:
> > Either my reply was not read, or I'm surprised nobody is answering here.
> >
> > "1. Java doesn't directly support SNMP;"
> >
> > It does, officially :
> > management/snmp.html and it's working pretty well with Tomcat besides
> being
> > easy to set up.
> I meant there was no client API
> > "2. If the JVM is braindead, the SNMP agent can't announce any state   to
> > the managers."
> >
> > Agent ? This is the SNMP server which is polling the Tomcat here. When
> > Tomcat is dead, the server cannot poll anymore and raises an alert.
> You were recommending the use of SNMP as an "alerting" alternative to
> "monitoring". I assumed you had meant that more passive "alerting" (e.g.
> only take action when a problem is occurring) was more efficient than
> "monitoring" (which I took to mean polling a service to check its status).
> So polling is less efficient but more reliable. Whether you use SNMP,
> JMX, HTTP, or whatever, *polling* a component is better than having a
> component try to report that it's failing, because part of the failure
> could be its inability to report the failure state.
> This isn't about SNMP versus some other technology. It's about probing
> versus ... not doing so, I guess.
> > You see how alerting is even easier without instrumenting, but maybe you
> > want to go deeper. But then, you probably start mixing what's necessary
> for
> > N1 support with what's helpful for developers. They have different jobs.
> What is your definition of "instrumentation"? What about "probing" or
> "alerting"? I'm certainly confused with your use of terms, especially
> when you equate one of them with a particular technology.
> -chris
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message