mirror of
https://github.com/spring-projects/spring-boot.git
synced 2024-09-03 04:26:12 +08:00
cf24af0bfb
Prior to this commit LoggingSystem initialization would happen multiple
times. Once to configure "quiet" logging, and again to configure correct
settings once the Application was initialized. This could cause problems
if `logging.groovy` logback files were used.
The logging system is now only initialized once (when possible) by
following these steps:
- Standard logging initialization occurs via the actual logging
implementation used (e.g. logback will load a logback.xml file if it
exists)
- beforeInitization() is called to prevent early log output.
Implementations now either use a Filter or simply set the root logging
level.
- initialize() is called with an optional log configuration file (e.g
a custom logback.xml location) and an optional log output file (the
default is null indicating console only output).
The initialize() method will attempt to prevent double initialization
by checking if a standard configuration file exists. Double
initialization now only occurs in the following situations:
- The user has a standard configuration file (e.g. classpath:logback.xml)
but also specifies a logging.config property. Double initialization is
required since the specified configuration file supersedes the default.
- The user has a standard configuration file (e.g. classpath:logback.xml)
and specifies a logging.file property. Double initialization is
required since the standard configuration may use a ${LOG_FILE}
reference.
In addition this commit removes the `logging.console` option and now
assumes that logging either occurs only to console or to both the
console and a file. This restriction helps simplify the LoggingSystem
implementations. If file only logging is required a custom logback.xml
can be used.
Fixes gh-1091
See gh-1612, gh-1770
|
||
|---|---|---|
| .. | ||
| src | ||
| pom.xml | ||
| README.adoc | ||
= Spring Boot - Actuator
Spring Boot Actuator includes a number of additional features to help you monitor and
manage your application when it's pushed to production. You can choose to manage and
monitor your application using HTTP endpoints, with JMX or even by remote shell (SSH or
Telnet). Auditing, health and metrics gathering can be automatically applied to your
application. The
http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready[user guide]
covers the features in more detail.
== Enabling the Actuator
The simplest way to enable the features is to add a dependency to the
`spring-boot-starter-actuator` ``Starter POM''. To add the actuator to a Maven based
project, add the following "starter" dependency:
[source,xml,indent=0]
----
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
</dependencies>
----
For Gradle, use the declaration:
[indent=0]
----
dependencies {
compile("org.springframework.boot:spring-boot-starter-actuator")
}
----
== Features
* **Endpoints** Actuator endpoints allow you to monitor and interact with your
application. Spring Boot includes a number of built-in endpoints and you can also add
your own. For example the `health` endpoint provides basic application health
information. Run up a basic application and look at `/health` (and see `/mappings` for
a list of other HTTP endpoints).
* **Metrics** Spring Boot Actuator includes a metrics service with ``gauge'' and
``counter'' support. A ``gauge'' records a single value; and a ``counter'' records a
delta (an increment or decrement). Metrics for all HTTP requests are automatically
recorded, so if you hit the `metrics` endpoint should should see a sensible response.
* **Audit** Spring Boot Actuator has a flexible audit framework that will publish events
to an `AuditService`. Once Spring Security is in play it automatically publishes
authentication events by default. This can be very useful for reporting, and also to
implement a lock-out policy based on authentication failures.
* **Process Monitoring** In Spring Boot Actuator you can find `ApplicationPidListener`
which creates a file containing the application PID (by default in the application
directory with a file name of `application.pid`).