...
- Strongly-typed monitoring interfaces and events
- High performance logging (millions of events per second) with no garbage creation for latency-sensitive appications
- Dynamic event level adjustment
| Info |
|---|
The samples contains an application in the features sectiona monitor applicationwhich shows how to use the monitoring framework in an application and write a custom appender for recording events. |
...
The Fabric3 monitor framework uses different implementations depending on the host environment. For WebLogic, Maven and Ant, the native host logging framework is used. For example, on WebLogic, monitor proxies will forward events to WebLogic's logging infrastructure. Configuration is therefore specific to each host environment. The Fabric3 Standalone and Tomcat runtimes use the native Fabric3 monitoring implementation, which is described in the rest of this section.
| 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. As we demonstrate below, 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 above example configures both a console and file appender. The file attribute is the location of the output file, which is relative to the runtime /data directory (subdirectories are supported).
Timestamp Formatting
Timestamp formatting can be configured using the pattern attribute of the monitor element:
| Code Block | ||
|---|---|---|
| ||
<monitor pattern="%d:%m:%Y %H:%i:%s.%F">
...
</monitor> |
The following formatting directives are supported:
- %a - Abbreviated weekday name ("Sun", "Mon", "Tue")
- %b - Abbreviated month name ("Jan", "Feb", "Mar")
- %c - The Month number
- %d - The day of month in padded two digit form (01..31)
- %e - The day of month in trimmed form (1..31)
- %f - Milliseconds in trimmed form (0..999)
- %F - Milliseconds in padded three digit form (000..999)
- %H - The hour in 24-hour form (00-23)
- %h - The hour in 12-hour form (01-12)
- %i - Minutes
- %j - Day of year (001..366)
- %k - The hour in trimmed 24-hour form (0..23)
- %l - The hour in trimmed 12-hour form (1..12)
- %M - The full month name
- %m - The month number
- %p - AM or PM
- %S - The seconds in trimmed form
- %s - The seconds in padded two digit form
- %W - The full weekday name("Sunday".."Saturday")
- %w - The day of week (1 - Sunday .. 7 - Saturday)
- %Y - The four digit year
- %y - The two digit year
Configuring Custom Destinations
...
By default, monitor events are sent routed to destinations synchronously. This may result in significant performance impact for <f3:monitor applications that frequently emit events. The Fabric3 monitor implementation can be configured using the mode attribute to route asynchronously using a LMAX Disruptor ring buffer, as illustrated in the following excerpt:
| Code Block | ||
|---|---|---|
| ||
<f3:monitor name="ApplicationDestination" mode="asynchronous |
...
" |
...
> <appenders> <appender.file file="application.log"/> |
...
Custom Appenders
Configuration Reference
Performance Considerations
...
</appenders>
</f3:monitor>
|
The mode attribute is set to "asynchronous," which indicates routing should be done using a ring buffer. If you plan to use asynchronous monitoring, keep in mind several things. The first is to select a ring buffer size that is large enough to avoid wrapping events (see the LMAX Disruptor documentation for more information). The default value is set at 65536 slots. The second is how buffers for writing monitor event data are handled. To avoid object creation, Fabric3 pre-allocates byte buffers with a configurable but fixed size (3,000 bytes by default) for writing monitor events. If the byte buffer size is not large enough to handle a message, you will need to increase the pre-allocated size or data will be truncated. Setting the ring buffer slot size and byte buffer capacity are done using the ring.size and capacity attributes respectively:
| Code Block | ||
|---|---|---|
| ||
<f3:monitor name="ApplicationDestination" mode="asynchronous" ring.size="65536" capacity="3000">
...
</f3:monitor>
|
If you decide to use as asynchronous monitor routing, it is also recommended you use the Fabric3 bytecode generation extension (Maven coordinates {{org.codehaus.fabric3:fabric3-bytecode-proxy}} for creating monitor proxies. This is done by including the extension in the runtime /extensions directory and setting the proxy attribute to "bytecode" as follows:
| Code Block | ||
|---|---|---|
| ||
<f3:monitor name="ApplicationDestination" mode="asynchronous" ring.size="65536" capacity="3000" proxy="bytecode">
...
</f3:monitor>
|
As a final performance recommendation, you should also consider whether to include formatted timestamp information in the log output. Formatting is a performance drain and can be avoided by using a raw nanosecond timestamp. This can be configured by setting the timestamp attribute to "unformatted" or "none":
| Code Block | ||
|---|---|---|
| ||
<f3:monitor name="ApplicationDestination" mode="asynchronous" ring.size="65536" capacity="3000" proxy="bytecode" timestamp="unformatted">
...
</f3:monitor> |
The monitor ring buffer can be fine-tuned using the following attributes. For more information, consult the LMAX Disruptor documentation:
- capacity
- ring.size
- wait.strategy
- blocking.timeout
- spin.timeout
- yield.timeout
- phased.blocking.type
Custom Appenders
The Fabric3 monitor implementation supports custom appenders. For an example, refer the sample monitor application.
Configuration Reference
The following represents a pseudo-schema for monitor configuration in systemConfig.xml:
| Code Block | ||
|---|---|---|
| ||
<monitor mode="synchronous|asynchronous" capacity="int" ring.size="power of 2" proxy="bytecode|JDK" wait.strategy="blocking|yielding|sleeping|backoff|spin|timeout"
blocking.timeout="nanoseconds" spin.timeout="nanoseconds" yield.timeout="nanoseconds" phased.blocking.type="lock|sleep" timestamp="formatted|unformatted|none" pattern=".." timezone="Java timezone">
</monitor> |