mirror of
https://github.com/spring-projects/spring-boot.git
synced 2024-08-29 03:06:45 +08:00
Migrate actuator-autoconfigure to Antora
See gh-33766
This commit is contained in:
parent
8d64e99714
commit
f35d6b6bd6
@ -1,6 +1,6 @@
|
||||
plugins {
|
||||
id "java-library"
|
||||
id "org.asciidoctor.jvm.convert"
|
||||
id "org.antora"
|
||||
id "org.springframework.boot.auto-configuration"
|
||||
id "org.springframework.boot.configuration-properties"
|
||||
id "org.springframework.boot.conventions"
|
||||
@ -11,13 +11,10 @@ plugins {
|
||||
description = "Spring Boot Actuator AutoConfigure"
|
||||
|
||||
configurations {
|
||||
documentation
|
||||
antoraContent
|
||||
}
|
||||
|
||||
dependencies {
|
||||
asciidoctorExtensions("org.springframework.restdocs:spring-restdocs-asciidoctor")
|
||||
asciidoctorExtensions("io.spring.asciidoctor:spring-asciidoctor-extensions-section-ids")
|
||||
|
||||
api(project(":spring-boot-project:spring-boot-actuator"))
|
||||
api(project(":spring-boot-project:spring-boot"))
|
||||
api(project(":spring-boot-project:spring-boot-autoconfigure"))
|
||||
@ -195,38 +192,6 @@ dependencies {
|
||||
}
|
||||
}
|
||||
|
||||
task dependencyVersions(type: org.springframework.boot.build.constraints.ExtractVersionConstraints) {
|
||||
enforcedPlatform(":spring-boot-project:spring-boot-dependencies")
|
||||
}
|
||||
|
||||
asciidoctor {
|
||||
sources {
|
||||
include "index.adoc"
|
||||
}
|
||||
}
|
||||
|
||||
task asciidoctorPdf(type: org.asciidoctor.gradle.jvm.AsciidoctorTask) {
|
||||
sources {
|
||||
include "index.adoc"
|
||||
}
|
||||
}
|
||||
|
||||
task zip(type: Zip) {
|
||||
dependsOn asciidoctor, asciidoctorPdf
|
||||
duplicatesStrategy "fail"
|
||||
from(asciidoctorPdf.outputDir) {
|
||||
into "pdf"
|
||||
rename { "spring-boot-actuator-web-api.pdf" }
|
||||
}
|
||||
from(asciidoctor.outputDir) {
|
||||
into "htmlsingle"
|
||||
}
|
||||
}
|
||||
|
||||
artifacts {
|
||||
documentation zip
|
||||
}
|
||||
|
||||
tasks.named("test") {
|
||||
jvmArgs += "--add-opens=java.base/java.net=ALL-UNNAMED"
|
||||
filter {
|
||||
@ -235,28 +200,46 @@ tasks.named("test") {
|
||||
}
|
||||
|
||||
def documentationTest = tasks.register("documentationTest", Test) {
|
||||
jvmArgs += "--add-opens=java.base/java.net=ALL-UNNAMED"
|
||||
filter {
|
||||
includeTestsMatching("org.springframework.boot.actuate.autoconfigure.endpoint.web.documentation.*")
|
||||
}
|
||||
jvmArgs += "--add-opens=java.base/java.net=ALL-UNNAMED"
|
||||
outputs.dir("${buildDir}/generated-snippets")
|
||||
predictiveSelection {
|
||||
enabled = false
|
||||
}
|
||||
}
|
||||
|
||||
tasks.withType(org.asciidoctor.gradle.jvm.AbstractAsciidoctorTask) {
|
||||
dependsOn dependencyVersions
|
||||
doFirst {
|
||||
def versionConstraints = dependencyVersions.versionConstraints
|
||||
def toAntoraVersion = version -> {
|
||||
String formatted = version.split("\\.").take(2).join('.')
|
||||
return version.endsWith("-SNAPSHOT") ? formatted + "-SNAPSHOT" : formatted
|
||||
}
|
||||
def integrationVersion = versionConstraints["org.springframework.integration:spring-integration-core"]
|
||||
String integrationDocs = String.format("https://docs.spring.io/spring-integration/reference/%s", toAntoraVersion(integrationVersion))
|
||||
attributes "spring-integration-docs": integrationDocs
|
||||
def antoraActuatorRestApiLocalAggregateContent = tasks.register("antoraActuatorRestApiLocalAggregateContent", Zip) {
|
||||
destinationDirectory = layout.buildDirectory.dir('generated/docs/antora-content')
|
||||
archiveClassifier = "actuator-rest-api-local-aggregate-content"
|
||||
from(tasks.getByName("generateAntoraYml")) {
|
||||
into "modules"
|
||||
}
|
||||
dependsOn documentationTest
|
||||
inputs.dir("${buildDir}/generated-snippets").withPathSensitivity(PathSensitivity.RELATIVE).withPropertyName("generatedSnippets")
|
||||
}
|
||||
|
||||
def antoraActuatorRestApiAggregateContent = tasks.register("antoraActuatorRestApiAggregateContent", Zip) {
|
||||
dependsOn documentationTest
|
||||
inputs.dir("${buildDir}/generated-snippets")
|
||||
.withPathSensitivity(PathSensitivity.RELATIVE)
|
||||
.withPropertyName("generatedSnippets")
|
||||
destinationDirectory = layout.buildDirectory.dir('generated/docs/antora-content')
|
||||
archiveClassifier = "actuator-rest-api-aggregate-content"
|
||||
from("${buildDir}/generated-snippets") {
|
||||
into "modules/api/partials/rest/actuator"
|
||||
}
|
||||
}
|
||||
|
||||
tasks.named("generateAntoraPlaybook") {
|
||||
alwaysInclude = [name: "actuator-rest-api", classifier: "local-aggregate-content"]
|
||||
dependsOn antoraActuatorRestApiLocalAggregateContent
|
||||
}
|
||||
|
||||
tasks.named("antora") {
|
||||
inputs.files(antoraActuatorRestApiAggregateContent)
|
||||
}
|
||||
|
||||
artifacts {
|
||||
antoraContent antoraActuatorRestApiAggregateContent
|
||||
}
|
||||
|
||||
|
@ -0,0 +1,6 @@
|
||||
name: spring-boot
|
||||
ext:
|
||||
zip_contents_collector:
|
||||
include:
|
||||
- name: actuator-rest-api
|
||||
classifier: aggregate-content
|
@ -0,0 +1 @@
|
||||
include::api:partial$nav-actuator-rest-api.adoc[]
|
@ -1,36 +1,40 @@
|
||||
[[audit-events]]
|
||||
= Audit Events (`auditevents`)
|
||||
|
||||
The `auditevents` endpoint provides information about the application's audit events.
|
||||
|
||||
|
||||
|
||||
[[audit-events.retrieving]]
|
||||
== Retrieving Audit Events
|
||||
|
||||
To retrieve the audit events, make a `GET` request to `/actuator/auditevents`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/auditevents/filtered/curl-request.adoc[]
|
||||
include::partial$rest/actuator/auditevents/filtered/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves `logout` events for the principal, `alice`, that occurred after 09:37 on 7 November 2017 in the UTC timezone.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/auditevents/filtered/http-response.adoc[]
|
||||
include::partial$rest/actuator/auditevents/filtered/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[audit-events.retrieving.query-parameters]]
|
||||
=== Query Parameters
|
||||
|
||||
The endpoint uses query parameters to limit the events that it returns.
|
||||
The following table shows the supported query parameters:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}/auditevents/filtered/query-parameters.adoc[]
|
||||
include::partial$rest/actuator/auditevents/filtered/query-parameters.adoc[]
|
||||
|
||||
|
||||
|
||||
[[audit-events.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of all of the audit events that matched the query.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/auditevents/all/response-fields.adoc[]
|
||||
include::partial$rest/actuator/auditevents/all/response-fields.adoc[]
|
@ -1,25 +1,28 @@
|
||||
[[beans]]
|
||||
= Beans (`beans`)
|
||||
|
||||
The `beans` endpoint provides information about the application's beans.
|
||||
|
||||
|
||||
|
||||
[[beans.retrieving]]
|
||||
== Retrieving the Beans
|
||||
|
||||
To retrieve the beans, make a `GET` request to `/actuator/beans`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/beans/curl-request.adoc[]
|
||||
include::partial$rest/actuator/beans/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/beans/http-response.adoc[]
|
||||
include::partial$rest/actuator/beans/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[beans.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's beans.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/beans/response-fields.adoc[]
|
||||
include::partial$rest/actuator/beans/response-fields.adoc[]
|
@ -1,78 +1,86 @@
|
||||
[[caches]]
|
||||
= Caches (`caches`)
|
||||
|
||||
The `caches` endpoint provides access to the application's caches.
|
||||
|
||||
|
||||
|
||||
[[caches.all]]
|
||||
== Retrieving All Caches
|
||||
|
||||
To retrieve the application's caches, make a `GET` request to `/actuator/caches`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/caches/all/curl-request.adoc[]
|
||||
include::partial$rest/actuator/caches/all/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/caches/all/http-response.adoc[]
|
||||
include::partial$rest/actuator/caches/all/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[caches.all.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's caches.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/caches/all/response-fields.adoc[]
|
||||
include::partial$rest/actuator/caches/all/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[caches.named]]
|
||||
== Retrieving Caches by Name
|
||||
|
||||
To retrieve a cache by name, make a `GET` request to `/actuator/caches/\{name}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/caches/named/curl-request.adoc[]
|
||||
include::partial$rest/actuator/caches/named/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves information about the cache named `cities`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/caches/named/http-response.adoc[]
|
||||
include::partial$rest/actuator/caches/named/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[caches.named.query-parameters]]
|
||||
=== Query Parameters
|
||||
|
||||
If the requested name is specific enough to identify a single cache, no extra parameter is required.
|
||||
Otherwise, the `cacheManager` must be specified.
|
||||
The following table shows the supported query parameters:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}/caches/named/query-parameters.adoc[]
|
||||
include::partial$rest/actuator/caches/named/query-parameters.adoc[]
|
||||
|
||||
|
||||
|
||||
[[caches.named.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the requested cache.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/caches/named/response-fields.adoc[]
|
||||
include::partial$rest/actuator/caches/named/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[caches.evict-all]]
|
||||
== Evict All Caches
|
||||
|
||||
To clear all available caches, make a `DELETE` request to `/actuator/caches` as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/caches/evict-all/curl-request.adoc[]
|
||||
include::partial$rest/actuator/caches/evict-all/curl-request.adoc[]
|
||||
|
||||
|
||||
|
||||
[[caches.evict-named]]
|
||||
== Evict a Cache by Name
|
||||
|
||||
To evict a particular cache, make a `DELETE` request to `/actuator/caches/\{name}` as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/caches/evict-named/curl-request.adoc[]
|
||||
include::partial$rest/actuator/caches/evict-named/curl-request.adoc[]
|
||||
|
||||
NOTE: As there are two caches named `countries`, the `cacheManager` has to be provided to specify which `Cache` should be cleared.
|
||||
|
||||
@ -80,9 +88,10 @@ NOTE: As there are two caches named `countries`, the `cacheManager` has to be pr
|
||||
|
||||
[[caches.evict-named.request-structure]]
|
||||
=== Request Structure
|
||||
|
||||
If the requested name is specific enough to identify a single cache, no extra parameter is required.
|
||||
Otherwise, the `cacheManager` must be specified.
|
||||
The following table shows the supported query parameters:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}/caches/evict-named/query-parameters.adoc[]
|
||||
include::partial$rest/actuator/caches/evict-named/query-parameters.adoc[]
|
@ -1,25 +1,28 @@
|
||||
[[conditions]]
|
||||
= Conditions Evaluation Report (`conditions`)
|
||||
|
||||
The `conditions` endpoint provides information about the evaluation of conditions on configuration and auto-configuration classes.
|
||||
|
||||
|
||||
|
||||
[[conditions.retrieving]]
|
||||
== Retrieving the Report
|
||||
|
||||
To retrieve the report, make a `GET` request to `/actuator/conditions`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/conditions/curl-request.adoc[]
|
||||
include::partial$rest/actuator/conditions/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/conditions/http-response.adoc[]
|
||||
include::partial$rest/actuator/conditions/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[conditions.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's condition evaluation.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/conditions/response-fields.adoc[]
|
||||
include::partial$rest/actuator/conditions/response-fields.adoc[]
|
@ -1,40 +1,44 @@
|
||||
[[configprops]]
|
||||
= Configuration Properties (`configprops`)
|
||||
|
||||
The `configprops` endpoint provides information about the application's `@ConfigurationProperties` beans.
|
||||
|
||||
|
||||
|
||||
[[configprops.retrieving]]
|
||||
== Retrieving All @ConfigurationProperties Beans
|
||||
|
||||
To retrieve all of the `@ConfigurationProperties` beans, make a `GET` request to `/actuator/configprops`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/configprops/all/curl-request.adoc[]
|
||||
include::partial$rest/actuator/configprops/all/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/configprops/all/http-response.adoc[]
|
||||
include::partial$rest/actuator/configprops/all/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[configprops.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's `@ConfigurationProperties` beans.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/configprops/all/response-fields.adoc[]
|
||||
include::partial$rest/actuator/configprops/all/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[configprops.retrieving-by-prefix]]
|
||||
== Retrieving @ConfigurationProperties Beans By Prefix
|
||||
|
||||
To retrieve the `@ConfigurationProperties` beans mapped under a certain prefix, make a `GET` request to `/actuator/configprops/\{prefix}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/configprops/prefixed/curl-request.adoc[]
|
||||
include::partial$rest/actuator/configprops/prefixed/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/configprops/prefixed/http-response.adoc[]
|
||||
include::partial$rest/actuator/configprops/prefixed/http-response.adoc[]
|
||||
|
||||
NOTE: The `\{prefix}` does not need to be exact, a more general prefix will return all beans mapped under that prefix stem.
|
||||
|
||||
@ -42,8 +46,9 @@ NOTE: The `\{prefix}` does not need to be exact, a more general prefix will retu
|
||||
|
||||
[[configprops.retrieving-by-prefix.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's `@ConfigurationProperties` beans.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/configprops/prefixed/response-fields.adoc[]
|
||||
include::partial$rest/actuator/configprops/prefixed/response-fields.adoc[]
|
@ -1,49 +1,57 @@
|
||||
[[env]]
|
||||
= Environment (`env`)
|
||||
|
||||
The `env` endpoint provides information about the application's `Environment`.
|
||||
|
||||
|
||||
|
||||
[[env.entire]]
|
||||
== Retrieving the Entire Environment
|
||||
|
||||
To retrieve the entire environment, make a `GET` request to `/actuator/env`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/env/all/curl-request.adoc[]
|
||||
include::partial$rest/actuator/env/all/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/env/all/http-response.adoc[]
|
||||
include::partial$rest/actuator/env/all/http-response.adoc[]
|
||||
|
||||
NOTE: Sanitization of sensitive values has been switched off for this example.
|
||||
|
||||
|
||||
|
||||
[[env.entire.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's `Environment`.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/env/all/response-fields.adoc[]
|
||||
include::partial$rest/actuator/env/all/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[env.single-property]]
|
||||
== Retrieving a Single Property
|
||||
|
||||
To retrieve a single property, make a `GET` request to `/actuator/env/{property.name}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/env/single/curl-request.adoc[]
|
||||
include::partial$rest/actuator/env/single/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves information about the property named `com.example.cache.max-size`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/env/single/http-response.adoc[]
|
||||
include::partial$rest/actuator/env/single/http-response.adoc[]
|
||||
|
||||
NOTE: Sanitization of sensitive values has been switched off for this example.
|
||||
|
||||
|
||||
|
||||
[[env.single-property.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the requested property.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/env/single/response-fields.adoc[]
|
||||
include::partial$rest/actuator/env/single/response-fields.adoc[]
|
@ -1,25 +1,28 @@
|
||||
[[flyway]]
|
||||
= Flyway (`flyway`)
|
||||
|
||||
The `flyway` endpoint provides information about database migrations performed by Flyway.
|
||||
|
||||
|
||||
|
||||
[[flyway.retrieving]]
|
||||
== Retrieving the Migrations
|
||||
|
||||
To retrieve the migrations, make a `GET` request to `/actuator/flyway`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/flyway/curl-request.adoc[]
|
||||
include::partial$rest/actuator/flyway/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/flyway/http-response.adoc[]
|
||||
include::partial$rest/actuator/flyway/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[flyway.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's Flyway migrations.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/flyway/response-fields.adoc[]
|
||||
include::partial$rest/actuator/flyway/response-fields.adoc[]
|
@ -1,28 +1,31 @@
|
||||
[[health]]
|
||||
= Health (`health`)
|
||||
|
||||
The `health` endpoint provides detailed information about the health of the application.
|
||||
|
||||
|
||||
|
||||
[[health.retrieving]]
|
||||
== Retrieving the Health of the Application
|
||||
|
||||
To retrieve the health of the application, make a `GET` request to `/actuator/health`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/health/curl-request.adoc[]
|
||||
include::partial$rest/actuator/health/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/health/http-response.adoc[]
|
||||
include::partial$rest/actuator/health/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[health.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the health of the application.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/health/response-fields.adoc[]
|
||||
include::partial$rest/actuator/health/response-fields.adoc[]
|
||||
|
||||
NOTE: The response fields above are for the V3 API.
|
||||
If you need to return V2 JSON you should use an accept header or `application/vnd.spring-boot.actuator.v2+json`
|
||||
@ -31,35 +34,38 @@ If you need to return V2 JSON you should use an accept header or `application/vn
|
||||
|
||||
[[health.retrieving-component]]
|
||||
== Retrieving the Health of a Component
|
||||
|
||||
To retrieve the health of a particular component of the application's health, make a `GET` request to `/actuator/health/\{component}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/health/component/curl-request.adoc[]
|
||||
include::partial$rest/actuator/health/component/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/health/component/http-response.adoc[]
|
||||
include::partial$rest/actuator/health/component/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[health.retrieving-component.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the health of a particular component of the application's health.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/health/component/response-fields.adoc[]
|
||||
include::partial$rest/actuator/health/component/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[health.retrieving-component-nested]]
|
||||
== Retrieving the Health of a Nested Component
|
||||
|
||||
If a particular component contains other nested components (as the `broker` indicator in the example above), the health of such a nested component can be retrieved by issuing a `GET` request to `/actuator/health/\{component}/\{subcomponent}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/health/instance/curl-request.adoc[]
|
||||
include::partial$rest/actuator/health/instance/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/health/instance/http-response.adoc[]
|
||||
include::partial$rest/actuator/health/instance/http-response.adoc[]
|
||||
|
||||
Components of an application's health may be nested arbitrarily deep depending on the application's health indicators and how they have been grouped.
|
||||
The health endpoint supports any number of `/\{component}` identifiers in the URL to allow the health of a component at any depth to be retrieved.
|
||||
@ -68,8 +74,9 @@ The health endpoint supports any number of `/\{component}` identifiers in the UR
|
||||
|
||||
[[health.retrieving-component-nested.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the health of an instance of a particular component of the application.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/health/instance/response-fields.adoc[]
|
||||
include::partial$rest/actuator/health/instance/response-fields.adoc[]
|
@ -1,11 +1,13 @@
|
||||
[[heapdump]]
|
||||
= Heap Dump (`heapdump`)
|
||||
|
||||
The `heapdump` endpoint provides a heap dump from the application's JVM.
|
||||
|
||||
|
||||
|
||||
[[heapdump.retrieving]]
|
||||
== Retrieving the Heap Dump
|
||||
|
||||
To retrieve the heap dump, make a `GET` request to `/actuator/heapdump`.
|
||||
The response is binary data and can be large.
|
||||
Its format depends upon the JVM on which the application is running.
|
||||
@ -14,6 +16,6 @@ and on OpenJ9 it is https://www.eclipse.org/openj9/docs/dump_heapdump/#portable-
|
||||
Typically, you should save the response to disk for subsequent analysis.
|
||||
When using curl, this can be achieved by using the `-O` option, as shown in the following example:
|
||||
|
||||
include::{snippets}/heapdump/curl-request.adoc[]
|
||||
include::partial$rest/actuator/heapdump/curl-request.adoc[]
|
||||
|
||||
The preceding example results in a file named `heapdump` being written to the current working directory.
|
@ -1,25 +1,28 @@
|
||||
[[httpexchanges]]
|
||||
= HTTP Exchanges (`httpexchanges`)
|
||||
|
||||
The `httpexchanges` endpoint provides information about HTTP request-response exchanges.
|
||||
|
||||
|
||||
|
||||
[[httpexchanges.retrieving]]
|
||||
== Retrieving the HTTP Exchanges
|
||||
|
||||
To retrieve the HTTP exchanges, make a `GET` request to `/actuator/httpexchanges`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/httpexchanges/curl-request.adoc[]
|
||||
include::partial$rest/actuator/httpexchanges/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/httpexchanges/http-response.adoc[]
|
||||
include::partial$rest/actuator/httpexchanges/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[httpexchanges.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the traced HTTP request-response exchanges.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/httpexchanges/response-fields.adoc[]
|
||||
include::partial$rest/actuator/httpexchanges/response-fields.adoc[]
|
@ -0,0 +1,41 @@
|
||||
:navtitle: Actuator
|
||||
[[overview]]
|
||||
= Actuator REST API
|
||||
|
||||
This API documentation describes Spring Boot Actuators web endpoints.
|
||||
|
||||
Before you proceed, you should read the following topics:
|
||||
|
||||
* <<overview.endpoint-urls>>
|
||||
* <<overview.timestamps>>
|
||||
|
||||
NOTE: In order to get the correct JSON responses documented below, Jackson must be available.
|
||||
|
||||
|
||||
|
||||
[[overview.endpoint-urls]]
|
||||
== URLs
|
||||
|
||||
By default, all web endpoints are available beneath the path `/actuator` with URLs of
|
||||
the form `/actuator/\{id}`. The `/actuator` base path can be configured by using the
|
||||
`management.endpoints.web.base-path` property, as shown in the following example:
|
||||
|
||||
[source,properties]
|
||||
----
|
||||
management.endpoints.web.base-path=/manage
|
||||
----
|
||||
|
||||
The preceding `application.properties` example changes the form of the endpoint URLs from
|
||||
`/actuator/\{id}` to `/manage/\{id}`. For example, the URL `info` endpoint would become
|
||||
`/manage/info`.
|
||||
|
||||
|
||||
|
||||
[[overview.timestamps]]
|
||||
== Timestamps
|
||||
|
||||
All timestamps that are consumed by the endpoints, either as query parameters or in the
|
||||
request body, must be formatted as an offset date and time as specified in
|
||||
https://en.wikipedia.org/wiki/ISO_8601[ISO 8601].
|
||||
|
||||
|
@ -1,23 +1,26 @@
|
||||
[[info]]
|
||||
= Info (`info`)
|
||||
|
||||
The `info` endpoint provides general information about the application.
|
||||
|
||||
|
||||
|
||||
[[info.retrieving]]
|
||||
== Retrieving the Info
|
||||
|
||||
To retrieve the information about the application, make a `GET` request to `/actuator/info`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/info/curl-request.adoc[]
|
||||
include::partial$rest/actuator/info/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/info/http-response.adoc[]
|
||||
include::partial$rest/actuator/info/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[info.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains general information about the application.
|
||||
Each section of the response is contributed by an `InfoContributor`.
|
||||
Spring Boot provides several contributors that are described below.
|
||||
@ -26,19 +29,21 @@ Spring Boot provides several contributors that are described below.
|
||||
|
||||
[[info.retrieving.response-structure.build]]
|
||||
==== Build Response Structure
|
||||
|
||||
The following table describe the structure of the `build` section of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/info/response-fields-beneath-build.adoc[]
|
||||
include::partial$rest/actuator/info/response-fields-beneath-build.adoc[]
|
||||
|
||||
|
||||
|
||||
[[info.retrieving.response-structure.git]]
|
||||
==== Git Response Structure
|
||||
|
||||
The following table describes the structure of the `git` section of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/info/response-fields-beneath-git.adoc[]
|
||||
include::partial$rest/actuator/info/response-fields-beneath-git.adoc[]
|
||||
|
||||
NOTE: This is the "simple" output.
|
||||
The contributor can also be configured to output all available data.
|
@ -1,34 +1,38 @@
|
||||
[[integrationgraph]]
|
||||
= Spring Integration graph (`integrationgraph`)
|
||||
|
||||
The `integrationgraph` endpoint exposes a graph containing all Spring Integration components.
|
||||
|
||||
|
||||
|
||||
[[integrationgraph.retrieving]]
|
||||
== Retrieving the Spring Integration Graph
|
||||
|
||||
To retrieve the information about the application, make a `GET` request to `/actuator/integrationgraph`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/integrationgraph/graph/curl-request.adoc[]
|
||||
include::partial$rest/actuator/integrationgraph/graph/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/integrationgraph/graph/http-response.adoc[]
|
||||
include::partial$rest/actuator/integrationgraph/graph/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[integrationgraph.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains all Spring Integration components used within the application, as well as the links between them.
|
||||
More information about the structure can be found in the {spring-integration-docs}/index.html#integration-graph[reference documentation].
|
||||
More information about the structure can be found in the {url-spring-integration-docs}/graph.html[reference documentation].
|
||||
|
||||
|
||||
|
||||
[[integrationgraph.rebuilding]]
|
||||
== Rebuilding the Spring Integration Graph
|
||||
|
||||
To rebuild the exposed graph, make a `POST` request to `/actuator/integrationgraph`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/integrationgraph/rebuild/curl-request.adoc[]
|
||||
include::partial$rest/actuator/integrationgraph/rebuild/curl-request.adoc[]
|
||||
|
||||
This will result in a `204 - No Content` response:
|
||||
|
||||
include::{snippets}/integrationgraph/rebuild/http-response.adoc[]
|
||||
include::partial$rest/actuator/integrationgraph/rebuild/http-response.adoc[]
|
@ -1,25 +1,28 @@
|
||||
[[liquibase]]
|
||||
= Liquibase (`liquibase`)
|
||||
|
||||
The `liquibase` endpoint provides information about database change sets applied by Liquibase.
|
||||
|
||||
|
||||
|
||||
[[liquibase.retrieving]]
|
||||
== Retrieving the Changes
|
||||
|
||||
To retrieve the changes, make a `GET` request to `/actuator/liquibase`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/liquibase/curl-request.adoc[]
|
||||
include::partial$rest/actuator/liquibase/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/liquibase/http-response.adoc[]
|
||||
include::partial$rest/actuator/liquibase/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[liquibase.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's Liquibase change sets.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/liquibase/response-fields.adoc[]
|
||||
include::partial$rest/actuator/liquibase/response-fields.adoc[]
|
@ -1,30 +1,33 @@
|
||||
[[logfile]]
|
||||
= Log File (`logfile`)
|
||||
|
||||
The `logfile` endpoint provides access to the contents of the application's log file.
|
||||
|
||||
|
||||
|
||||
[[logfile.retrieving]]
|
||||
== Retrieving the Log File
|
||||
|
||||
To retrieve the log file, make a `GET` request to `/actuator/logfile`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/logfile/entire/curl-request.adoc[]
|
||||
include::partial$rest/actuator/logfile/entire/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/logfile/entire/http-response.adoc[]
|
||||
include::partial$rest/actuator/logfile/entire/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[logfile.retrieving-part]]
|
||||
== Retrieving Part of the Log File
|
||||
|
||||
NOTE: Retrieving part of the log file is not supported when using Jersey.
|
||||
|
||||
To retrieve part of the log file, make a `GET` request to `/actuator/logfile` by using the `Range` header, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/logfile/range/curl-request.adoc[]
|
||||
include::partial$rest/actuator/logfile/range/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the first 1024 bytes of the log file.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/logfile/range/http-response.adoc[]
|
||||
include::partial$rest/actuator/logfile/range/http-response.adoc[]
|
@ -1,83 +1,91 @@
|
||||
[[loggers]]
|
||||
= Loggers (`loggers`)
|
||||
|
||||
The `loggers` endpoint provides access to the application's loggers and the configuration of their levels.
|
||||
|
||||
|
||||
|
||||
[[loggers.all]]
|
||||
== Retrieving All Loggers
|
||||
|
||||
To retrieve the application's loggers, make a `GET` request to `/actuator/loggers`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/loggers/all/curl-request.adoc[]
|
||||
include::partial$rest/actuator/loggers/all/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/loggers/all/http-response.adoc[]
|
||||
include::partial$rest/actuator/loggers/all/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[loggers.all.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's loggers.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/loggers/all/response-fields.adoc[]
|
||||
include::partial$rest/actuator/loggers/all/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[loggers.single]]
|
||||
== Retrieving a Single Logger
|
||||
|
||||
To retrieve a single logger, make a `GET` request to `/actuator/loggers/{logger.name}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/loggers/single/curl-request.adoc[]
|
||||
include::partial$rest/actuator/loggers/single/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves information about the logger named `com.example`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/loggers/single/http-response.adoc[]
|
||||
include::partial$rest/actuator/loggers/single/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[loggers.single.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the requested logger.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/loggers/single/response-fields.adoc[]
|
||||
include::partial$rest/actuator/loggers/single/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[loggers.group]]
|
||||
== Retrieving a Single Group
|
||||
|
||||
To retrieve a single group, make a `GET` request to `/actuator/loggers/{group.name}`,
|
||||
as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/loggers/group/curl-request.adoc[]
|
||||
include::partial$rest/actuator/loggers/group/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves information about the logger group named `test`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/loggers/group/http-response.adoc[]
|
||||
include::partial$rest/actuator/loggers/group/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[loggers.group.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the requested group.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/loggers/group/response-fields.adoc[]
|
||||
include::partial$rest/actuator/loggers/group/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[loggers.setting-level]]
|
||||
== Setting a Log Level
|
||||
|
||||
To set the level of a logger, make a `POST` request to `/actuator/loggers/{logger.name}` with a JSON body that specifies the configured level for the logger, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/loggers/set/curl-request.adoc[]
|
||||
include::partial$rest/actuator/loggers/set/curl-request.adoc[]
|
||||
|
||||
The preceding example sets the `configuredLevel` of the `com.example` logger to `DEBUG`.
|
||||
|
||||
@ -85,19 +93,21 @@ The preceding example sets the `configuredLevel` of the `com.example` logger to
|
||||
|
||||
[[loggers.setting-level.request-structure]]
|
||||
=== Request Structure
|
||||
|
||||
The request specifies the desired level of the logger.
|
||||
The following table describes the structure of the request:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/loggers/set/request-fields.adoc[]
|
||||
include::partial$rest/actuator/loggers/set/request-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[loggers.group-setting-level]]
|
||||
== Setting a Log Level for a Group
|
||||
|
||||
To set the level of a logger, make a `POST` request to `/actuator/loggers/{group.name}` with a JSON body that specifies the configured level for the logger group, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/loggers/setGroup/curl-request.adoc[]
|
||||
include::partial$rest/actuator/loggers/setGroup/curl-request.adoc[]
|
||||
|
||||
The preceding example sets the `configuredLevel` of the `test` logger group to `DEBUG`.
|
||||
|
||||
@ -105,18 +115,20 @@ The preceding example sets the `configuredLevel` of the `test` logger group to `
|
||||
|
||||
[[loggers.group-setting-level.request-structure]]
|
||||
=== Request Structure
|
||||
|
||||
The request specifies the desired level of the logger group.
|
||||
The following table describes the structure of the request:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/loggers/set/request-fields.adoc[]
|
||||
include::partial$rest/actuator/loggers/set/request-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[loggers.clearing-level]]
|
||||
== Clearing a Log Level
|
||||
|
||||
To clear the level of a logger, make a `POST` request to `/actuator/loggers/{logger.name}` with a JSON body containing an empty object, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/loggers/clear/curl-request.adoc[]
|
||||
include::partial$rest/actuator/loggers/clear/curl-request.adoc[]
|
||||
|
||||
The preceding example clears the configured level of the `com.example` logger.
|
@ -1,29 +1,32 @@
|
||||
[[mappings]]
|
||||
= Mappings (`mappings`)
|
||||
|
||||
The `mappings` endpoint provides information about the application's request mappings.
|
||||
|
||||
|
||||
|
||||
[[mappings.retrieving]]
|
||||
== Retrieving the Mappings
|
||||
|
||||
To retrieve the mappings, make a `GET` request to `/actuator/mappings`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/mappings/curl-request.adoc[]
|
||||
include::partial$rest/actuator/mappings/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/mappings/http-response.adoc[]
|
||||
include::partial$rest/actuator/mappings/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[mappings.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's mappings.
|
||||
The items found in the response depend on the type of web application (reactive or Servlet-based).
|
||||
The following table describes the structure of the common elements of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/mappings/response-fields.adoc[]
|
||||
include::partial$rest/actuator/mappings/response-fields.adoc[]
|
||||
|
||||
The entries that may be found in `contexts.*.mappings` are described in the following sections.
|
||||
|
||||
@ -31,38 +34,42 @@ The entries that may be found in `contexts.*.mappings` are described in the foll
|
||||
|
||||
[[mappings.retrieving.response-structure-dispatcher-servlets]]
|
||||
=== Dispatcher Servlets Response Structure
|
||||
|
||||
When using Spring MVC, the response contains details of any `DispatcherServlet` request mappings beneath `contexts.*.mappings.dispatcherServlets`.
|
||||
The following table describes the structure of this section of the response:
|
||||
|
||||
[cols="4,1,2"]
|
||||
include::{snippets}/mappings/response-fields-dispatcher-servlets.adoc[]
|
||||
include::partial$rest/actuator/mappings/response-fields-dispatcher-servlets.adoc[]
|
||||
|
||||
|
||||
|
||||
[[mappings.retrieving.response-structure-servlets]]
|
||||
=== Servlets Response Structure
|
||||
|
||||
When using the Servlet stack, the response contains details of any `Servlet` mappings beneath `contexts.*.mappings.servlets`.
|
||||
The following table describes the structure of this section of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/mappings/response-fields-servlets.adoc[]
|
||||
include::partial$rest/actuator/mappings/response-fields-servlets.adoc[]
|
||||
|
||||
|
||||
|
||||
[[mappings.retrieving.response-structure-servlet-filters]]
|
||||
=== Servlet Filters Response Structure
|
||||
|
||||
When using the Servlet stack, the response contains details of any `Filter` mappings beneath `contexts.*.mappings.servletFilters`.
|
||||
The following table describes the structure of this section of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/mappings/response-fields-servlet-filters.adoc[]
|
||||
include::partial$rest/actuator/mappings/response-fields-servlet-filters.adoc[]
|
||||
|
||||
|
||||
|
||||
[[mappings.retrieving.response-structure-dispatcher-handlers]]
|
||||
=== Dispatcher Handlers Response Structure
|
||||
|
||||
When using Spring WebFlux, the response contains details of any `DispatcherHandler` request mappings beneath `contexts.*.mappings.dispatcherHandlers`.
|
||||
The following table describes the structure of this section of the response:
|
||||
|
||||
[cols="4,1,2"]
|
||||
include::{snippets}/mappings/response-fields-dispatcher-handlers.adoc[]
|
||||
include::partial$rest/actuator/mappings/response-fields-dispatcher-handlers.adoc[]
|
@ -1,70 +1,77 @@
|
||||
[[metrics]]
|
||||
= Metrics (`metrics`)
|
||||
|
||||
The `metrics` endpoint provides access to application metrics.
|
||||
|
||||
|
||||
|
||||
[[metrics.retrieving-names]]
|
||||
== Retrieving Metric Names
|
||||
|
||||
To retrieve the names of the available metrics, make a `GET` request to `/actuator/metrics`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/metrics/names/curl-request.adoc[]
|
||||
include::partial$rest/actuator/metrics/names/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/metrics/names/http-response.adoc[]
|
||||
include::partial$rest/actuator/metrics/names/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[metrics.retrieving-names.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the metric names.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,2"]
|
||||
include::{snippets}/metrics/names/response-fields.adoc[]
|
||||
include::partial$rest/actuator/metrics/names/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[metrics.retrieving-metric]]
|
||||
== Retrieving a Metric
|
||||
|
||||
To retrieve a metric, make a `GET` request to `/actuator/metrics/{metric.name}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/metrics/metric/curl-request.adoc[]
|
||||
include::partial$rest/actuator/metrics/metric/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves information about the metric named `jvm.memory.max`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/metrics/metric/http-response.adoc[]
|
||||
include::partial$rest/actuator/metrics/metric/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[metrics.retrieving-metric.query-parameters]]
|
||||
=== Query Parameters
|
||||
The endpoint uses query parameters to <<metrics.drilling-down,drill down>> into a metric by using its tags.
|
||||
|
||||
The endpoint uses query parameters to xref:rest/actuator/metrics.adoc#metrics.drilling-down[drill down] into a metric by using its tags.
|
||||
The following table shows the single supported query parameter:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}/metrics/metric-with-tags/query-parameters.adoc[]
|
||||
include::partial$rest/actuator/metrics/metric-with-tags/query-parameters.adoc[]
|
||||
|
||||
|
||||
|
||||
[[metrics.retrieving-metric.response-structure]]
|
||||
=== Response structure
|
||||
|
||||
The response contains details of the metric.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
include::{snippets}/metrics/metric/response-fields.adoc[]
|
||||
include::partial$rest/actuator/metrics/metric/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[metrics.drilling-down]]
|
||||
== Drilling Down
|
||||
|
||||
To drill down into a metric, make a `GET` request to `/actuator/metrics/{metric.name}` using the `tag` query parameter, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/metrics/metric-with-tags/curl-request.adoc[]
|
||||
include::partial$rest/actuator/metrics/metric-with-tags/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the `jvm.memory.max` metric, where the `area` tag has a value of `nonheap` and the `id` attribute has a value of `Compressed Class Space`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/metrics/metric-with-tags/http-response.adoc[]
|
||||
include::partial$rest/actuator/metrics/metric-with-tags/http-response.adoc[]
|
@ -1,47 +1,51 @@
|
||||
[[prometheus]]
|
||||
= Prometheus (`prometheus`)
|
||||
|
||||
The `prometheus` endpoint provides Spring Boot application's metrics in the format required for scraping by a Prometheus server.
|
||||
|
||||
|
||||
|
||||
[[prometheus.retrieving]]
|
||||
== Retrieving All Metrics
|
||||
|
||||
To retrieve all metrics, make a `GET` request to `/actuator/prometheus`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/prometheus/all/curl-request.adoc[]
|
||||
include::partial$rest/actuator/prometheus/all/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/prometheus/all/http-response.adoc[]
|
||||
include::partial$rest/actuator/prometheus/all/http-response.adoc[]
|
||||
|
||||
The default response content type is `text/plain;version=0.0.4`.
|
||||
The endpoint can also produce `application/openmetrics-text;version=1.0.0` when called with an appropriate `Accept` header, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/prometheus/openmetrics/curl-request.adoc[]
|
||||
include::partial$rest/actuator/prometheus/openmetrics/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/prometheus/openmetrics/http-response.adoc[]
|
||||
include::partial$rest/actuator/prometheus/openmetrics/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[prometheus.retrieving.query-parameters]]
|
||||
=== Query Parameters
|
||||
|
||||
The endpoint uses query parameters to limit the samples that it returns.
|
||||
The following table shows the supported query parameters:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}/prometheus/names/query-parameters.adoc[]
|
||||
include::partial$rest/actuator/prometheus/names/query-parameters.adoc[]
|
||||
|
||||
|
||||
|
||||
[[prometheus.retrieving-names]]
|
||||
== Retrieving Filtered Metrics
|
||||
|
||||
To retrieve metrics matching specific names, make a `GET` request to `/actuator/prometheus` with the `includedNames` query parameter, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/prometheus/names/curl-request.adoc[]
|
||||
include::partial$rest/actuator/prometheus/names/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/prometheus/names/http-response.adoc[]
|
||||
include::partial$rest/actuator/prometheus/names/http-response.adoc[]
|
||||
|
@ -1,96 +1,105 @@
|
||||
[[quartz]]
|
||||
= Quartz (`quartz`)
|
||||
|
||||
The `quartz` endpoint provides information about jobs and triggers that are managed by the Quartz Scheduler.
|
||||
|
||||
|
||||
|
||||
[[quartz.report]]
|
||||
== Retrieving Registered Groups
|
||||
|
||||
Jobs and triggers are managed in groups.
|
||||
To retrieve the list of registered job and trigger groups, make a `GET` request to `/actuator/quartz`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/quartz/report/curl-request.adoc[]
|
||||
include::partial$rest/actuator/quartz/report/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/report/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/report/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.report.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains the groups names for registered jobs and triggers.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/quartz/report/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/report/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.job-groups]]
|
||||
== Retrieving Registered Job Names
|
||||
|
||||
To retrieve the list of registered job names, make a `GET` request to `/actuator/quartz/jobs`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/quartz/jobs/curl-request.adoc[]
|
||||
include::partial$rest/actuator/quartz/jobs/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/jobs/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/jobs/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.job-groups.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains the registered job names for each group.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/quartz/jobs/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/jobs/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.trigger-groups]]
|
||||
== Retrieving Registered Trigger Names
|
||||
|
||||
To retrieve the list of registered trigger names, make a `GET` request to `/actuator/quartz/triggers`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/quartz/triggers/curl-request.adoc[]
|
||||
include::partial$rest/actuator/quartz/triggers/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/triggers/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/triggers/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.trigger-groups.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains the registered trigger names for each group.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/quartz/triggers/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/triggers/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.job-group]]
|
||||
== Retrieving Overview of a Job Group
|
||||
|
||||
To retrieve an overview of the jobs in a particular group, make a `GET` request to `/actuator/quartz/jobs/\{groupName}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/quartz/job-group/curl-request.adoc[]
|
||||
include::partial$rest/actuator/quartz/job-group/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the summary for jobs in the `samples` group.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/job-group/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/job-group/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.job-group.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains an overview of jobs in a particular group.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/quartz/job-group/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/job-group/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
@ -99,36 +108,38 @@ include::{snippets}/quartz/job-group/response-fields.adoc[]
|
||||
|
||||
To retrieve an overview of the triggers in a particular group, make a `GET` request to `/actuator/quartz/triggers/\{groupName}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/quartz/trigger-group/curl-request.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-group/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the summary for triggers in the `tests` group.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/trigger-group/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-group/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.trigger-group.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains an overview of triggers in a particular group.
|
||||
Trigger implementation specific details are available.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/quartz/trigger-group/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-group/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.job]]
|
||||
== Retrieving Details of a Job
|
||||
|
||||
To retrieve the details about a particular job, make a `GET` request to `/actuator/quartz/jobs/\{groupName}/\{jobName}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/quartz/job-details/curl-request.adoc[]
|
||||
include::partial$rest/actuator/quartz/job-details/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the details of the job identified by the `samples` group and `jobOne` name.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/job-details/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/job-details/http-response.adoc[]
|
||||
|
||||
If a key in the data map is identified as sensitive, its value is sanitized.
|
||||
|
||||
@ -136,20 +147,22 @@ If a key in the data map is identified as sensitive, its value is sanitized.
|
||||
|
||||
[[quartz.job.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains the full details of a job including a summary of the triggers associated with it, if any.
|
||||
The triggers are sorted by next fire time and priority.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/quartz/job-details/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/job-details/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.trigger]]
|
||||
== Retrieving Details of a Trigger
|
||||
|
||||
To retrieve the details about a particular trigger, make a `GET` request to `/actuator/quartz/triggers/\{groupName}/\{triggerName}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/quartz/trigger-details-cron/curl-request.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-cron/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the details of trigger identified by the `samples` group and `example` name.
|
||||
|
||||
@ -157,6 +170,7 @@ The preceding example retrieves the details of trigger identified by the `sample
|
||||
|
||||
[[quartz.trigger.common-response-structure]]
|
||||
=== Common Response Structure
|
||||
|
||||
The response has a common structure and an additional object that is specific to the trigger's type.
|
||||
There are five supported types:
|
||||
|
||||
@ -169,89 +183,94 @@ There are five supported types:
|
||||
The following table describes the structure of the common elements of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/quartz/trigger-details-common/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-common/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.trigger.cron-response-structure]]
|
||||
=== Cron Trigger Response Structure
|
||||
|
||||
A cron trigger defines the cron expression that is used to determine when it has to fire.
|
||||
The resulting response for such a trigger implementation is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/trigger-details-cron/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-cron/http-response.adoc[]
|
||||
|
||||
|
||||
Much of the response is common to all trigger types.
|
||||
The structure of the common elements of the response was <<quartz.trigger.common-response-structure,described previously>>.
|
||||
The structure of the common elements of the response was xref:rest/actuator/quartz.adoc#quartz.trigger.common-response-structure[described previously].
|
||||
The following table describes the structure of the parts of the response that are specific to cron triggers:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/quartz/trigger-details-cron/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-cron/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.trigger.simple-response-structure]]
|
||||
=== Simple Trigger Response Structure
|
||||
|
||||
A simple trigger is used to fire a Job at a given moment in time, and optionally repeated at a specified interval.
|
||||
The resulting response for such a trigger implementation is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/trigger-details-simple/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-simple/http-response.adoc[]
|
||||
|
||||
|
||||
Much of the response is common to all trigger types.
|
||||
The structure of the common elements of the response was <<quartz.trigger.common-response-structure,described previously>>.
|
||||
The structure of the common elements of the response was xref:rest/actuator/quartz.adoc#quartz.trigger.common-response-structure[described previously].
|
||||
The following table describes the structure of the parts of the response that are specific to simple triggers:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/quartz/trigger-details-simple/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-simple/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.trigger.daily-time-interval-response-structure]]
|
||||
=== Daily Time Interval Trigger Response Structure
|
||||
|
||||
A daily time interval trigger is used to fire a Job based upon daily repeating time intervals.
|
||||
The resulting response for such a trigger implementation is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/trigger-details-daily-time-interval/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-daily-time-interval/http-response.adoc[]
|
||||
|
||||
|
||||
Much of the response is common to all trigger types.
|
||||
The structure of the common elements of the response was <<quartz.trigger.common-response-structure,described previously>>.
|
||||
The structure of the common elements of the response was xref:rest/actuator/quartz.adoc#quartz.trigger.common-response-structure[described previously].
|
||||
The following table describes the structure of the parts of the response that are specific to daily time interval triggers:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/quartz/trigger-details-daily-time-interval/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-daily-time-interval/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.trigger.calendar-interval-response-structure]]
|
||||
=== Calendar Interval Trigger Response Structure
|
||||
|
||||
A calendar interval trigger is used to fire a Job based upon repeating calendar time intervals.
|
||||
The resulting response for such a trigger implementation is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/trigger-details-calendar-interval/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-calendar-interval/http-response.adoc[]
|
||||
|
||||
|
||||
Much of the response is common to all trigger types.
|
||||
The structure of the common elements of the response was <<quartz.trigger.common-response-structure,described previously>>.
|
||||
The structure of the common elements of the response was xref:rest/actuator/quartz.adoc#quartz.trigger.common-response-structure[described previously].
|
||||
The following table describes the structure of the parts of the response that are specific to calendar interval triggers:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/quartz/trigger-details-calendar-interval/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-calendar-interval/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[quartz.trigger.custom-response-structure]]
|
||||
=== Custom Trigger Response Structure
|
||||
|
||||
A custom trigger is any other implementation.
|
||||
The resulting response for such a trigger implementation is similar to the following:
|
||||
|
||||
include::{snippets}/quartz/trigger-details-custom/http-response.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-custom/http-response.adoc[]
|
||||
|
||||
|
||||
Much of the response is common to all trigger types.
|
||||
The structure of the common elements of the response was <<quartz.trigger.common-response-structure,described previously>>.
|
||||
The structure of the common elements of the response was xref:rest/actuator/quartz.adoc#quartz.trigger.common-response-structure[described previously].
|
||||
The following table describes the structure of the parts of the response that are specific to custom triggers:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/quartz/trigger-details-custom/response-fields.adoc[]
|
||||
include::partial$rest/actuator/quartz/trigger-details-custom/response-fields.adoc[]
|
@ -1,25 +1,28 @@
|
||||
[[scheduled-tasks]]
|
||||
= Scheduled Tasks (`scheduledtasks`)
|
||||
|
||||
The `scheduledtasks` endpoint provides information about the application's scheduled tasks.
|
||||
|
||||
|
||||
|
||||
[[scheduled-tasks.retrieving]]
|
||||
== Retrieving the Scheduled Tasks
|
||||
|
||||
To retrieve the scheduled tasks, make a `GET` request to `/actuator/scheduledtasks`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/scheduled-tasks/curl-request.adoc[]
|
||||
include::partial$rest/actuator/scheduled-tasks/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/scheduled-tasks/http-response.adoc[]
|
||||
include::partial$rest/actuator/scheduled-tasks/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[scheduled-tasks.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application's scheduled tasks.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/scheduled-tasks/response-fields.adoc[]
|
||||
include::partial$rest/actuator/scheduled-tasks/response-fields.adoc[]
|
@ -1,69 +1,76 @@
|
||||
[[sessions]]
|
||||
= Sessions (`sessions`)
|
||||
|
||||
The `sessions` endpoint provides information about the application's HTTP sessions that are managed by Spring Session.
|
||||
|
||||
|
||||
|
||||
[[sessions.retrieving]]
|
||||
== Retrieving Sessions
|
||||
|
||||
To retrieve the sessions, make a `GET` request to `/actuator/sessions`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/sessions/username/curl-request.adoc[]
|
||||
include::partial$rest/actuator/sessions/username/curl-request.adoc[]
|
||||
|
||||
The preceding examples retrieves all of the sessions for the user whose username is `alice`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/sessions/username/http-response.adoc[]
|
||||
include::partial$rest/actuator/sessions/username/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[sessions.retrieving.query-parameters]]
|
||||
=== Query Parameters
|
||||
|
||||
The endpoint uses query parameters to limit the sessions that it returns.
|
||||
The following table shows the single required query parameter:
|
||||
|
||||
[cols="2,4"]
|
||||
include::{snippets}/sessions/username/query-parameters.adoc[]
|
||||
include::partial$rest/actuator/sessions/username/query-parameters.adoc[]
|
||||
|
||||
|
||||
|
||||
[[sessions.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the matching sessions.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/sessions/username/response-fields.adoc[]
|
||||
include::partial$rest/actuator/sessions/username/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[sessions.retrieving-id]]
|
||||
== Retrieving a Single Session
|
||||
|
||||
To retrieve a single session, make a `GET` request to `/actuator/sessions/\{id}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/sessions/id/curl-request.adoc[]
|
||||
include::partial$rest/actuator/sessions/id/curl-request.adoc[]
|
||||
|
||||
The preceding example retrieves the session with the `id` of `4db5efcc-99cb-4d05-a52c-b49acfbb7ea9`.
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/sessions/id/http-response.adoc[]
|
||||
include::partial$rest/actuator/sessions/id/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[sessions.retrieving-id.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the requested session.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/sessions/id/response-fields.adoc[]
|
||||
include::partial$rest/actuator/sessions/id/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[sessions.deleting]]
|
||||
== Deleting a Session
|
||||
|
||||
To delete a session, make a `DELETE` request to `/actuator/sessions/\{id}`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/sessions/delete/curl-request.adoc[]
|
||||
include::partial$rest/actuator/sessions/delete/curl-request.adoc[]
|
||||
|
||||
The preceding example deletes the session with the `id` of `4db5efcc-99cb-4d05-a52c-b49acfbb7ea9`.
|
@ -1,25 +1,28 @@
|
||||
[[shutdown]]
|
||||
= Shutdown (`shutdown`)
|
||||
|
||||
The `shutdown` endpoint is used to shut down the application.
|
||||
|
||||
|
||||
|
||||
[[shutdown.shutting-down]]
|
||||
== Shutting Down the Application
|
||||
|
||||
To shut down the application, make a `POST` request to `/actuator/shutdown`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/shutdown/curl-request.adoc[]
|
||||
include::partial$rest/actuator/shutdown/curl-request.adoc[]
|
||||
|
||||
A response similar to the following is produced:
|
||||
|
||||
include::{snippets}/shutdown/http-response.adoc[]
|
||||
include::partial$rest/actuator/shutdown/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[shutdown.shutting-down.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the result of the shutdown request.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,3"]
|
||||
include::{snippets}/shutdown/response-fields.adoc[]
|
||||
include::partial$rest/actuator/shutdown/response-fields.adoc[]
|
@ -1,43 +1,48 @@
|
||||
[[startup]]
|
||||
= Application Startup (`startup`)
|
||||
|
||||
The `startup` endpoint provides information about the application's startup sequence.
|
||||
|
||||
|
||||
|
||||
[[startup.retrieving]]
|
||||
== Retrieving the Application Startup Steps
|
||||
|
||||
The application startup steps can either be retrieved as a snapshot (`GET`) or drained from the buffer (`POST`).
|
||||
|
||||
|
||||
|
||||
[[startup.retrieving.snapshot]]
|
||||
=== Retrieving a snapshot of the Application Startup Steps
|
||||
|
||||
To retrieve the steps recorded so far during the application startup phase, make a `GET` request to `/actuator/startup`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/startup-snapshot/curl-request.adoc[]
|
||||
include::partial$rest/actuator/startup-snapshot/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/startup-snapshot/http-response.adoc[]
|
||||
include::partial$rest/actuator/startup-snapshot/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[startup.retrieving.drain]]
|
||||
=== Draining the Application Startup Steps
|
||||
|
||||
To drain and return the steps recorded so far during the application startup phase, make a `POST` request to `/actuator/startup`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/startup/curl-request.adoc[]
|
||||
include::partial$rest/actuator/startup/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/startup/http-response.adoc[]
|
||||
include::partial$rest/actuator/startup/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[startup.retrieving.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the application startup steps.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="2,1,3"]
|
||||
include::{snippets}/startup/response-fields.adoc[]
|
||||
include::partial$rest/actuator/startup/response-fields.adoc[]
|
@ -1,38 +1,42 @@
|
||||
[[threaddump]]
|
||||
= Thread Dump (`threaddump`)
|
||||
|
||||
The `threaddump` endpoint provides a thread dump from the application's JVM.
|
||||
|
||||
|
||||
|
||||
[[threaddump.retrieving-json]]
|
||||
== Retrieving the Thread Dump as JSON
|
||||
|
||||
To retrieve the thread dump as JSON, make a `GET` request to `/actuator/threaddump` with an appropriate `Accept` header, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/threaddump/json/curl-request.adoc[]
|
||||
include::partial$rest/actuator/threaddump/json/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/threaddump/json/http-response.adoc[]
|
||||
include::partial$rest/actuator/threaddump/json/http-response.adoc[]
|
||||
|
||||
|
||||
|
||||
[[threaddump.retrieving-json.response-structure]]
|
||||
=== Response Structure
|
||||
|
||||
The response contains details of the JVM's threads.
|
||||
The following table describes the structure of the response:
|
||||
|
||||
[cols="3,1,2"]
|
||||
include::{snippets}/threaddump/json/response-fields.adoc[]
|
||||
include::partial$rest/actuator/threaddump/json/response-fields.adoc[]
|
||||
|
||||
|
||||
|
||||
[[threaddump.retrieving-text]]
|
||||
== Retrieving the Thread Dump as Text
|
||||
|
||||
To retrieve the thread dump as text, make a `GET` request to `/actuator/threaddump` that
|
||||
accepts `text/plain`, as shown in the following curl-based example:
|
||||
|
||||
include::{snippets}/threaddump/text/curl-request.adoc[]
|
||||
include::partial$rest/actuator/threaddump/text/curl-request.adoc[]
|
||||
|
||||
The resulting response is similar to the following:
|
||||
|
||||
include::{snippets}/threaddump/text/http-response.adoc[]
|
||||
include::partial$rest/actuator/threaddump/text/http-response.adoc[]
|
@ -0,0 +1,25 @@
|
||||
* xref:api:rest/actuator/index.adoc[]
|
||||
** xref:api:rest/actuator/auditevents.adoc[]
|
||||
** xref:api:rest/actuator/beans.adoc[]
|
||||
** xref:api:rest/actuator/caches.adoc[]
|
||||
** xref:api:rest/actuator/conditions.adoc[]
|
||||
** xref:api:rest/actuator/configprops.adoc[]
|
||||
** xref:api:rest/actuator/env.adoc[]
|
||||
** xref:api:rest/actuator/flyway.adoc[]
|
||||
** xref:api:rest/actuator/health.adoc[]
|
||||
** xref:api:rest/actuator/heapdump.adoc[]
|
||||
** xref:api:rest/actuator/httpexchanges.adoc[]
|
||||
** xref:api:rest/actuator/info.adoc[]
|
||||
** xref:api:rest/actuator/integrationgraph.adoc[]
|
||||
** xref:api:rest/actuator/liquibase.adoc[]
|
||||
** xref:api:rest/actuator/logfile.adoc[]
|
||||
** xref:api:rest/actuator/loggers.adoc[]
|
||||
** xref:api:rest/actuator/mappings.adoc[]
|
||||
** xref:api:rest/actuator/metrics.adoc[]
|
||||
** xref:api:rest/actuator/prometheus.adoc[]
|
||||
** xref:api:rest/actuator/quartz.adoc[]
|
||||
** xref:api:rest/actuator/scheduledtasks.adoc[]
|
||||
** xref:api:rest/actuator/sessions.adoc[]
|
||||
** xref:api:rest/actuator/shutdown.adoc[]
|
||||
** xref:api:rest/actuator/startup.adoc[]
|
||||
** xref:api:rest/actuator/threaddump.adoc[]
|
@ -1,103 +0,0 @@
|
||||
[[spring-boot-actuator-web-api-documentation]]
|
||||
= Spring Boot Actuator Web API Documentation
|
||||
Andy Wilkinson; Stephane Nicoll
|
||||
v{gradle-project-version}
|
||||
:!version-label:
|
||||
:doctype: book
|
||||
:toc: left
|
||||
:toclevels: 4
|
||||
:numbered:
|
||||
:icons: font
|
||||
:hide-uri-scheme:
|
||||
:docinfo: shared,private
|
||||
:attribute-missing: warn
|
||||
|
||||
|
||||
|
||||
This API documentation describes Spring Boot Actuators web endpoints.
|
||||
|
||||
|
||||
|
||||
[[overview]]
|
||||
== Overview
|
||||
Before you proceed, you should read the following topics:
|
||||
|
||||
* <<overview.endpoint-urls>>
|
||||
* <<overview.timestamps>>
|
||||
|
||||
NOTE: In order to get the correct JSON responses documented below, Jackson must be available.
|
||||
|
||||
|
||||
|
||||
[[overview.endpoint-urls]]
|
||||
=== URLs
|
||||
By default, all web endpoints are available beneath the path `/actuator` with URLs of
|
||||
the form `/actuator/\{id}`. The `/actuator` base path can be configured by using the
|
||||
`management.endpoints.web.base-path` property, as shown in the following example:
|
||||
|
||||
[source,properties,indent=0]
|
||||
----
|
||||
management.endpoints.web.base-path=/manage
|
||||
----
|
||||
|
||||
The preceding `application.properties` example changes the form of the endpoint URLs from
|
||||
`/actuator/\{id}` to `/manage/\{id}`. For example, the URL `info` endpoint would become
|
||||
`/manage/info`.
|
||||
|
||||
|
||||
|
||||
[[overview.timestamps]]
|
||||
=== Timestamps
|
||||
All timestamps that are consumed by the endpoints, either as query parameters or in the
|
||||
request body, must be formatted as an offset date and time as specified in
|
||||
https://en.wikipedia.org/wiki/ISO_8601[ISO 8601].
|
||||
|
||||
|
||||
|
||||
include::endpoints/auditevents.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/beans.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/caches.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/conditions.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/configprops.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/env.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/flyway.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/health.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/heapdump.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/httpexchanges.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/info.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/integrationgraph.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/liquibase.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/logfile.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/loggers.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/mappings.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/metrics.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/prometheus.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/quartz.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/scheduledtasks.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/sessions.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/shutdown.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/startup.adoc[leveloffset=+1]
|
||||
|
||||
include::endpoints/threaddump.adoc[leveloffset=+1]
|
Loading…
Reference in New Issue
Block a user