Wrap production-ready-features.adoc at 90 characters
Closes gh-10830
This commit is contained in:
Andy Wilkinson
@@ -5,8 +5,8 @@
|
||||
--
|
||||
Spring Boot includes a number of additional features to help you monitor and manage your
|
||||
application when you push it to production. You can choose to manage and monitor your
|
||||
application by using HTTP endpoints or with JMX. Auditing, health, and metrics gathering can
|
||||
also be automatically applied to your application.
|
||||
application by using HTTP endpoints or with JMX. Auditing, health, and metrics gathering
|
||||
can also be automatically applied to your application.
|
||||
|
||||
Actuator HTTP endpoints are only available with a Spring MVC-based application. In
|
||||
particular, it does not work with Jersey <<howto.adoc#howto-use-actuator-with-jersey,
|
||||
@@ -17,9 +17,9 @@ unless you enable Spring MVC as well.>>
|
||||
|
||||
[[production-ready-enabling]]
|
||||
== Enabling Production-ready Features
|
||||
The {github-code}/spring-boot-project/spring-boot-actuator[`spring-boot-actuator`] module provides all of
|
||||
Spring Boot's production-ready features. The simplest way to enable the features is to add
|
||||
a dependency to the `spring-boot-starter-actuator` '`Starter`'.
|
||||
The {github-code}/spring-boot-project/spring-boot-actuator[`spring-boot-actuator`] module
|
||||
provides all of Spring Boot's production-ready features. The simplest way to enable the
|
||||
features is to add a dependency to the `spring-boot-starter-actuator` '`Starter`'.
|
||||
|
||||
.Definition of Actuator
|
||||
****
|
||||
@@ -28,8 +28,7 @@ controlling something. Actuators can generate a large amount of motion from a sm
|
||||
change.
|
||||
****
|
||||
|
||||
To add the actuator to a Maven based project, add the following '`Starter`'
|
||||
dependency:
|
||||
To add the actuator to a Maven based project, add the following '`Starter`' dependency:
|
||||
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
@@ -58,10 +57,10 @@ Actuator endpoints let you monitor and interact with your application. Spring Bo
|
||||
includes a number of built-in endpoints and lets you add your own. For example, the
|
||||
`health` endpoint provides basic application health information.
|
||||
|
||||
The way that endpoints are exposed depends on the type of technology that you choose.
|
||||
Most applications choose HTTP monitoring, where the ID of the endpoint along with a prefix of
|
||||
`/application` is mapped to a URL. For example, by default, the `health` endpoint is mapped
|
||||
to `/application/health`.
|
||||
The way that endpoints are exposed depends on the type of technology that you choose. Most
|
||||
applications choose HTTP monitoring, where the ID of the endpoint along with a prefix of
|
||||
`/application` is mapped to a URL. For example, by default, the `health` endpoint is
|
||||
mapped to `/application/health`.
|
||||
|
||||
The following technology-agnostic endpoints are available:
|
||||
|
||||
@@ -114,7 +113,8 @@ The following technology-agnostic endpoints are available:
|
||||
|Lets the application be gracefully shutdown (not enabled by default).
|
||||
|
||||
|`status`
|
||||
|Shows application status information (that is, `health` status with no additional details).
|
||||
|Shows application status information (that is, `health` status with no additional
|
||||
details).
|
||||
|
||||
|`threaddump`
|
||||
|Performs a thread dump.
|
||||
@@ -153,8 +153,8 @@ TIP: If you want to use something other than `ACTUATOR` as the role, set the
|
||||
`management.security.roles` property to the value you want to use.
|
||||
|
||||
If you deploy applications behind a firewall, you may prefer that all your actuator
|
||||
endpoints can be accessed without requiring authentication. You can do so by changing
|
||||
the `management.security.enabled` property, as follows:
|
||||
endpoints can be accessed without requiring authentication. You can do so by changing the
|
||||
`management.security.enabled` property, as follows:
|
||||
|
||||
.application.properties
|
||||
[source,properties,indent=0]
|
||||
@@ -166,17 +166,17 @@ CAUTION: By default, actuator endpoints are exposed on the same port that serves
|
||||
HTTP traffic. Take care not to accidentally expose sensitive information if you change
|
||||
the `management.security.enabled` property.
|
||||
|
||||
If you deploy applications publicly, you may want to add '`Spring Security`' to
|
||||
handle user authentication. When '`Spring Security`' is added, by default, '`basic`'
|
||||
If you deploy applications publicly, you may want to add '`Spring Security`' to handle
|
||||
user authentication. When '`Spring Security`' is added, by default, '`basic`'
|
||||
authentication is used. The username is`user` and the password is a random generated
|
||||
password (which is printed on the console when the application starts).
|
||||
|
||||
TIP: Generated passwords are logged as the application starts. To find the password in
|
||||
the console, search for '`Using default security password`'.
|
||||
TIP: Generated passwords are logged as the application starts. To find the password in the
|
||||
console, search for '`Using default security password`'.
|
||||
|
||||
You can use Spring properties to change the username and password and to change the
|
||||
security role(s) required to access the endpoints. For example, you might set the following
|
||||
properties in your `application.properties`:
|
||||
security role(s) required to access the endpoints. For example, you might set the
|
||||
following properties in your `application.properties`:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -187,27 +187,27 @@ properties in your `application.properties`:
|
||||
|
||||
If your application has custom security configuration and you want all your actuator
|
||||
endpoints to be accessible without authentication, you need to explicitly configure that
|
||||
in your security configuration. Also, you need to change the
|
||||
`management.security.enabled` property to `false`.
|
||||
in your security configuration. Also, you need to change the `management.security.enabled`
|
||||
property to `false`.
|
||||
|
||||
If your custom security configuration secures your actuator endpoints, you also need to
|
||||
ensure that the authenticated user has the roles specified under
|
||||
`management.security.roles`.
|
||||
|
||||
TIP: If you do not have a use case for exposing basic health information to unauthenticated
|
||||
users and you have secured the actuator endpoints with custom security, you can set
|
||||
`management.security.enabled` to `false`. This tells Spring Boot to skip the
|
||||
TIP: If you do not have a use case for exposing basic health information to
|
||||
unauthenticated users and you have secured the actuator endpoints with custom security,
|
||||
you can set `management.security.enabled` to `false`. This tells Spring Boot to skip the
|
||||
additional role check.
|
||||
|
||||
|
||||
|
||||
[[production-ready-customizing-endpoints]]
|
||||
=== Customizing Endpoints
|
||||
Endpoints can be customized by using Spring properties. You can change whether an endpoint is
|
||||
`enabled` and its `id`.
|
||||
Endpoints can be customized by using Spring properties. You can change whether an endpoint
|
||||
is `enabled` and its `id`.
|
||||
|
||||
For example, the following `application.properties` changes the id of the `beans`
|
||||
endpoint and also enables `shutdown`:
|
||||
For example, the following `application.properties` changes the id of the `beans` endpoint
|
||||
and also enables `shutdown`:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -218,9 +218,9 @@ endpoint and also enables `shutdown`:
|
||||
NOTE: The prefix ‟`endpoints` + `.` + `name`” is used to uniquely identify the endpoint
|
||||
that is being configured.
|
||||
|
||||
By default, all endpoints except for `shutdown` are enabled. If you prefer to
|
||||
specifically "`opt-in`" endpoint enablement, you can use the `endpoints.default.enabled`
|
||||
property. For example, the following settings disables _all_ endpoints except for `info`:
|
||||
By default, all endpoints except for `shutdown` are enabled. If you prefer to specifically
|
||||
"`opt-in`" endpoint enablement, you can use the `endpoints.default.enabled` property. For
|
||||
example, the following settings disables _all_ endpoints except for `info`:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -235,11 +235,11 @@ property. For example, the following settings disables _all_ endpoints except fo
|
||||
A "`discovery page`" is added with links to all the endpoints. The "`discovery page`" is
|
||||
available on `/application` by default.
|
||||
|
||||
When a custom management context path is configured, the "`discovery page`"
|
||||
automatically moves from `/application` to the root of the management context. For example,
|
||||
if the management context path is `/management`, then the discovery page is available
|
||||
from `/management`. When the management context path is set to `/`, the discovery page
|
||||
is disabled to prevent the possibility of a clash with other mappings.
|
||||
When a custom management context path is configured, the "`discovery page`" automatically
|
||||
moves from `/application` to the root of the management context. For example, if the
|
||||
management context path is `/management`, then the discovery page is available from
|
||||
`/management`. When the management context path is set to `/`, the discovery page is
|
||||
disabled to prevent the possibility of a clash with other mappings.
|
||||
|
||||
|
||||
|
||||
@@ -247,13 +247,12 @@ is disabled to prevent the possibility of a clash with other mappings.
|
||||
=== CORS Support
|
||||
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing[Cross-origin resource sharing]
|
||||
(CORS) is a http://www.w3.org/TR/cors/[W3C specification] that allows you to specify in a
|
||||
flexible way what kind of cross domain requests are authorized. If you use Spring
|
||||
MVC or Spring WebFlux, Actuator's web endpoints can be configured to support such
|
||||
scenarios.
|
||||
flexible way what kind of cross domain requests are authorized. If you use Spring MVC or
|
||||
Spring WebFlux, Actuator's web endpoints can be configured to support such scenarios.
|
||||
|
||||
CORS support is disabled by default and is only enabled once the
|
||||
`management.endpoints.cors.allowed-origins` property has been set. The following configuration
|
||||
permits `GET` and `POST` calls from the `example.com` domain:
|
||||
`management.endpoints.cors.allowed-origins` property has been set. The following
|
||||
configuration permits `GET` and `POST` calls from the `example.com` domain:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -261,8 +260,7 @@ permits `GET` and `POST` calls from the `example.com` domain:
|
||||
management.endpoints.cors.allowed-methods=GET,POST
|
||||
----
|
||||
|
||||
TIP: See {sc-spring-boot-actuator-autoconfigure}/endpoint/web/servlet/CorsEndpointProperties.{sc-ext}[CorsEndpointProperties]
|
||||
for a complete list of options.
|
||||
TIP: See {sc-spring-boot-actuator-autoconfigure}/endpoint/web/servlet/CorsEndpointProperties.{sc-ext}[CorsEndpointProperties] for a complete list of options.
|
||||
|
||||
|
||||
|
||||
@@ -272,20 +270,20 @@ If you add a `@Bean` annotated with `@Endpoint`, any methods annotated with
|
||||
`@ReadOperation` or `@WriteOperation` are automatically exposed over JMX and, in a web
|
||||
application, over HTTP as well.
|
||||
|
||||
TIP: If you do this as a library feature, consider adding a configuration class
|
||||
annotated with `@ManagementContextConfiguration` to `/META-INF/spring.factories` under the
|
||||
key, `org.springframework.boot.actuate.autoconfigure.ManagementContextConfiguration`. If
|
||||
you do so and if your users ask for a separate management port or address, the endpoint
|
||||
moves to a child context with all the other web endpoints.
|
||||
TIP: If you do this as a library feature, consider adding a configuration class annotated
|
||||
with `@ManagementContextConfiguration` to `/META-INF/spring.factories` under the key,
|
||||
`org.springframework.boot.actuate.autoconfigure.ManagementContextConfiguration`. If you do
|
||||
so and if your users ask for a separate management port or address, the endpoint moves to
|
||||
a child context with all the other web endpoints.
|
||||
|
||||
|
||||
|
||||
[[production-ready-health]]
|
||||
=== Health Information
|
||||
You can use health information to check the status of your running application. It is
|
||||
often used by monitoring software to alert someone when a production system goes down.
|
||||
The default information exposed by the `health` endpoint depends on how it is accessed.
|
||||
For an unauthenticated connection in a secure application, a simple '`status`' message is
|
||||
often used by monitoring software to alert someone when a production system goes down. The
|
||||
default information exposed by the `health` endpoint depends on how it is accessed. For an
|
||||
unauthenticated connection in a secure application, a simple '`status`' message is
|
||||
returned. For an authenticated connection, additional details are also displayed. (See
|
||||
<<production-ready-health-access-restrictions>> for HTTP details.)
|
||||
|
||||
@@ -376,11 +374,11 @@ NOTE: The identifier for a given `HealthIndicator` is the name of the bean witho
|
||||
is available in an entry named `my`.
|
||||
|
||||
In addition to Spring Boot's predefined {sc-spring-boot-actuator}/health/Status.{sc-ext}[`Status`]
|
||||
types, it is also possible for `Health` to return a custom `Status` that represents a
|
||||
new system state. In such cases, a custom implementation of the
|
||||
{sc-spring-boot-actuator}/health/HealthAggregator.{sc-ext}[`HealthAggregator`]
|
||||
interface also needs to be provided, or the default implementation has to be configured
|
||||
by using the `management.health.status.order` configuration property.
|
||||
types, it is also possible for `Health` to return a custom `Status` that represents a new
|
||||
system state. In such cases, a custom implementation of the
|
||||
{sc-spring-boot-actuator}/health/HealthAggregator.{sc-ext}[`HealthAggregator`] interface
|
||||
also needs to be provided, or the default implementation has to be configured by using the
|
||||
`management.health.status.order` configuration property.
|
||||
|
||||
For example, assume a new `Status` with code `FATAL` is being used in one of your
|
||||
`HealthIndicator` implementations. To configure the severity order, add the following
|
||||
@@ -392,9 +390,9 @@ to your application properties:
|
||||
----
|
||||
|
||||
The HTTP status code in the response reflects the overall health status (for example, `UP`
|
||||
maps to 200, while `OUT_OF_SERVICE` and `DOWN` map to 503). You might also want to register custom
|
||||
status mappings if you access the health endpoint over HTTP. For example, the following
|
||||
property maps `FATAL` to 503 (service unavailable):
|
||||
maps to 200, while `OUT_OF_SERVICE` and `DOWN` map to 503). You might also want to
|
||||
register custom status mappings if you access the health endpoint over HTTP. For example,
|
||||
the following property maps `FATAL` to 503 (service unavailable):
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -456,8 +454,8 @@ property.
|
||||
[[production-ready-application-info-env]]
|
||||
==== Custom Application Information
|
||||
You can customize the data exposed by the `info` endpoint by setting `+info.*+` Spring
|
||||
properties. All `Environment` properties under the info key are automatically
|
||||
exposed. For example, you could add the following settings to your `application.properties` file:
|
||||
properties. All `Environment` properties under the info key are automatically exposed. For
|
||||
example, you could add the following settings to your `application.properties` file:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -485,13 +483,13 @@ Assuming you use Maven, you could rewrite the preceding example as follows:
|
||||
|
||||
[[production-ready-application-info-git]]
|
||||
==== Git Commit Information
|
||||
Another useful feature of the `info` endpoint is its ability to publish information
|
||||
about the state of your `git` source code repository when the project was built. If a
|
||||
`GitProperties` bean is available, the `git.branch`, `git.commit.id` and
|
||||
`git.commit.time` properties are exposed.
|
||||
Another useful feature of the `info` endpoint is its ability to publish information about
|
||||
the state of your `git` source code repository when the project was built. If a
|
||||
`GitProperties` bean is available, the `git.branch`, `git.commit.id` and `git.commit.time`
|
||||
properties are exposed.
|
||||
|
||||
TIP: A `GitProperties` bean is auto-configured if a `git.properties` file is available
|
||||
at the root of the classpath. See
|
||||
TIP: A `GitProperties` bean is auto-configured if a `git.properties` file is available at
|
||||
the root of the classpath. See
|
||||
"<<howto.adoc#howto-git-info,Generate git information>>" for more details.
|
||||
|
||||
If you want to display the full git information (that is, the full content of
|
||||
@@ -506,9 +504,9 @@ If you want to display the full git information (that is, the full content of
|
||||
|
||||
[[production-ready-application-info-build]]
|
||||
==== Build Information
|
||||
If a `BuildProperties` bean is available, the `info` endpoint can also publish
|
||||
information about your build. This happens if a `META-INF/build-info.properties` file
|
||||
is available in the classpath.
|
||||
If a `BuildProperties` bean is available, the `info` endpoint can also publish information
|
||||
about your build. This happens if a `META-INF/build-info.properties` file is available in
|
||||
the classpath.
|
||||
|
||||
TIP: The Maven and Gradle plugins can both generate that file. See
|
||||
"<<howto.adoc#howto-build-info,Generate build information>>" for more details.
|
||||
@@ -557,43 +555,44 @@ additional entry:
|
||||
|
||||
[[production-ready-monitoring]]
|
||||
== Monitoring and Management over HTTP
|
||||
If you are developing a Spring MVC application, Spring Boot Actuator auto-configures
|
||||
all enabled endpoints to be exposed over HTTP. The default convention is to use the
|
||||
`id` of the endpoint with a prefix of `/application` as the URL path. For example, `health`
|
||||
is exposed as `/application/health`.
|
||||
If you are developing a Spring MVC application, Spring Boot Actuator auto-configures all
|
||||
enabled endpoints to be exposed over HTTP. The default convention is to use the `id` of
|
||||
the endpoint with a prefix of `/application` as the URL path. For example, `health` is
|
||||
exposed as `/application/health`.
|
||||
|
||||
|
||||
|
||||
[[production-ready-customizing-management-server-context-path]]
|
||||
=== Customizing the Management Endpoint Paths
|
||||
Sometimes, it is useful to customize the prefix for the management endpoints.
|
||||
For example, your application might already use `/application` for another purpose.
|
||||
You can use the `management.endpoints.web.base-path` property to change the prefix for your
|
||||
management endpoint, as shown in the following example:
|
||||
Sometimes, it is useful to customize the prefix for the management endpoints. For example,
|
||||
your application might already use `/application` for another purpose. You can use the
|
||||
`management.endpoints.web.base-path` property to change the prefix for your management
|
||||
endpoint, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
management.endpoints.web.base-path=/manage
|
||||
----
|
||||
|
||||
The preceding `application.properties` example changes the endpoint from `/application/{id}` to
|
||||
`/manage/{id}` (e.g. `/manage/info`).
|
||||
The preceding `application.properties` example changes the endpoint from
|
||||
`/application/{id}` to `/manage/{id}` (e.g. `/manage/info`).
|
||||
|
||||
NOTE: Unless the management port has been configured to
|
||||
<<production-ready-customizing-management-server-port,expose endpoints using a different
|
||||
HTTP port>>, `management.endpoints.web.base-path` is relative to `server.context-path`. If `management.server.port`
|
||||
is configured, `management.endpoints.web.base-path` is relative to `management.server.servlet.context-path`.
|
||||
HTTP port>>, `management.endpoints.web.base-path` is relative to `server.context-path`.
|
||||
If `management.server.port` is configured, `management.endpoints.web.base-path` is
|
||||
relative to `management.server.servlet.context-path`.
|
||||
|
||||
|
||||
|
||||
[[production-ready-customizing-management-server-port]]
|
||||
=== Customizing the Management Server Port
|
||||
Exposing management endpoints by using the default HTTP port is a sensible choice for cloud
|
||||
based deployments. If, however, your application runs inside your own data center, you
|
||||
may prefer to expose endpoints by using a different HTTP port.
|
||||
Exposing management endpoints by using the default HTTP port is a sensible choice for
|
||||
cloud based deployments. If, however, your application runs inside your own data center,
|
||||
you may prefer to expose endpoints by using a different HTTP port.
|
||||
|
||||
You can set the `management.server.port` property to change the HTTP port, as shown in
|
||||
the following example:
|
||||
You can set the `management.server.port` property to change the HTTP port, as shown in the
|
||||
following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -602,8 +601,8 @@ the following example:
|
||||
|
||||
Since your management port is often protected by a firewall and not exposed to the public,
|
||||
you might not need security on the management endpoints, even if your main application is
|
||||
secure. In that case, you should have Spring Security on the classpath, and you can disable
|
||||
management security as follows:
|
||||
secure. In that case, you should have Spring Security on the classpath, and you can
|
||||
disable management security as follows:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -618,9 +617,9 @@ disable the management security in this way. Doing so might even break the appli
|
||||
[[production-ready-management-specific-ssl]]
|
||||
=== Configuring Management-specific SSL
|
||||
When configured to use a custom port, the management server can also be configured with
|
||||
its own SSL by using the various `management.server.ssl.*` properties. For example, doing so lets a
|
||||
management server be available via HTTP while the main application uses HTTPS, as shown
|
||||
in the following property settings:
|
||||
its own SSL by using the various `management.server.ssl.*` properties. For example, doing
|
||||
so lets a management server be available via HTTP while the main application uses HTTPS,
|
||||
as shown in the following property settings:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -651,13 +650,13 @@ different key stores, as follows:
|
||||
|
||||
[[production-ready-customizing-management-server-address]]
|
||||
=== Customizing the Management Server Address
|
||||
You can customize the address that the management endpoints are available on by
|
||||
setting the `management.server.address` property. Doing so can be useful if you want to
|
||||
listen only on an internal or ops-facing network or to listen only for connections from
|
||||
You can customize the address that the management endpoints are available on by setting
|
||||
the `management.server.address` property. Doing so can be useful if you want to listen
|
||||
only on an internal or ops-facing network or to listen only for connections from
|
||||
`localhost`.
|
||||
|
||||
NOTE: You can only listen on a different address if the port is different from the
|
||||
main server port.
|
||||
NOTE: You can only listen on a different address if the port is different from the main
|
||||
server port.
|
||||
|
||||
The following example `application.properties` does not allow remote management
|
||||
connections:
|
||||
@@ -683,11 +682,10 @@ If you do not want to expose endpoints over HTTP, you can set the management por
|
||||
|
||||
[[production-ready-health-access-restrictions]]
|
||||
=== HTTP Health Endpoint Format and Access Restrictions
|
||||
The information exposed by the health endpoint varies, depending on whether it is
|
||||
accessed anonymously and whether the enclosing application is secure.
|
||||
By default, when accessed anonymously in a secure application, any details about the
|
||||
server's health are hidden and the endpoint indicates whether the server
|
||||
is up or down.
|
||||
The information exposed by the health endpoint varies, depending on whether it is accessed
|
||||
anonymously and whether the enclosing application is secure. By default, when accessed
|
||||
anonymously in a secure application, any details about the server's health are hidden and
|
||||
the endpoint indicates whether the server is up or down.
|
||||
|
||||
The following example shows a summarized HTTP response (default for anonymous request):
|
||||
|
||||
@@ -702,7 +700,8 @@ The following example shows a summarized HTTP response (default for anonymous re
|
||||
{"status":"UP"}
|
||||
----
|
||||
|
||||
The following example shows a summarized HTTP response for status "DOWN" (notice the 503 status code):
|
||||
The following example shows a summarized HTTP response for status "DOWN" (notice the 503
|
||||
status code):
|
||||
|
||||
[source,indent=0]
|
||||
----
|
||||
@@ -746,19 +745,20 @@ The following example shows a detailed HTTP response:
|
||||
[[production-ready-jmx]]
|
||||
== Monitoring and Management over JMX
|
||||
Java Management Extensions (JMX) provide a standard mechanism to monitor and manage
|
||||
applications. By default, Spring Boot exposes management endpoints as JMX MBeans
|
||||
under the `org.springframework.boot` domain.
|
||||
applications. By default, Spring Boot exposes management endpoints as JMX MBeans under the
|
||||
`org.springframework.boot` domain.
|
||||
|
||||
|
||||
|
||||
[[production-ready-custom-mbean-names]]
|
||||
=== Customizing MBean Names
|
||||
The name of the MBean is usually generated from the `id` of the endpoint. For example
|
||||
the `health` endpoint is exposed as `org.springframework.boot:type=Endpoint,name=Health`.
|
||||
The name of the MBean is usually generated from the `id` of the endpoint. For example the
|
||||
`health` endpoint is exposed as `org.springframework.boot:type=Endpoint,name=Health`.
|
||||
|
||||
If your application contains more than one Spring `ApplicationContext`, you may find that
|
||||
names clash. To solve this problem, you can set the `management.endpoints.jmx.unique-names`
|
||||
property to `true` so that MBean names are always unique.
|
||||
names clash. To solve this problem, you can set the
|
||||
`management.endpoints.jmx.unique-names` property to `true` so that MBean names are always
|
||||
unique.
|
||||
|
||||
You can also customize the JMX domain under which endpoints are exposed. The following
|
||||
settings show an example of doing so in `application.properties`:
|
||||
@@ -773,8 +773,8 @@ settings show an example of doing so in `application.properties`:
|
||||
|
||||
[[production-ready-disable-jmx-endpoints]]
|
||||
=== Disabling JMX Endpoints
|
||||
If you do not want to expose endpoints over JMX, you can set the `endpoints.default.jmx.enabled`
|
||||
property to `false`, as shown in the following example:
|
||||
If you do not want to expose endpoints over JMX, you can set the
|
||||
`endpoints.default.jmx.enabled` property to `false`, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
@@ -785,9 +785,9 @@ property to `false`, as shown in the following example:
|
||||
|
||||
[[production-ready-jolokia]]
|
||||
=== Using Jolokia for JMX over HTTP
|
||||
Jolokia is a JMX-HTTP bridge that provides an alternative method of accessing JMX beans. To
|
||||
use Jolokia, include a dependency to `org.jolokia:jolokia-core`. For example,
|
||||
with Maven, you would add the following dependency:
|
||||
Jolokia is a JMX-HTTP bridge that provides an alternative method of accessing JMX beans.
|
||||
To use Jolokia, include a dependency to `org.jolokia:jolokia-core`. For example, with
|
||||
Maven, you would add the following dependency:
|
||||
|
||||
[source,xml,indent=0]
|
||||
----
|
||||
@@ -797,7 +797,8 @@ with Maven, you would add the following dependency:
|
||||
</dependency>
|
||||
----
|
||||
|
||||
Jolokia can then be accessed by using `/application/jolokia` on your management HTTP server.
|
||||
Jolokia can then be accessed by using `/application/jolokia` on your management HTTP
|
||||
server.
|
||||
|
||||
|
||||
|
||||
@@ -831,7 +832,8 @@ If you use Jolokia but do not want Spring Boot to configure it, set the
|
||||
Spring Boot Actuator includes the ability to view and configure the log levels of your
|
||||
application at runtime. You can view either the entire list or an individual logger's
|
||||
configuration, which is made up of both the explicitly configured logging level as well as
|
||||
the effective logging level given to it by the logging framework. These levels can be one of:
|
||||
the effective logging level given to it by the logging framework. These levels can be one
|
||||
of:
|
||||
|
||||
* `TRACE`
|
||||
* `DEBUG`
|
||||
@@ -877,22 +879,21 @@ monitoring systems:
|
||||
- https://prometheus.io[Prometheus]
|
||||
|
||||
Micrometer provides a separate module for each supported monitoring system. Depending on
|
||||
one (or more) of these modules is sufficient to get started with Micrometer in your
|
||||
Spring Boot application. To learn more about Micrometer's capabilities, please refer to
|
||||
its https://micrometer.io/docs[reference documentation].
|
||||
one (or more) of these modules is sufficient to get started with Micrometer in your Spring
|
||||
Boot application. To learn more about Micrometer's capabilities, please refer to its
|
||||
https://micrometer.io/docs[reference documentation].
|
||||
|
||||
|
||||
|
||||
[[production-ready-metrics-spring-mvc]]
|
||||
=== Spring MVC Metrics
|
||||
Auto-configuration enables the instrumentation of requests handled by Spring MVC.
|
||||
When `spring.metrics.web.server.auto-time-requests` is `true`, this instrumentation
|
||||
occurs for all requests. Alternatively, when set to `false`, you can enable instrumentation
|
||||
by adding `@Timed` to a request-handling method.
|
||||
Auto-configuration enables the instrumentation of requests handled by Spring MVC. When
|
||||
`spring.metrics.web.server.auto-time-requests` is `true`, this instrumentation occurs for
|
||||
all requests. Alternatively, when set to `false`, you can enable instrumentation by adding
|
||||
`@Timed` to a request-handling method.
|
||||
|
||||
By default, metrics are generated with the name, `http.server.requests`. The name
|
||||
can be customized by setting the `spring.metrics.web.server.requests-metrics-name`
|
||||
property.
|
||||
By default, metrics are generated with the name, `http.server.requests`. The name can be
|
||||
customized by setting the `spring.metrics.web.server.requests-metrics-name` property.
|
||||
|
||||
|
||||
|
||||
@@ -911,8 +912,8 @@ To customize the tags, provide a `@Bean` that implements `WebMvcTagsProvider`.
|
||||
[[production-ready-metrics-web-flux]]
|
||||
=== WebFlux Metrics
|
||||
Auto-configuration enables the instrumentation of all requests handled by WebFlux
|
||||
controllers. You can also use a helper class, `RouterFunctionMetrics`,
|
||||
to instrument applications that use WebFlux's functional programming model.
|
||||
controllers. You can also use a helper class, `RouterFunctionMetrics`, to instrument
|
||||
applications that use WebFlux's functional programming model.
|
||||
|
||||
By default, metrics are generated with the name `http.server.requests`. You can customize
|
||||
the name by setting the `spring.metrics.web.server.requests-metrics-name` property.
|
||||
@@ -921,8 +922,8 @@ the name by setting the `spring.metrics.web.server.requests-metrics-name` proper
|
||||
|
||||
[[production-ready-metrics-web-flux-tags]]
|
||||
==== WebFlux Metric Tags
|
||||
By default, WebFlux-related metrics for the annotation-based programming model are
|
||||
tagged with the following information:
|
||||
By default, WebFlux-related metrics for the annotation-based programming model are tagged
|
||||
with the following information:
|
||||
|
||||
- The request's method.
|
||||
- The request's URI (templated if possible).
|
||||
@@ -931,8 +932,8 @@ tagged with the following information:
|
||||
|
||||
To customize the tags, provide a `@Bean` that implements `WebFluxTagsProvider`.
|
||||
|
||||
By default, metrics for the functional programming model are tagged with the
|
||||
following information:
|
||||
By default, metrics for the functional programming model are tagged with the following
|
||||
information:
|
||||
|
||||
- The request's method
|
||||
- The request's URI (templated if possible).
|
||||
@@ -946,19 +947,18 @@ instance.
|
||||
[[production-ready-metrics-rest-template]]
|
||||
=== RestTemplate Metrics
|
||||
Auto-configuration customizes the auto-configured `RestTemplate` to enable the
|
||||
instrumentation of its requests. `MetricsRestTemplateCustomizer` can be used to
|
||||
customize your own `RestTemplate` instances.
|
||||
instrumentation of its requests. `MetricsRestTemplateCustomizer` can be used to customize
|
||||
your own `RestTemplate` instances.
|
||||
|
||||
By default, metrics are generated with the name, `http.client.requests`. The name
|
||||
can be customized by setting the `spring.metrics.web.client.requests-metrics-name`
|
||||
property.
|
||||
By default, metrics are generated with the name, `http.client.requests`. The name can be
|
||||
customized by setting the `spring.metrics.web.client.requests-metrics-name` property.
|
||||
|
||||
|
||||
|
||||
[[production-ready-metrics-rest-template-tags]]
|
||||
==== RestTemplate Metric Tags
|
||||
By default, metrics generated by an instrumented `RestTemplate` are tagged with
|
||||
the following information:
|
||||
By default, metrics generated by an instrumented `RestTemplate` are tagged with the
|
||||
following information:
|
||||
|
||||
- The request's method.
|
||||
- The request's URI (templated if possible).
|
||||
@@ -1042,16 +1042,16 @@ Auto-configuration enables binding of a number of Spring Integration-related met
|
||||
[[production-ready-auditing]]
|
||||
== Auditing
|
||||
Once Spring Security is in play Spring Boot Actuator has a flexible audit framework that
|
||||
publishes events (by default, '`authentication success`', '`failure`' and '`access denied`'
|
||||
exceptions). This feature can be very useful for reporting and for implementing a
|
||||
lock-out policy based on authentication failures. To customize published security events,
|
||||
you can provide your own implementations of `AbstractAuthenticationAuditListener` and
|
||||
`AbstractAuthorizationAuditListener`.
|
||||
publishes events (by default, '`authentication success`', '`failure`' and
|
||||
'`access denied`' exceptions). This feature can be very useful for reporting and for
|
||||
implementing a lock-out policy based on authentication failures. To customize published
|
||||
security events, you can provide your own implementations of
|
||||
`AbstractAuthenticationAuditListener` and `AbstractAuthorizationAuditListener`.
|
||||
|
||||
You can also use the audit services for your own business events. To do so,
|
||||
either inject the existing `AuditEventRepository` into your own components and
|
||||
use that directly or publish an `AuditApplicationEvent` with the Spring
|
||||
`ApplicationEventPublisher` (by implementing `ApplicationEventPublisherAware`).
|
||||
You can also use the audit services for your own business events. To do so, either inject
|
||||
the existing `AuditEventRepository` into your own components and use that directly or
|
||||
publish an `AuditApplicationEvent` with the Spring `ApplicationEventPublisher` (by
|
||||
implementing `ApplicationEventPublisherAware`).
|
||||
|
||||
|
||||
|
||||
@@ -1121,20 +1121,20 @@ By default, the trace includes the following information:
|
||||
=== Custom tracing
|
||||
If you need to trace additional events, you can inject a
|
||||
{sc-spring-boot-actuator}/trace/TraceRepository.{sc-ext}[`TraceRepository`] into your
|
||||
Spring beans. The `add` method accepts a single `Map` structure that is converted to
|
||||
JSON and logged.
|
||||
Spring beans. The `add` method accepts a single `Map` structure that is converted to JSON
|
||||
and logged.
|
||||
|
||||
By default, an `InMemoryTraceRepository` that stores the last 100 events is used. If you
|
||||
need to expand the capacity, you can define your own instance of the
|
||||
`InMemoryTraceRepository` bean. You can also create your own alternative
|
||||
`TraceRepository` implementation.
|
||||
`InMemoryTraceRepository` bean. You can also create your own alternative `TraceRepository`
|
||||
implementation.
|
||||
|
||||
|
||||
|
||||
[[production-ready-process-monitoring]]
|
||||
== Process Monitoring
|
||||
In the `spring-boot` module, you can find two classes to create files that are often useful
|
||||
for process monitoring:
|
||||
In the `spring-boot` module, you can find two classes to create files that are often
|
||||
useful for process monitoring:
|
||||
|
||||
* `ApplicationPidFileWriter` creates a file containing the application PID (by default, in
|
||||
the application directory with the file name, `application.pid`).
|
||||
@@ -1149,8 +1149,8 @@ described in the next section.
|
||||
|
||||
[[production-ready-process-monitoring-configuration]]
|
||||
=== Extend Configuration
|
||||
In the `META-INF/spring.factories` file, you can activate the listener(s) that
|
||||
writes a PID file, as shown in the following example:
|
||||
In the `META-INF/spring.factories` file, you can activate the listener(s) that writes a
|
||||
PID file, as shown in the following example:
|
||||
|
||||
[indent=0]
|
||||
----
|
||||
@@ -1164,8 +1164,8 @@ writes a PID file, as shown in the following example:
|
||||
[[production-ready-process-monitoring-programmatically]]
|
||||
=== Programmatically
|
||||
You can also activate a listener by invoking the `SpringApplication.addListeners(...)`
|
||||
method and passing the appropriate `Writer` object. This method also lets you
|
||||
customize the file name and path in the `Writer` constructor.
|
||||
method and passing the appropriate `Writer` object. This method also lets you customize
|
||||
the file name and path in the `Writer` constructor.
|
||||
|
||||
|
||||
|
||||
@@ -1175,10 +1175,10 @@ Spring Boot's actuator module includes additional support that is activated when
|
||||
deploy to a compatible Cloud Foundry instance. The `/cloudfoundryapplication` path
|
||||
provides an alternative secured route to all `@Endpoint` beans.
|
||||
|
||||
The extended support lets Cloud Foundry management UIs (such as the web
|
||||
application that you can use to view deployed applications) be augmented with Spring
|
||||
Boot actuator information. For example, an application status page may include full health
|
||||
information instead of the typical "`running`" or "`stopped`" status.
|
||||
The extended support lets Cloud Foundry management UIs (such as the web application that
|
||||
you can use to view deployed applications) be augmented with Spring Boot actuator
|
||||
information. For example, an application status page may include full health information
|
||||
instead of the typical "`running`" or "`stopped`" status.
|
||||
|
||||
NOTE: The `/cloudfoundryapplication` path is not directly accessible to regular users.
|
||||
In order to use the endpoint, a valid UAA token must be passed with the request.
|
||||
@@ -1216,9 +1216,9 @@ services use self-signed certificates, you need to set the following property:
|
||||
[[production-ready-cloudfoundry-custom-security]]
|
||||
=== Custom Security Configuration
|
||||
If you define custom security configuration and you want extended Cloud Foundry actuator
|
||||
support, you should ensure that `/cloudfoundryapplication/**` paths are open. Without
|
||||
a direct open route, your Cloud Foundry application manager is not able to obtain
|
||||
endpoint data.
|
||||
support, you should ensure that `/cloudfoundryapplication/**` paths are open. Without a
|
||||
direct open route, your Cloud Foundry application manager is not able to obtain endpoint
|
||||
data.
|
||||
|
||||
For Spring Security, you typically include something like
|
||||
`mvcMatchers("/cloudfoundryapplication/**").permitAll()` in your configuration, as shown
|
||||
@@ -1237,7 +1237,6 @@ If you want to explore some of the concepts discussed in this chapter, you can t
|
||||
look at the actuator {github-code}/spring-boot-samples[sample applications]. You also
|
||||
might want to read about graphing tools such as http://graphite.wikidot.com/[Graphite].
|
||||
|
||||
Otherwise, you can continue on, to read about <<deployment.adoc#deployment,
|
||||
'`deployment options`'>> or jump ahead
|
||||
for some in-depth information about Spring Boot's
|
||||
Otherwise, you can continue on, to read about <<deployment.adoc#deployment, '`deployment
|
||||
options`'>> or jump ahead for some in-depth information about Spring Boot's
|
||||
_<<build-tool-plugins.adoc#build-tool-plugins, build tool plugins>>_.
|
||||
|
||||
Reference in New Issue
Block a user