for users to get started. It also makes it more flexible if different
aggregation keys are needed depending on the environment. The most
important new feature is the
spring.metrics.export.redis.aggregateKeyPattern configuration, which
fits the *.redis.key and prefix defaults. The aggregate reader uses
a prefix based on the key by default, with a naming convention that
the key starts with "keys.".
Update `ConfigurationPropertiesReportEndpoint` so that properties that
are set with a Boolean class but read with a boolean primitive still
appear in the report. The allows the Endpoint.isEnabled() property to
be displayed.
Fixes gh-2929
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.
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.
Update CacheStatisticsProvider to use a generic to indicate the type
of cache supported. Also extract individual CacheStatisticsProvider
implementations and made statistics an auto-configuration.
See gh-2633
Prior to this commit, EndpointWebMvcAutoConfiguration would start a
child context if the management port was different to the server port
and the application context was a web application context. This caused
two problems:
If a user built an executable war and configured the management port so
that it was different to the server port, their application would run
successfully when launched with java -jar, but it would fail when
deployed to Tomcat as an attempt would be made to start embedded Tomcat.
Secondly, if a user ran a test annotated with @WebAppConfiguration the
main embedded Tomcat instance would not be started, but the child
context would trigger the creation of a Tomcat instance listening on the
configured management port. This is unexpected as @WebIntegrationTest
or @IntegrationTest and @WebAppConfiguration should be required to have
the test trigger full startup of the application and listen on the
configured ports.
This commit updates EndpointWebMvcAutoConfiguration so that it will only
start a child context when the management port is different to the
server port and the EmbeddedWebApplicationContext has an embedded
servlet container. This resolves the two problems described above as
there will be no embedded servlet container when deployed to a
standalone container or when a test is run without @IntegrationTest.
Fixes gh-2798
Previously, when multiple cache managers had a cache with the same name,
the prefix for the first cache that was processed would not include its
cache manager’s name, but all subsequent prefixes would include the
cache manager’s name. This was inconsistent, and due to the cache
managers being unordered, the prefixing was not deterministic.
This commit updates the prefixing logic so that when there is a clash,
all of the affected prefixes will include the name of the cache manager.
For example, with cache managers named first and second and each
with a cache named users, the prefixes will be cache.first_users and
cache.second_users rather than cache.users and
cache.{first|second}_users.
Closes gh-2824
multipleCacheManagers fails on the CI server but does not fail
locally. This commit updates assertMetrics to include information
about the actual metrics so it's clear why the expectation was not
met.
Add an abstraction that provides a standard manner to retrieve a
statistics snapshot of a cache.
Specific implementations for JSR-107, ehcache, hazelcast, guava and
concurrent map are provided. At the moment the size of the cache and
the hit/miss ratios are recorded. Cache metrics are exposed via the
`cache.` prefix followed by the name of the cache. In case of conflict,
the name of the cache manager is added as a qualifier.
It is possible to easily register a new CacheStatisticsProvider for an
unsupported cache system and the CacheStatistics object itself can be
extended to provide additional metrics.
See gh-2633
Closes gh-2770
Previously, if a call to doFilter in MetricFilter failed (i.e. it threw
an exception), it would be handled as if it had a response status of
200. This is because the servlet container was yet to handle the
exception and set the response status to 500.
This commit updates MetricFilter to assume that an exception thrown from
doFilter will result in a response with a status of 500. Strictly
speaking, even though the filter has highest precedence and will
therefore run last on the way back out, this may not always be the case.
For example, a custom Tomcat Valve could handle the exception and result
in a 200 response but that’s an edge case that’s into shooting yourself
in the foot territory.
Closes gh-2818
