Make sure the Hazelcast statistics support is not triggered if the Spring
support is not present. The Hazelcast dependency alone may be used with
JCache and this should not trigger the support of the native Hazelcast
metrics infra.
See gh-2633
Previously the @Value annotation was not on a top level @Bean field
(it was nested inside). Manually constructing the bean in a separate
configuration class seems like the best way to get it to actually bind
at runtime.
Users can add @ExportMetric[Reader,Writer] to readers and writers that
they want to participate in the default exporter. There is also still an
@ActuatorMetricWriter that is used for the legacy (non-Java8) Gauge and
CounterServices.
The redis export and aggregate use case is a lot nicer with this
shared data between the two component types.
Also made MetricExportProperties itself a Trigger (so the default
delay etc. can be configured via spring.metrics.export.*).
Write to NUL on Windows and /dev/null on other platforms. Increase the
default number of iterations to avoid problems with the reduced timing
precision on Windows.
Closes gh-2976
User can add a bean of type MetricsEndpointMetricReader to opt in
to exporting all metrics via the MetricsEndpoint (instead of via
MetricReaders). There are disadvantages (like no accurate timestamps)
so it's best to leave it as an opt in.
Also improved tests for metric auto configuration a bit.
In principle you might have multiple "system" repositories, all
of which you want to go to public metrics or not be metrics exporters.
This change adds a new annotation and renames the old one, so that
reades and writers can be distinguished, and also changes the
autowiring of them to accept multiple values.
Also adds automatic public metrics for Spring Integration.
This commit adds CORS support to the Actuator’s MVC endpoints. CORS
support is disabled by default and is only enabled once the
endpoints.cors.allowed-origins property has been set.
The new properties to control the endpoints’ CORS configuration are:
endpoints.cors.allow-credentials
endpoints.cors.allowed-origins
endpoints.cors.allowed-methods
endpoints.cors.allowed-headers
endpoints.cors.exposed-headers
The changes to enable Jolokia-specific CORS support (57a51ed) have been
reverted as part of this commit. This provides a consistent approach
to CORS configuration across all endpoints, rather than Jolokia using
its own configuration.
See gh-1987
Closes gh-2936
This avoids a potential problems with ordering between Dropwizard and
normal repository configuration. A Dropwizard sample has been added to
verify the behaviour.
Different physical sources for the same logical metric just need to
publish them with a period-separated prefix, and this reader will
aggregate (by truncating the metric names, dropping the prefix).
Very useful (for instance) if multiple application instances are
feeding to a central (e.g. redis) repository and you want to
display the results. Useful in conjunction with a
MetricReaderPublicMetrics for hooking up to the /metrics endpoint.
This seems pretty efficient (approx 12M write/s as opposed to 2M with
the DefaultCounterService). N.B. there is no need to change most of
the rest of the metrics stuff because metrics are write-often, read-
seldom, so we don't need high performance reads as much.
The Spring Integration configuration and Dropwizard support has changed
a bit. Functionally very similar and probably opaque to users, but now
the messaging operates as an Exporter on a @Scheduled method, and
Dropwizard is a replacement [Gauge,Counter]Service.
Metrics are all
collected live in-memory (and can be very fast with Java 8), buffered
there and shipped out to a MessageChannel (if one exists with id
"metricsChannel") in a background thread.
We can still use Java 8 library APIs (like LongAdder) but to compile
to java 7 compatible byte code we have to forgo the use of lambdas :-(
and shorthand generics (<>).
Fixes gh-2682, fixes gh-2513 (for Java 8 and Dropwizard users).
Spring Framework 4.2 introduces improved support for CORS. Notably this
means that a DispatcherServlet will now process an OPTIONS request if
it contains an Origin header, without having to enable OPTIONS request
dispatching for every endpoint.
This commit takes advantage of these changes in Spring Framework 4.2 by
configuring the controller that wraps Jolokia’s AgentServlet to handle
OPTIONS requests. This allows Jolokia’s CORS support to be configured
using Jolokia’s standard configuration, as described in section 4.1.5
of the Jolokia documentation [1].
Closes gh-1987
[1] https://jolokia.org/reference/html/security.html
Previously ManagementSecurityAutoConfiguration used Spring Security's
default realm of "Realm" when authentication failed. This was confusing
because when prompted for authentication (i.e. no credentials provided)
the realm "Spring" was requested.
This commit ensures the Realm that is used is consistent for all of of the
security auto configuration.
Fixes#2466
In addition to the changes already made in 1.2.x, this commit updates
the tests in spring-boot-actuator to ensure that any Elasticsearch
data files are written into the target directory. This avoids problems
when switching branches caused by different versions of Elasticsearch
trying to read the files.
Stephane Nicoll
Dave Syer
izeye
Andreas Ahlenstorf
Andy Wilkinson
Josh Thornhill
Rob Winch
Phillip Webb