You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
157 lines
6.2 KiB
Markdown
157 lines
6.2 KiB
Markdown
12 years ago
|
# Spring Actuator Feature Guide
|
||
12 years ago
|
|
||
12 years ago
|
Here are some (most, hopefully all) the features of Spring Actuator
|
||
|
with some commentary to help you start using them. We
|
||
12 years ago
|
recommend you first build a project with the Actuator (e.g. the
|
||
|
getting started project from the main README), and then try each
|
||
|
feature in turn there.
|
||
|
|
||
12 years ago
|
Many useful features of
|
||
11 years ago
|
[Spring Boot](../../spring-boot/README.md) are all available
|
||
12 years ago
|
in an Actuator application.
|
||
12 years ago
|
|
||
|
TODO: group things together and break them out into separate files.
|
||
|
|
||
|
## Customizing Management Endpoints
|
||
|
|
||
|
The `ManagementProperties` are bound to application properties, and
|
||
|
can be used to specify
|
||
|
|
||
|
* The port that the application listens on for the management
|
||
|
endpoints (defaults to 8080)
|
||
|
|
||
|
* The address that the management endpoints are available on (if the
|
||
|
port is different to the main server port). Use this to listen only
|
||
|
on an internal or ops-facing network, for instance, or to only
|
||
|
listen for connections from localhost (by specifying "127.0.0.1")
|
||
|
|
||
12 years ago
|
* The context root of the management endpoints
|
||
12 years ago
|
|
||
|
## Error Handling
|
||
|
|
||
12 years ago
|
The Actuator provides an `/error` mapping by default that handles all
|
||
12 years ago
|
errors in a sensible way. If you want more specific error pages for
|
||
|
some conditions, the embedded servlet containers support a uniform
|
||
|
Java DSL for customizing the error handling. To do this you have to
|
||
|
have picked a container implementation (by including either Tomcat or
|
||
|
Jetty on the classpath), but then the API is the same. TODO: finish
|
||
|
this.
|
||
|
|
||
12 years ago
|
## Info Endpoint
|
||
|
|
||
|
By default the Actuator adds an `/info` endpoint to the main server.
|
||
|
It contains the commit and timestamp information from `git.properties`
|
||
|
(if that file exists) and also any properties it finds in the
|
||
12 years ago
|
environment with prefix "info".
|
||
|
|
||
|
To populate `git.properties` in a
|
||
12 years ago
|
Maven build you can use the excellent
|
||
|
[git-commit-id-plugin](https://github.com/ktoso/maven-git-commit-id-plugin).
|
||
12 years ago
|
|
||
12 years ago
|
To populate the "info" map all you need to do is add some stuff to
|
||
|
`application.properties`, e.g.
|
||
|
|
||
|
info.app.name: MyService
|
||
|
info.app.description: My awesome service
|
||
|
info.app.version: 1.0.0
|
||
|
|
||
12 years ago
|
If you are using Maven you can automcatically populate info properties
|
||
|
from the project using resource filtering. In your `pom.xml` you
|
||
|
have (inside the `<build/>` element):
|
||
|
|
||
|
<resources>
|
||
|
<resource>
|
||
|
<directory>src/main/resources</directory>
|
||
|
<filtering>true</filtering>
|
||
|
</resource>
|
||
|
</resources>
|
||
|
|
||
|
and then in the `application.properties` you can refer to project
|
||
|
properties via placeholders, e.g.
|
||
|
|
||
|
project.artifactId: myproject
|
||
|
project.name: Demo
|
||
|
project.version: X.X.X.X
|
||
|
project.description: Demo project for info endpoint
|
||
|
info.build.artifact: ${project.artifactId}
|
||
|
info.build.name: ${project.name}
|
||
|
info.build.description: ${project.description}
|
||
|
info.build.version: ${project.version}
|
||
12 years ago
|
|
||
12 years ago
|
(notice that in the example we used `project.*` to set some values to
|
||
|
be used as fallbacks if the Maven resource filtering has for some
|
||
|
reason not been switched on).
|
||
|
|
||
12 years ago
|
## Security - Basic Authentication
|
||
|
|
||
|
To secure your endpoints just add Spring Security Javaconfig to the
|
||
|
classpath. By default HTTP Basic authentication will be applied to
|
||
|
every request in the main server (and the management server if it is
|
||
|
running on the same port). There is a single account by default, and
|
||
|
you can test it like this:
|
||
|
|
||
12 years ago
|
$ mvn user:password@localhost:8080/metrics
|
||
12 years ago
|
... stuff comes out
|
||
12 years ago
|
|
||
12 years ago
|
If the management server is running on a different port it is
|
||
|
unsecured by default. If you want to secure it you can add a security
|
||
|
auto configuration explicitly
|
||
|
|
||
12 years ago
|
## Security - HTTPS
|
||
|
|
||
12 years ago
|
Ensuring that all your main endpoints are only available over HTTPS is
|
||
|
an important chore for any application. If you are using Tomcat as a
|
||
|
servlet container, then the Actuator will add Tomcat's own
|
||
|
`RemoteIpValve` automatically if it detects some environment settings,
|
||
|
and you should be able to rely on the `HttpServletRequest` to report
|
||
|
whether or not it is secure (even downstream of the real SSL
|
||
|
termination endpoint). The standard behaviour is determined by the
|
||
|
presence or absence of certain request headers ("x-forwarded-for" and
|
||
|
"x-forwarded-proto"), whose names are conventional, so it should work
|
||
|
with most front end proxies. You switch on the valve by adding some
|
||
|
entries to `application.properties`, e.g.
|
||
|
|
||
|
server.tomcat.remote_ip_header: x-forwarded-for
|
||
|
server.tomcat.protocol_header: x-forwarded-proto
|
||
12 years ago
|
|
||
12 years ago
|
(The presence of either of those properties will switch on the
|
||
|
valve. Or you can add the `RemoteIpValve` yourself by adding a
|
||
12 years ago
|
`TomcatEmbeddedServletContainerFactory` bean.)
|
||
|
|
||
12 years ago
|
Spring Security can also be configured to require a secure channel for
|
||
|
all (or some requests). To switch that on in an Actuator application
|
||
|
you just need to set `security.require_https: true` in
|
||
|
`application.properties`.
|
||
12 years ago
|
|
||
|
## Audit Events
|
||
|
|
||
12 years ago
|
The Actuator has a flexible audit framework that will publish events
|
||
|
once Spring Security is in play (authentication success and failure
|
||
|
and access denied exceptions by default). This can be very useful for
|
||
|
reporting, and also to implement a lock-out policy based on
|
||
|
authentication failures.
|
||
|
|
||
|
You can also choose to use the audit services for your own business
|
||
|
events. To do that you can either inject the existing
|
||
|
`AuditEventRepository` into your own components and use that directly,
|
||
|
or you can simply publish `AuditApplicationEvent` via the Spring
|
||
|
`ApplicationContext` (using `ApplicationEventPublisherAware`).
|
||
|
|
||
12 years ago
|
## Metrics Customization
|
||
|
|
||
12 years ago
|
Metrics come out on the `/metrics` endpoint. You can add additional
|
||
12 years ago
|
metrics by injecting a `MetricsRepository` into your application
|
||
|
components and adding metrics whenever you need to. To customize the
|
||
|
`MetricsRepository` itself, just add a bean definition of that type to
|
||
|
the application context (only in memory is supported out of the box
|
||
|
for now).
|
||
|
|
||
|
## Customizing the Health Indicator
|
||
|
|
||
12 years ago
|
The application always tells you if it's healthy via the `/health`
|
||
12 years ago
|
endpoint. By default it just responds to a GET witha 200 status and a
|
||
|
plain text body containing "ok". If you want to add more detailed
|
||
|
information (e.g. a description of the current state of the
|
||
|
application), just add a bean of type `HealthIndicator` to your
|
||
|
application context, and it will take the place of the default one.
|