tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jamie Jackson <jamieja...@gmail.com>
Subject Re: Monitoring Connections
Date Wed, 04 Nov 2015 16:59:39 GMT
By the way, I had to back-burner this investigation due to other things
that have come up. When those are out of the way, I'll pick up where I left
off. Thanks for the discussion so far.

(I don't know anything about SNMP, etc., so I'm only following that thread
very loosely until I have time to concentrate on it.)

On Wed, Nov 4, 2015 at 3:25 AM, Aurélien Terrestris <aterrestris@gmail.com>
wrote:

> 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 :
> http://docs.oracle.com/javase/7/docs/technotes/guides/management/snmp.html
>
> 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
> solutions.
>
>
> best regards
>
>
>
>
> 2015-11-03 16:05 GMT+01:00 Christopher Schultz <
> chris@christopherschultz.net
> >:
>
> > 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 :
> > http://docs.oracle.com/javase/7/docs/technotes/guides/
> > > 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: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>

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