...
To use the monitoring framework in application code entails two things, creating a monitor interface and injecting the monitor in a component.
...
Defining a Monitor Interface
...
The monitor interface is used for sending monitoring events. The interface defines operations for publishing events, monitoring levels and optional event message templates:
...
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
...
| Code Block | ||
|---|---|---|
| ||
<composite .... xmlns:f3="urn:fabric3.org">
<f3:monitor name="ApplicationDestination">
<appenders>
<appender.file file="application.log"/>
</appenders>
</f3:monitor>
</composite>
|
Application code can then reference the destination by specifying its name in the @Monitor annotation:
...
| Code Block | ||
|---|---|---|
| ||
<f3:monitor name="ApplicationDestination" mode="asynchronous">
<appenders>
<appender.file file="application.log"/>
</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":
...