mirror of
https://github.com/spring-projects/spring-boot.git
synced 2024-09-03 04:26:12 +08:00
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`).