@@ -4,7 +4,7 @@ The `configprops` endpoint provides information about the application's `@Config
[[configprops-retrieving]]
[[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:
== 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:
...
...
@@ -40,7 +40,7 @@ NOTE: The `\{prefix}` does not need to be exact, a more general prefix will retu
The response contains details of the health of the application.
The following table describes the structure of the response:
...
...
@@ -29,8 +29,8 @@ 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
[[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:
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:
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:
...
...
@@ -83,7 +83,7 @@ The preceding example sets the `configuredLevel` of the `com.example` logger to
[[loggers-setting-level-request-structure]]
[[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:
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:
...
...
@@ -103,7 +103,7 @@ The preceding example sets the `configuredLevel` of the `test` logger group to `
[[loggers-group-setting-level-request-structure]]
[[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:
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:
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:
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:
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:
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:
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:
...
...
@@ -134,7 +134,7 @@ If a key in the data map is identified as sensitive, its value is sanitized.
[[quartz-job-response-structure]]
[[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.
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:
...
...
@@ -155,7 +155,7 @@ The preceding example retrieves the details of trigger identified by the `sample
[[quartz-trigger-common-response-structure]]
[[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.
@@ -4,14 +4,14 @@ The `startup` endpoint provides information about the application's startup sequ
[[startup-retrieving]]
== Retrieving the Application Startup steps
[[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
[[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:
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:
@@ -4,7 +4,7 @@ The `threaddump` endpoint provides a thread dump from the application's JVM.
[[threaddump-retrieving-json]]
[[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:
