Applications deployed on Fabric3 can take advantage of an its built-in injection-based monitoring and logging frameworkframework for logging and recording application events. The monitoring framework offers a number of benefits:
- Strongly-typed monitoring interfaces and eventsEvent-based monitoring
- High performance logging (millions of events per second) with no garbage creation for latency-sensitive appications
- Dynamic event level adjustment
Using Monitoring
To use the monitoring framework in application code, do the following: defining a monitor interface and injecting the monitor in a component.
Define a Monitoring Interface.
The monitoring interface is used for sending monitoring events. The interface defines expected events and monitoring levels using methods on the interface:
...
import org.fabric3.api.annotation.monitor.Severe;
import org.fabric3.api.annotation.monitor.Debug;
public inteface ComponentMonitor
@Severe
void error(String message, Throwable t);
@Debug ("Received request {0}")
void receivedRequest(String id);
}
The above interface defines an error event and a debug event. The debug event also specifies a formatted message that will be logged if the event is received. The following monitoring levels are supported:
- Severe - Critical errors that affect continue runtime operation
- Warning - Error conditions that do not affect continued runtime operation or a potential runtime configuration issue
- Info - Informational event
- Debug - An event useful for diagnosing a problem
- Trace - A low level event useful for diagnosing a problem
By default, info and above are enabled at runtime.
Injecting the Monitor
A monitor is injected in a component using the org.fabric3.api.annotation.monitor.Monitor annotation:
...
import org.fabric3.api.annotation.monitor.Monitor;
public void TheComponent {
@Monitor
protected ComponentMonitor monitor;
public void call(Message message) {
monitor.receivedRequest(message.getId);
try{
validate(message));
} catch (ValidationException e) {
// bad message
monitor.error("Invalid message", e)
}
// ...
}
When an @Monitor annotation is encountered, the Fabric3 runtime will generate a monitor proxy and inject it based on the monitor interface. Depending on the current monitor level, events may be logged or ignored. In the above example, if the monitor level is set to severe, the receivedRequest() event will be dropped.
Performance Considerations
Fabric3 uses JDK proxies to implement monitor interfaces. For most code paths in an application, this should not introduce significant performance impact as there are optimizations to avoid object creation when events are discarded. However, for performance intensive code paths, JDK proxies may introduce too much overhead. As an alternative, Fabric3 provides the org.fabric3.api.MonitorChannel interface. A monitor can be typed with this interface, which bypasses JDK proxies and instead uses static method calls:
...
| Info | ||
|---|---|---|
| ||
You may be wondering why the Fabric3 Standalone and Tomcat runtimes use a proprietary monitor implementation as opposed to a third-party logging library. The reason is performance and excessive object creation. Many applications running on Fabric3 have very low latency requirements. This means that a monitoring solution must be capable of routing events extremely quickly (i.e. microsecond latencies to disk) without creating objects. The common third-party logging libraries we examined all suffered from thread contention and, more importantly, excessive object creation which leads to GC pauses under load. The Fabric3 monitor implementation can be configured to use the LMAX Disruptor to alleviate contention and avoid object creation altogether, resulting in stable operation with no GC (even minor collections) under load. |
The Following sections cover the Fabric3 monitor framework.
| Page Tree | ||
|---|---|---|
|