Long package names are really unnecessary in samples and they
just clutter things up. Also Spring Loaded doesn't work with
org.sfw packages, so to demo that technology you need a
different package name.
Main user-facing interface is still Counter/GaugeService but the
back end behind that has more options. The Default*Services write
metrics to a MetricWriter and there are some variants of that, and
also variants of MetricReader (basic read-only actions).
MetricRepository is now a combination of MetricReader, MetricWriter
and some more methods that make it a bit more repository like.
There is also a MultiMetricReader and a MultiMetricRepository for
the common case where metrics are stored in related (often open
ended) groups. Examples would be complex metrics like histograms
and "rich" metrics with averages and statistics attached (which
are both closed) and "field counters" which count the occurrences
of values of a particular named field or slot in an incoming message
(e.g. counting Twitter hastags, open ended).
In memory and redis implementations are provided for the repositories.
Generally speaking the in memory repository should be used as a
local buffer and then scheduled "exports" can be executed to copy
metric values accross to a remote repository for aggregation.
There is an Exporter interface to support this and a few implementations
dealing with different strategies for storing the results (singly or
grouped).
Codahale metrics are also supported through the MetricWriter interface.
Currently implemented through a naming convention (since Codahale has
a fixed object model this makes sense): metrics beginning with "histogram"
are Histograms, "timer" for Timers, "meter" for Meters etc.
Support for message driven metric consumption and production are provided
through a MetricWriterMessageHandler and a MessageChannelMetricWriter.
No support yet for pagination in the repositories, or for HATEOAS style
HTTP endpoints.
When management endpoints are on a different port the HandlerMappings
are restricted to a single EndpointHandlerMapping, so the error
controller (which is a normal @Controller with @RequestMappings) does
not get mapped.
Fixed by addinga shim Endpoint on "/error" that delegates to the
ErrorController (which interface picks up an extra method).
This commit adds a new starter named spring-boot-starter-shell-crsh and auto configuration support to embed a system shell within Spring Boot applications.
The embedded shell allows clients to connect via ssh or telnet to the Boot app and execute commands. Commands can be implemented and embedded with app.
For sample usage see spring-boot-samples-actuator.
Previously the management endpoint filter was applied to all requests
if the user had disabled security.management.enabled, but since it
had no security applied it was letting all requests through.
The fix was to explicitly exclude the whole enclosing configuration
and carefully ignore the management endpoints in the normal security
chain.
Fixes gh-100.
The management endpoints were still all mixed up
with the user endpoints. Fixed that and extracted
user endpoints in to conditional block so not
protected if path explicitly set to empty string.
[#53029715]
Management endpoints are still secure by default if
Spring Security is present, but now the default
user details have an ADMIN role, and a random password
(which is logged at INFO level if not overridden).
To override you add management.user.password (name, role)
to external properties.
[Fixes#53029715] [bs-203]
Phillip Webb
Dave Syer
Christian Dupuis