| Interface | Description | 
|---|---|
| CounterMonitorMBean | Exposes the remote management interface of the counter monitor MBean. | 
| GaugeMonitorMBean | Exposes the remote management interface of the gauge monitor MBean. | 
| MonitorMBean | Exposes the remote management interface of monitor MBeans. | 
| StringMonitorMBean | Exposes the remote management interface of the string monitor MBean. | 
| Class | Description | 
|---|---|
| CounterMonitor | Defines a monitor MBean designed to observe the values of a counter
 attribute. | 
| GaugeMonitor | Defines a monitor MBean designed to observe the values of a gauge attribute. | 
| Monitor | Defines the part common to all monitor MBeans. | 
| MonitorNotification | Provides definitions of the notifications sent by monitor MBeans. | 
| StringMonitor | Defines a monitor MBean designed to observe the values of a string
 attribute. | 
| Exception | Description | 
|---|---|
| MonitorSettingException | Exception thrown by the monitor when a monitor setting becomes invalid while the monitor is running. | 
Provides the definition of the monitor classes.  A Monitor is
      an MBean that periodically observes the value of an attribute in
      one or more other MBeans.  If the attribute meets a certain
      condition, the Monitor emits a MonitorNotification. When the monitor MBean periodically calls
      getAttribute
      to retrieve the value of the attribute being monitored it does
      so within the access control context of the
      Monitor.start() caller.
The value being monitored can be a simple value
      contained within a complex type. For example, the MemoryMXBean defined in
      java.lang.management has an attribute
      HeapMemoryUsage of type MemoryUsage. To monitor the
      amount of used memory, described by the used
      property of MemoryUsage, you could monitor
      "HeapMemoryUsage.used". That string would be the
      argument to setObservedAttribute.
The rules used to interpret an ObservedAttribute like "HeapMemoryUsage.used" are as follows. Suppose the string is A.e (so A would be "HeapMemoryUsage" and e would be "used" in the example).
First the value of the attribute A is obtained. Call it v. A value x is extracted from v as follows:
CompositeData and if v.get(e)
      returns a value then x is that value.Introspector.getBeanInfo, for the class of v 
      (v.getClass()) identifies a property with the name 
      e, then x is the result of reading the property value. The third rule means for example that if the attribute HeapMemoryUsage is a MemoryUsage, monitoring "HeapMemoryUsage.used" will obtain the observed value by calling MemoryUsage.getUsed().
If the ObservedAttribute contains more than one period, for example "ConnectionPool.connectionStats.length", then the above rules are applied iteratively. Here, v would initially be the value of the attribute ConnectionPool, and x would be derived by applying the above rules with e equal to "connectionStats". Then v would be set to this x and a new x derived by applying the rules again with e equal to "length".
Although it is recommended that attribute names be valid Java
      identifiers, it is possible for an attribute to be called
      HeapMemoryUsage.used. This means that an
      ObservedAttribute that is HeapMemoryUsage.used
      could mean that the value to observe is either an attribute of that
      name, or the property used within an attribute called
      HeapMemoryUsage. So for compatibility reasons, when the
      ObservedAttribute contains a period (.), the monitor
      will check whether an attribute exists whose name is the full
      ObservedAttribute string (HeapMemoryUsage.used in the
      example). It does this by calling getMBeanInfo for the observed MBean and looking for a contained MBeanAttributeInfo with the given
      name. If one is found, then that is what is monitored. If more than one
      MBean is being observed, the behavior is unspecified if some of them have
      a HeapMemoryUsage.used attribute and others do not. An
      implementation may therefore call getMBeanInfo on just one of
      the MBeans in this case. The behavior is also unspecified if the result
      of the check changes while the monitor is active.
The exact behavior of monitors is detailed in the JMX Specification. What follows is a summary.
There are three kinds of Monitors:
A CounterMonitor observes attributes of integer
            type.  The attributes are assumed to be non-negative, and
            monotonically increasing except for a possible
            roll-over at a specified modulus.  Each
            observed attribute has an associated threshold
            value.  A notification is sent when the attribute exceeds
            its threshold.
An offset value can be specified. When an observed value exceeds its threshold, the threshold is incremented by the offset, or by a multiple of the offset sufficient to make the threshold greater than the new observed value.
A CounterMonitor can operate in
            difference mode.  In this mode, the value
            compared against the threshold is the difference between
            two successive observations of an attribute.
A GaugeMonitor observes attributes of numerical type.  Each
            observed attribute has an associated high
              threshold and low threshold.
When an observed attribute crosses the high threshold, if the notify high flag is true, then a notification is sent. Subsequent crossings of the high threshold value will not trigger further notifications until the gauge value becomes less than or equal to the low threshold.
When an observed attribute crosses the low threshold, if the notify low flag is true, then a notification is sent. Subsequent crossings of the low threshold value will not trigger further notifications until the gauge value becomes greater than or equal to the high threshold.
Typically, only one of the notify high and notify low flags is set. The other threshold is used to provide a hysteresis mechanism to avoid the repeated triggering of notifications when an attribute makes small oscillations around the threshold value.
A GaugeMonitor can operate in difference
              mode.  In this mode, the value compared against the
            high and low thresholds is the difference between two
            successive observations of an attribute.
A StringMonitor observes attributes of type
            String.  A notification is sent when an
            observed attribute becomes equal and/or not equal to a
            given string.
 Submit a bug or feature 
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
 Copyright © 1993, 2025, Oracle and/or its affiliates.  All rights reserved. Use is subject to license terms. Also see the documentation redistribution policy.