+1
Le mer. 12 févr. 2020 à 12:01, Tellier Benoit a
écrit :
> Then an admin might miss the original log, if out of it's browsing window.
>
> However I agree the log could be done at a lower pace:
> - Check every minute, log directly upon status change
> - Otherwise re-log current status every 3
Then an admin might miss the original log, if out of it's browsing window.
However I agree the log could be done at a lower pace:
- Check every minute, log directly upon status change
- Otherwise re-log current status every 30 minutes
On 12/02/2020 17:48, Antoine Duprat wrote:
> Shouldn't it be
Shouldn't it be more logic to log only status changes ?
I mean, if you are in a degraded state, you will log the same thing each
minute else if you have fixed the issue.
Le mer. 12 févr. 2020 à 11:43, Tellier Benoit a
écrit :
> +1
>
> We should make this happen.
>
> On 12/02/2020 17:29, Matthie
+1
We should make this happen.
On 12/02/2020 17:29, Matthieu Baechler wrote:
> On Wed, 2020-02-12 at 16:27 +0700, Tellier Benoit wrote:
>
>> - Through grafana, the admin will have the information directly
>> available. Nowaday, health-checks requires her to execute the
>> healthcheck via webadm
On Wed, 2020-02-12 at 16:27 +0700, Tellier Benoit wrote:
> - Through grafana, the admin will have the information directly
> available. Nowaday, health-checks requires her to execute the
> healthcheck via webadmin. More actions is generally the best way of
> having none of them taken.
>
I just
Hello all,
Recently, as part of our work documenting Administration Procedures for
the Distributed Guice James product, we are having some reflections
regarding the way to conduct monitoring, which undertook some nice
discussions.
Currently, monitoring of `mailbox event processing` and `mail
Gautier DI FOLCO created JAMES-2673:
---
Summary: Monitoring via logging document is out-of-date
Key: JAMES-2673
URL: https://issues.apache.org/jira/browse/JAMES-2673
Project: James Server
JAMES-1868 Enable JMX monitoring for metrics via Guice
Project: http://git-wip-us.apache.org/repos/asf/james-project/repo
Commit: http://git-wip-us.apache.org/repos/asf/james-project/commit/ff1f8e99
Tree: http://git-wip-us.apache.org/repos/asf/james-project/tree/ff1f8e99
Diff: http://git-wip
he existing metrics we already have?
>>> http://james.apache.org/server/3/monitor-jmx.html
>>> How do you see them integrated?
>>> We'd better not stay with multiple monitoring systems.
It does support JMX exporting:
http://jetm.void.fm/howto/jmx_registration.html. I
/
Bye,
Norman
2012/5/11 Eric Charles:
Also, did you look at the existing metrics we already have?
http://james.apache.org/server/3/monitor-jmx.html
How do you see them integrated?
We'd better not stay with multiple monitoring systems.
We also need to document this new feature (optional or not
Metrics is also a nice one:
http://metrics.codahale.com/
Bye,
Norman
2012/5/11 Eric Charles :
> Also, did you look at the existing metrics we already have?
> http://james.apache.org/server/3/monitor-jmx.html
> How do you see them integrated?
> We'd better not stay with mu
Also, did you look at the existing metrics we already have?
http://james.apache.org/server/3/monitor-jmx.html
How do you see them integrated?
We'd better not stay with multiple monitoring systems.
We also need to document this new feature (optional or not, how to
configure to enable, di
d off pretty easily.
Servo needs annotations, which is not code, and the start of a server,
which can be made optional by configuration.
JMX monitoring is more powerful than what jetm offers. If needed we
can provide jetm as an optional package since we can externalize it
into a config file and
e alternative/better solutions.
You are right, but since nobody was against it and it required minimal
intrusion I decided to go for it.
I will be more verbose in the future.
As a note, servo also requires to write some code while jetm doesn't
so it can be turned off pretty easily.
JMX monitor
ive/better solutions.
Thx,
Eric
[1] http://techblog.netflix.com/2012/02/announcing-servo.html
On 05/10/2012 03:22 PM, Ioan Eugen Stan wrote:
Hi,
I've committed the changes needed to add jetm performance monitoring.
It uses Spring AOP and can be enabled/ disa bled by configuration for
eve
Hi,
I've committed the changes needed to add jetm performance monitoring.
It uses Spring AOP and can be enabled/ disa bled by configuration for
every bean that we create.
The project home-page shows some stuff that you can do with it:
http://jetm.void.fm/views/monitoring_examples.html
It
[
https://issues.apache.org/jira/browse/MAILBOX-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ioan Eugen Stan resolved MAILBOX-152.
-
Resolution: Duplicate
> JETM performance monitor
[
https://issues.apache.org/jira/browse/JAMESAPP-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ioan Eugen Stan resolved JAMESAPP-9.
Resolution: Fixed
> JETM performance monitor
[
https://issues.apache.org/jira/browse/JAMESAPP-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272312#comment-13272312
]
Ioan Eugen Stan commented on JAMESAPP-9:
You can view monitoring result on
Ioan Eugen Stan created JAMESAPP-9:
--
Summary: JETM performance monitoring
Key: JAMESAPP-9
URL: https://issues.apache.org/jira/browse/JAMESAPP-9
Project: JAMES App
Issue Type: New Feature
[
https://issues.apache.org/jira/browse/MAILBOX-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ioan Eugen Stan updated MAILBOX-152:
Component/s: jpa mailbox
jcr mailbox
> JETM performance monitor
JETM performance monitoring
---
Key: MAILBOX-152
URL: https://issues.apache.org/jira/browse/MAILBOX-152
Project: James Mailbox
Issue Type: New Feature
Components: hbase, maildir mailbox, spring
Affects
Author: eric
Date: Tue Apr 5 14:48:36 2011
New Revision: 1089068
URL: http://svn.apache.org/viewvc?rev=1089068&view=rev
Log:
Add JMX metrics image (JAMES-1219)
Added:
james/server/trunk/src/site/resources/images/jmx-monitoring/jmx-org.apache.james.smtpserver.JamesDataCmdHandler
site/resources/images/dns_mx/
james/server/trunk/src/site/resources/images/jmx-management/
- copied from r1031965,
james/server/trunk/src/site/resources/images/jmx_management/
james/server/trunk/src/site/resources/images/jmx-monitoring/
- copied from r1031965,
james/server/trunk
honorable gentlemen suggested to "add more JMX monitoring for our
> internal resources" (which I gues could mean everything from DNS cache
> sizes to SMTP connections per minute).
>
> I think that is a good idea.
>
> Because my administrator's fantasy is limited
ol to help sysadmin in
sizings.
Stefano
Bernd Fondermann wrote:
Hi,
Some honorable gentlemen suggested to "add more JMX monitoring for our
internal resources" (which I gues could mean everything from DNS cache
sizes to SMTP connections per minute).
I think that is a go
Hi,
Some honorable gentlemen suggested to "add more JMX monitoring for our
internal resources" (which I gues could mean everything from DNS cache
sizes to SMTP connections per minute).
I think that is a good idea.
Because my administrator's fantasy is limited due to the la
> Can you layout the differences for those of us who haven't
> spent as much time looking at this as you?
Sure. But how long do you think I've been looking at it ? (rhetorical)
;)
> From what you are saying, if a monitor has a metric that
> isn't filled in by a service, it sits empty. And if
Steve Short wrote:
> > I thought, from Chapter 8 of the JMX (JSR 77) specification
> > that SNMP is supported directly by JMX.
> There's a difference between JMX and JSR 77. JMX is the basic
> management API and is covered by JSR 3.
> JSR 77 is for management of the J2EE platform. It does includ
Noel,
> I thought, from Chapter 8 of the JMX (JSR 77) specification
> that SNMP is supported directly by JMX.
There's a difference between JMX and JSR 77. JMX is the basic
management API and is covered by JSR 3. It does not include any remote
access capability at all, it does allow for remote a
Steve,
I don't know JMX well enough yet, but your proposal seems good. The only
thing I would like for you to clarify comes from:
> Eventually we could provide several implementations of the
> service one for JMX, one for SNMP.
I thought, from Chapter 8 of the JMX (JSR 77) specification that SN
Guys,
Shall I go ahead with this or not? I need to be working on this for our
product this week and I'd really like to contribute to James.
Steve
> -Original Message-
> From: Steve Short
> Sent: Friday, December 05, 2003 4:26 PM
> To: James Developers List
> Su
- Original Message -
From: Steve Short <[EMAIL PROTECTED]>
Sent: Dec 5, 9:26 AM
>
> The only decent usable LGPL one I've found is Joesnmp, which is
> currently part of the Opennms project but is in the process of becoming
> an independent project at Sourceforge.
A previous company I wo
Steve Short wrote:
As far as JMX is concerned the root kernel is already MBean
enabled and is an active event generator (reflecting changes
to kernel state).
What still needs to be done is the exposure (via the kernel)
of the subsidiary applicance mbeans - but more internal event
structure
Alex Karasulu wrote:
Yes this is the next critical step. I think everyone at
Avalon would be in favor of this since it has surprisingly
become the basis for IoC in the J2EE container world.
Yes, I'm all for it as Noel says! Once the repo release is
complete is suspect this is the next priorit
Noel J. Bergman wrote:
Stephen J. McConnell wrote:
Right now I'm in the process of pulling together the next release of
Merlin. The main *feature* of the new release will be a much cleaning
embedding strategy based on a bunch of improvements from Alex (Apache
Directory Project).
If
Sent: Friday, December 05, 2003 10:13 AM
> To: James Developers List
> Subject: RE: Monitoring
>
>
> > The Monitor service would be exposed via JMX (automatically
> thanks to
> > Phoenix and hopefully Merlin).
>
> > The monitor service configuration would
nts for management.
But I don't see anything in Chapter 6 (Performance Monitoring) to indicate
that the event mechanism is expected to be used for metric gathering. The
specification talk about the external side of the Stats and
StatisticsProvider interf
o you say Steve?
Alex
> -Original Message-
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 05, 2003 1:53 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; James Developers List
> Subject: RE: Monitoring
>
> Stephen J. McConnell wrote
> As far as JMX is concerned the root kernel is already MBean
> enabled and is an active event generator (reflecting changes
> to kernel state).
> What still needs to be done is the exposure (via the kernel)
> of the subsidiary applicance mbeans - but more internal event
> structure is needed
Stephen J. McConnell wrote:
> Right now I'm in the process of pulling together the next release of
> Merlin. The main *feature* of the new release will be a much cleaning
> embedding strategy based on a bunch of improvements from Alex (Apache
> Directory Project).
> If you or other have thoughts
> Sent: Friday, December 05, 2003 10:13 AM
> To: James Developers List
> Subject: RE: Monitoring
>
>
> > The Monitor service would be exposed via JMX (automatically
> thanks to
> > Phoenix and hopefully Merlin).
>
> > The monitor service configuration would
Noel J. Bergman wrote:
The Monitor service would be exposed via JMX (automatically
thanks to Phoenix and hopefully Merlin).
The monitor service configuration would allow declaration of
groups and act as a factory for other components that wish
to be monitored.
My suggestion would be
Steve Short wrote:
I can do it using JMX calls but if Stephen
McConnell is reading - please treat this as a feature request for
Merlin's JMX implemtation.
I'm reading ;-)
Right now I'm in the process of pulling together the next release of
Merlin. The main *feature* of the new release will be
> The Monitor service would be exposed via JMX (automatically
> thanks to Phoenix and hopefully Merlin).
> The monitor service configuration would allow declaration of
> groups and act as a factory for other components that wish
> to be monitored.
My suggestion would be to use JNDI for this purpo
P OIDs to attributes within MBean instances. No prizes for guessing
where I'm going with this! However my knowledge of SNMP is severely
limited and I need to find out more about how JMX SNMP adaptors are
expected to behave before doing any more on this front.
Back to Monitoring in James. I was t
Steve Short wrote:
I've been taking a look at what it would take to add some monitoring to
James.
I'm very interested in SNMP w/Java in general, but not particularly
James. Do you have a library in mind to use it? I remember finding one
or two poorly-maintained projects, and I thi
> I've been taking a look at what it would take to add some monitoring to
> James.
> So does it seem to the members of this list like a good idea to base
> James monitoring on these basic structures?
Without doing more than scanning the rfc it looks like a good idea.
Perha
James does have rudimentary JMX support at the moment, thanks to Avalon.
What James really needs is instrumentation points (or whatever) in the
code so whatever monitoring framework we use we can get useful data out.
However I think the implementing some of the RFC 2789 structures would
be a good
I've been taking a look at what it would take to add some monitoring to
James. I think it would be useful to base James monitoring on the SNMP
MTA MIB as defined in RFC 2789
(http://www.ietf.org/rfc/rfc2789.txt?number=2789). I'll briefly
summarise the data structures defined
50 matches
Mail list logo
