@Configuration public class MetricRepositoryAutoConfiguration extends Object
Auto-configurationfor metrics services. Creates user-facing
CounterServiceinstances, and also back end repositories to catch the data pumped into them.
InMemoryMetricRepository is always created unless another
MetricRepository is already provided by the user. In general, even if metric
data needs to be stored and analysed remotely, it is recommended to use an in-memory
repository to buffer metric updates locally. The values can be exported (e.g. on a
periodic basis) using an
Exporter, most implementations of which have
optimizations for sending data to remote repositories.
If Spring Messaging is on the classpath a
"metricsChannel" is also created (unless one already exists) and all metric update
events are published additionally as messages on that channel. Additional analysis or
actions can be taken by clients subscribing to that channel.
In addition if Codahale's metrics library is on the classpath a
will be created and wired up to the counter and gauge services in addition to the basic
repository. Users can create Codahale metrics by prefixing their metric names with the
appropriate type (e.g. "histogram.*", "meter.*") and sending them to the standard
By default all metric updates go to all
MetricWriter instances in the
application context. To change this behaviour define your own metric writer bean called
"primaryMetricWriter", mark it
@Primary, and this one will receive all
updates from the default counter and gauge services. Alternatively you can provide your
own counter and gauge services and wire them to whichever writer you choose.
|Constructor and Description|
Copyright © 2015 Pivotal Software, Inc.. All rights reserved.