@@ -57,10 +57,10 @@ Actuator endpoints let you monitor and interact with your application. Spring Bo
57
57
includes a number of built-in endpoints and lets you add your own. For example, the
58
58
`health` endpoint provides basic application health information.
59
59
60
- The way that endpoints are exposed depends on the type of technology that you choose. Most
61
- applications choose HTTP monitoring, where the ID of the endpoint along with a prefix of
62
- `/application` is mapped to a URL. For example, by default, the `health` endpoint is
63
- mapped to `/application/health`.
60
+ The way that endpoints are exposed depends on the type of technology that you choose.
61
+ Most applications choose HTTP monitoring, where the ID of the endpoint along with a
62
+ prefix of `/application` is mapped to a URL. For example, by default, the `health`
63
+ endpoint is mapped to `/application/health`.
64
64
65
65
The following technology-agnostic endpoints are available:
66
66
@@ -171,8 +171,8 @@ user authentication. When '`Spring Security`' is added, by default, '`basic`'
171
171
authentication is used. The username is`user` and the password is a random generated
172
172
password (which is printed on the console when the application starts).
173
173
174
- TIP: Generated passwords are logged as the application starts. To find the password in the
175
- console, search for '`Using default security password`'.
174
+ TIP: Generated passwords are logged as the application starts. To find the password in
175
+ the console, search for '`Using default security password`'.
176
176
177
177
You can use Spring properties to change the username and password and to change the
178
178
security role(s) required to access the endpoints. For example, you might set the
@@ -187,8 +187,8 @@ following properties in your `application.properties`:
187
187
188
188
If your application has custom security configuration and you want all your actuator
189
189
endpoints to be accessible without authentication, you need to explicitly configure that
190
- in your security configuration. Also, you need to change the `management.security.enabled`
191
- property to `false`.
190
+ in your security configuration. Also, you need to change the
191
+ `management.security.enabled` property to `false`.
192
192
193
193
If your custom security configuration secures your actuator endpoints, you also need to
194
194
ensure that the authenticated user has the roles specified under
@@ -203,11 +203,11 @@ additional role check.
203
203
204
204
[[production-ready-customizing-endpoints]]
205
205
=== Customizing Endpoints
206
- Endpoints can be customized by using Spring properties. You can change whether an endpoint
207
- is `enabled` and its `id`.
206
+ Endpoints can be customized by using Spring properties. You can change whether an
207
+ endpoint is `enabled` and its `id`.
208
208
209
- For example, the following `application.properties` changes the id of the `beans` endpoint
210
- and also enables `shutdown`:
209
+ For example, the following `application.properties` changes the id of the `beans`
210
+ endpoint and also enables `shutdown`:
211
211
212
212
[source,properties,indent=0]
213
213
----
@@ -218,9 +218,9 @@ and also enables `shutdown`:
218
218
NOTE: The prefix ‟`endpoints` + `.` + `name`” is used to uniquely identify the endpoint
219
219
that is being configured.
220
220
221
- By default, all endpoints except for `shutdown` are enabled. If you prefer to specifically
222
- "`opt-in`" endpoint enablement, you can use the `endpoints.default.enabled` property. For
223
- example, the following settings disables _all_ endpoints except for `info`:
221
+ By default, all endpoints except for `shutdown` are enabled. If you prefer to
222
+ specifically "`opt-in`" endpoint enablement, you can use the `endpoints.default.enabled`
223
+ property. For example, the following settings disables _all_ endpoints except for `info`:
224
224
225
225
[source,properties,indent=0]
226
226
----
@@ -272,29 +272,29 @@ application, over HTTP as well.
272
272
273
273
TIP: If you do this as a library feature, consider adding a configuration class annotated
274
274
with `@ManagementContextConfiguration` to `/META-INF/spring.factories` under the key,
275
- `org.springframework.boot.actuate.autoconfigure.ManagementContextConfiguration`. If you do
276
- so and if your users ask for a separate management port or address, the endpoint moves to
277
- a child context with all the other web endpoints.
275
+ `org.springframework.boot.actuate.autoconfigure.ManagementContextConfiguration`. If you
276
+ do so and if your users ask for a separate management port or address, the endpoint moves
277
+ to a child context with all the other web endpoints.
278
278
279
279
280
280
281
281
[[production-ready-health]]
282
282
=== Health Information
283
283
You can use health information to check the status of your running application. It is
284
- often used by monitoring software to alert someone when a production system goes down. The
285
- default information exposed by the `health` endpoint depends on how it is accessed. For an
286
- unauthenticated connection in a secure application, a simple '`status`' message is
284
+ often used by monitoring software to alert someone when a production system goes down.
285
+ The default information exposed by the `health` endpoint depends on how it is accessed.
286
+ For an unauthenticated connection in a secure application, a simple '`status`' message is
287
287
returned. For an authenticated connection, additional details are also displayed. (See
288
288
<<production-ready-health-access-restrictions>> for HTTP details.)
289
289
290
290
Health information is collected from all
291
- {sc-spring-boot-actuator}/health/HealthIndicator.{sc-ext}[`HealthIndicator`] beans defined
292
- in your `ApplicationContext`. Spring Boot includes a number of auto-configured
293
- `HealthIndicators`, and you can also write your own. By default, the final system state is
294
- derived by the `HealthAggregator`, which sorts the statuses from each `HealthIndicator`
295
- based on an ordered list of statuses. The first status in the sorted list is used as the
296
- overall health status. If no `HealthIndicator` returns a status that is known to the
297
- `HealthAggregator`, an `UNKNOWN` status is used.
291
+ {sc-spring-boot-actuator}/health/HealthIndicator.{sc-ext}[`HealthIndicator`] beans
292
+ defined in your `ApplicationContext`. Spring Boot includes a number of auto-configured
293
+ `HealthIndicators`, and you can also write your own. By default, the final system state
294
+ is derived by the `HealthAggregator`, which sorts the statuses from each
295
+ `HealthIndicator` based on an ordered list of statuses. The first status in the sorted
296
+ list is used as the overall health status. If no `HealthIndicator` returns a status that
297
+ is known to the `HealthAggregator`, an `UNKNOWN` status is used.
298
298
299
299
300
300
@@ -373,12 +373,13 @@ NOTE: The identifier for a given `HealthIndicator` is the name of the bean witho
373
373
`HealthIndicator` suffix, if it exists. In the preceding example, the health information
374
374
is available in an entry named `my`.
375
375
376
- In addition to Spring Boot's predefined {sc-spring-boot-actuator}/health/Status.{sc-ext}[`Status`]
377
- types, it is also possible for `Health` to return a custom `Status` that represents a new
378
- system state. In such cases, a custom implementation of the
376
+ In addition to Spring Boot's predefined
377
+ {sc-spring-boot-actuator}/health/Status.{sc-ext}[`Status`] types, it is also possible for
378
+ `Health` to return a custom `Status` that represents a new system state. In such cases, a
379
+ custom implementation of the
379
380
{sc-spring-boot-actuator}/health/HealthAggregator.{sc-ext}[`HealthAggregator`] interface
380
- also needs to be provided, or the default implementation has to be configured by using the
381
- `management.health.status.order` configuration property.
381
+ also needs to be provided, or the default implementation has to be configured by using
382
+ the `management.health.status.order` configuration property.
382
383
383
384
For example, assume a new `Status` with code `FATAL` is being used in one of your
384
385
`HealthIndicator` implementations. To configure the severity order, add the following
@@ -389,8 +390,8 @@ to your application properties:
389
390
management.health.status.order=FATAL, DOWN, OUT_OF_SERVICE, UNKNOWN, UP
390
391
----
391
392
392
- The HTTP status code in the response reflects the overall health status (for example, `UP`
393
- maps to 200, while `OUT_OF_SERVICE` and `DOWN` map to 503). You might also want to
393
+ The HTTP status code in the response reflects the overall health status (for example,
394
+ `UP` maps to 200, while `OUT_OF_SERVICE` and `DOWN` map to 503). You might also want to
394
395
register custom status mappings if you access the health endpoint over HTTP. For example,
395
396
the following property maps `FATAL` to 503 (service unavailable):
396
397
@@ -454,8 +455,8 @@ property.
454
455
[[production-ready-application-info-env]]
455
456
==== Custom Application Information
456
457
You can customize the data exposed by the `info` endpoint by setting `+info.*+` Spring
457
- properties. All `Environment` properties under the info key are automatically exposed. For
458
- example, you could add the following settings to your `application.properties` file:
458
+ properties. All `Environment` properties under the info key are automatically exposed.
459
+ For example, you could add the following settings to your `application.properties` file:
459
460
460
461
[source,properties,indent=0]
461
462
----
@@ -485,8 +486,8 @@ Assuming you use Maven, you could rewrite the preceding example as follows:
485
486
==== Git Commit Information
486
487
Another useful feature of the `info` endpoint is its ability to publish information about
487
488
the state of your `git` source code repository when the project was built. If a
488
- `GitProperties` bean is available, the `git.branch`, `git.commit.id` and `git.commit.time`
489
- properties are exposed.
489
+ `GitProperties` bean is available, the `git.branch`, `git.commit.id` and
490
+ `git.commit.time` properties are exposed.
490
491
491
492
TIP: A `GitProperties` bean is auto-configured if a `git.properties` file is available at
492
493
the root of the classpath. See
@@ -504,9 +505,9 @@ If you want to display the full git information (that is, the full content of
504
505
505
506
[[production-ready-application-info-build]]
506
507
==== Build Information
507
- If a `BuildProperties` bean is available, the `info` endpoint can also publish information
508
- about your build. This happens if a `META-INF/build-info.properties` file is available in
509
- the classpath.
508
+ If a `BuildProperties` bean is available, the `info` endpoint can also publish
509
+ information about your build. This happens if a `META-INF/build-info.properties` file is
510
+ available in the classpath.
510
511
511
512
TIP: The Maven and Gradle plugins can both generate that file. See
512
513
"<<howto.adoc#howto-build-info,Generate build information>>" for more details.
@@ -564,10 +565,10 @@ exposed as `/application/health`.
564
565
565
566
[[production-ready-customizing-management-server-context-path]]
566
567
=== Customizing the Management Endpoint Paths
567
- Sometimes, it is useful to customize the prefix for the management endpoints. For example,
568
- your application might already use `/application` for another purpose. You can use the
569
- `management.endpoints.web.base-path` property to change the prefix for your management
570
- endpoint, as shown in the following example:
568
+ Sometimes, it is useful to customize the prefix for the management endpoints. For
569
+ example, your application might already use `/application` for another purpose. You can
570
+ use the `management.endpoints.web.base-path` property to change the prefix for your
571
+ management endpoint, as shown in the following example:
571
572
572
573
[source,properties,indent=0]
573
574
----
@@ -591,18 +592,18 @@ Exposing management endpoints by using the default HTTP port is a sensible choic
591
592
cloud based deployments. If, however, your application runs inside your own data center,
592
593
you may prefer to expose endpoints by using a different HTTP port.
593
594
594
- You can set the `management.server.port` property to change the HTTP port, as shown in the
595
- following example:
595
+ You can set the `management.server.port` property to change the HTTP port, as shown in
596
+ the following example:
596
597
597
598
[source,properties,indent=0]
598
599
----
599
600
management.server.port=8081
600
601
----
601
602
602
- Since your management port is often protected by a firewall and not exposed to the public,
603
- you might not need security on the management endpoints, even if your main application is
604
- secure. In that case, you should have Spring Security on the classpath, and you can
605
- disable management security as follows:
603
+ Since your management port is often protected by a firewall and not exposed to the
604
+ public, you might not need security on the management endpoints, even if your main
605
+ application is secure. In that case, you should have Spring Security on the classpath,
606
+ and you can disable management security as follows:
606
607
607
608
[source,properties,indent=0]
608
609
----
@@ -682,10 +683,10 @@ If you do not want to expose endpoints over HTTP, you can set the management por
682
683
683
684
[[production-ready-health-access-restrictions]]
684
685
=== HTTP Health Endpoint Format and Access Restrictions
685
- The information exposed by the health endpoint varies, depending on whether it is accessed
686
- anonymously and whether the enclosing application is secure. By default, when accessed
687
- anonymously in a secure application, any details about the server's health are hidden and
688
- the endpoint indicates whether the server is up or down.
686
+ The information exposed by the health endpoint varies, depending on whether it is
687
+ accessed anonymously and whether the enclosing application is secure. By default, when
688
+ accessed anonymously in a secure application, any details about the server's health are
689
+ hidden and the endpoint indicates whether the server is up or down.
689
690
690
691
The following example shows a summarized HTTP response (default for anonymous request):
691
692
@@ -745,8 +746,8 @@ The following example shows a detailed HTTP response:
745
746
[[production-ready-jmx]]
746
747
== Monitoring and Management over JMX
747
748
Java Management Extensions (JMX) provide a standard mechanism to monitor and manage
748
- applications. By default, Spring Boot exposes management endpoints as JMX MBeans under the
749
- `org.springframework.boot` domain.
749
+ applications. By default, Spring Boot exposes management endpoints as JMX MBeans under
750
+ the `org.springframework.boot` domain.
750
751
751
752
752
753
@@ -831,9 +832,9 @@ If you use Jolokia but do not want Spring Boot to configure it, set the
831
832
== Loggers
832
833
Spring Boot Actuator includes the ability to view and configure the log levels of your
833
834
application at runtime. You can view either the entire list or an individual logger's
834
- configuration, which is made up of both the explicitly configured logging level as well as
835
- the effective logging level given to it by the logging framework. These levels can be one
836
- of:
835
+ configuration, which is made up of both the explicitly configured logging level as well
836
+ as the effective logging level given to it by the logging framework. These levels can be
837
+ one of:
837
838
838
839
* `TRACE`
839
840
* `DEBUG`
@@ -879,18 +880,18 @@ monitoring systems:
879
880
- https://prometheus.io[Prometheus]
880
881
881
882
Micrometer provides a separate module for each supported monitoring system. Depending on
882
- one (or more) of these modules is sufficient to get started with Micrometer in your Spring
883
- Boot application. To learn more about Micrometer's capabilities, please refer to its
884
- https://micrometer.io/docs[reference documentation].
883
+ one (or more) of these modules is sufficient to get started with Micrometer in your
884
+ Spring Boot application. To learn more about Micrometer's capabilities, please refer to
885
+ its https://micrometer.io/docs[reference documentation].
885
886
886
887
887
888
888
889
[[production-ready-metrics-spring-mvc]]
889
890
=== Spring MVC Metrics
890
891
Auto-configuration enables the instrumentation of requests handled by Spring MVC. When
891
892
`spring.metrics.web.server.auto-time-requests` is `true`, this instrumentation occurs for
892
- all requests. Alternatively, when set to `false`, you can enable instrumentation by adding
893
- `@Timed` to a request-handling method.
893
+ all requests. Alternatively, when set to `false`, you can enable instrumentation by
894
+ adding `@Timed` to a request-handling method.
894
895
895
896
By default, metrics are generated with the name, `http.server.requests`. The name can be
896
897
customized by setting the `spring.metrics.web.server.requests-metrics-name` property.
@@ -970,10 +971,10 @@ following information:
970
971
[[production-ready-metrics-jdbc]]
971
972
=== DataSource metrics
972
973
Auto-configuration will enable the instrumentation of all available `DataSources` with a
973
- metric named `data.source`. Data source instrumentation results in gauges representing the
974
- currently active, maximum allowed, and minimum allowed connections in the pool. Each of
975
- these gauges has a name which is prefixed by `data.source` by default. The prefix can be
976
- be customized using the `spring.metrics.jdbc.datasource-metric-name` property.
974
+ metric named `data.source`. Data source instrumentation results in gauges representing
975
+ the currently active, maximum allowed, and minimum allowed connections in the pool. Each
976
+ of these gauges has a name which is prefixed by `data.source` by default. The prefix can
977
+ be customized by using the `spring.metrics.jdbc.datasource-metric-name` property.
977
978
978
979
Metrics will also be tagged by the name of the `DataSource` computed based on the bean
979
980
name.
@@ -1126,8 +1127,8 @@ and logged.
1126
1127
1127
1128
By default, an `InMemoryTraceRepository` that stores the last 100 events is used. If you
1128
1129
need to expand the capacity, you can define your own instance of the
1129
- `InMemoryTraceRepository` bean. You can also create your own alternative `TraceRepository`
1130
- implementation.
1130
+ `InMemoryTraceRepository` bean. You can also create your own alternative
1131
+ `TraceRepository` implementation.
1131
1132
1132
1133
1133
1134
@@ -1136,11 +1137,11 @@ implementation.
1136
1137
In the `spring-boot` module, you can find two classes to create files that are often
1137
1138
useful for process monitoring:
1138
1139
1139
- * `ApplicationPidFileWriter` creates a file containing the application PID (by default, in
1140
- the application directory with the file name, `application.pid`).
1140
+ * `ApplicationPidFileWriter` creates a file containing the application PID (by default,
1141
+ in the application directory with the file name, `application.pid`).
1141
1142
* `EmbeddedServerPortFileWriter` creates a file (or files) containing the ports of the
1142
- embedded server (by default, in the application directory with the file name
1143
- `application.port`).
1143
+ embedded server (by default, in the application directory with the file name
1144
+ `application.port`).
1144
1145
1145
1146
By default, these writers are not activated, but you can enable them in one of the ways
1146
1147
described in the next section.
0 commit comments