Monitoring and management over HTTP
If you are developing a Spring MVC application, Spring Boot Actuator will auto-configure
all enabled endpoints to be exposed over HTTP. The default convention is to use the
id
of the endpoint as the URL path. For example, health
is exposed as /health
.
Accessing sensitive endpoints
By default all sensitive HTTP endpoints are secured such that only users that have an
ACTUATOR
role may access them. Security is enforced using the standard
HttpServletRequest.isUserInRole
method.
Use the management.security.roles property if you want something different to
ACTUATOR .
|
If you are deploying applications behind a firewall, you may prefer that all your actuator
endpoints can be accessed without requiring authentication. You can do this by changing
the management.security.enabled
property:
management.security.enabled=false
By default, actuator endpoints are exposed on the same port that serves regular
HTTP traffic. Take care not to accidentally expose sensitive information if you change
the management.security.enabled property.
|
If you’re deploying applications publicly, you may want to add ‘Spring Security’ to
handle user authentication. When ‘Spring Security’ is added, by default ‘basic’
authentication will be used with the username user
and a generated password (which is
printed on the console when the application starts).
Generated passwords are logged as the application starts. 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
in your application.properties
:
security.user.name=admin
security.user.password=secret
management.security.roles=SUPERUSER
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. Along with that, 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
.
If you don’t 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 will inform Spring Boot to skip the additional role check.
|
Customizing the management endpoint paths
Sometimes it is useful to group all management endpoints under a single path. For example,
your application might already use /info
for another purpose. You can use the
management.context-path
property to set a prefix for your management endpoint:
management.context-path=/manage
The application.properties
example above will change the endpoint from /{id}
to
/manage/{id}
(e.g. /manage/info
).
Unless the management port has been configured to
expose endpoints using a different
HTTP port, management.context-path is relative to server.context-path .
|
You can also change the “id” of an endpoint (using endpoints.{name}.id
) which then
changes the default resource path for the MVC endpoint. Legal endpoint ids are composed
only of alphanumeric characters (because they can be exposed in a number of places,
including JMX object names, where special characters are forbidden). The MVC path can be
changed separately by configuring endpoints.{name}.path
, and there is no validation on
those values (so you can use anything that is legal in a URL path). For example, to change
the location of the /health
endpoint to /ping/me
you can set
endpoints.health.path=/ping/me
.
Even if an endpoint path is configured separately, it is still relative to the
management.context-path .
|
If you provide a custom MvcEndpoint remember to include a settable path property,
and default it to /{id} if you want your code to behave like the standard MVC endpoints.
(Take a look at the HealthMvcEndpoint to see how you might do that.) If your custom
endpoint is an Endpoint (not an MvcEndpoint ) then Spring Boot will take care of the
path for you.
|
Customizing the management server port
Exposing management endpoints 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 using a different HTTP port.
The management.port
property can be used to change the HTTP port.
management.port=8081
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 will have Spring Security on the classpath, and you can disable management security like this:
management.security.enabled=false
(If you don’t have Spring Security on the classpath then there is no need to explicitly disable the management security in this way, and it might even break the application.)
Configuring management-specific SSL
When configured to use a custom port, the management server can also be configured with
its own SSL using the various management.ssl.*
properties. For example, this allows a
management server to be available via HTTP while the main application uses HTTPS:
server.port=8443
server.ssl.enabled=true
server.ssl.key-store=classpath:store.jks
server.ssl.key-password=secret
management.port=8080
management.ssl.enabled=false
Alternatively, both the main server and the management server can use SSL but with different key stores:
server.port=8443
server.ssl.enabled=true
server.ssl.key-store=classpath:main.jks
server.ssl.key-password=secret
management.port=8080
management.ssl.enabled=true
management.ssl.key-store=classpath:management.jks
management.ssl.key-password=secret
Customizing the management server address
You can customize the address that the management endpoints are available on by
setting the management.address
property. This can be useful if you want to
listen only on an internal or ops-facing network, or to only listen for connections from
localhost
.
You can only listen on a different address if the port is different to the main server port. |
Here is an example application.properties
that will not allow remote management
connections:
management.port=8081
management.address=127.0.0.1
Disabling HTTP endpoints
If you don’t want to expose endpoints over HTTP you can set the management port to -1
:
management.port=-1
HTTP health endpoint format and access restrictions
The information exposed by the health endpoint varies depending on whether or not it’s
accessed anonymously, and whether or not 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 will simply indicate whether or not the server
is up or down. Furthermore the response is cached for a configurable period to prevent the
endpoint being used in a denial of service attack. The endpoints.health.time-to-live
property is used to configure the caching period in milliseconds. It defaults to 1000,
i.e. one second.
Sample summarized HTTP response (default for anonymous request):
$ curl -i localhost:8080/health
HTTP/1.1 200
X-Application-Context: application
Content-Type: application/vnd.spring-boot.actuator.v1+json;charset=UTF-8
Content-Length: 15
{"status":"UP"}
Sample summarized HTTP response for status "DOWN" (notice the 503 status code):
$ curl -i localhost:8080/health
HTTP/1.1 503
X-Application-Context: application
Content-Type: application/vnd.spring-boot.actuator.v1+json;charset=UTF-8
Content-Length: 17
{"status":"DOWN"}
Sample detailed HTTP response:
$ curl -i localhost:8080/health
HTTP/1.1 200 OK
X-Application-Context: application
Content-Type: application/vnd.spring-boot.actuator.v1+json;charset=UTF-8
Content-Length: 221
{
"status" : "UP",
"diskSpace" : {
"status" : "UP",
"total" : 63251804160,
"free" : 31316164608,
"threshold" : 10485760
},
"db" : {
"status" : "UP",
"database" : "H2",
"hello" : 1
}
}
The above-described restrictions can be enhanced, thereby allowing only authenticated
users full access to the health endpoint in a secure application. To do so, set
endpoints.health.sensitive
to true
. Here’s a summary of behavior (with default
sensitive
flag value “false” indicated in bold):
management.security.enabled |
endpoints.health.sensitive |
Unauthenticated | Authenticated (with right role) |
---|---|---|---|
false |
* |
Full content |
Full content |
true |
false |
Status only |
Full content |
true |
true |
No content |
Full content |