Update actuator docs to prefer "You can..."

Edit the actuator docs so that more "You can..." phrasing is used.

For example
	"Auditing can be enabled by providing"
becomes
	"You can enable auditing by providing"

See gh-27759

spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/auditing.adoc

@@ -3,7 +3,7 @@
 Once Spring Security is in play, Spring Boot Actuator has a flexible audit framework that publishes events (by default, "`authentication success`", "`failure`" and "`access denied`" exceptions).
 This feature can be very useful for reporting and for implementing a lock-out policy based on authentication failures.
 
-Auditing can be enabled by providing a bean of type `AuditEventRepository` in your application's configuration.
+You can enable auditing by providing a bean of type `AuditEventRepository` in your application's configuration.
 For convenience, Spring Boot offers an `InMemoryAuditEventRepository`.
 `InMemoryAuditEventRepository` has limited capabilities, and we recommend using it only for development environments.
 For production environments, consider creating your own alternative `AuditEventRepository` implementation.

spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/cloud-foundry.adoc

@@ -4,10 +4,10 @@ Spring Boot's actuator module includes additional support that is activated when
 The `/cloudfoundryapplication` path provides an alternative secured route to all `@Endpoint` beans.
 
 The extended support lets Cloud Foundry management UIs (such as the web application that you can use to view deployed applications) be augmented with Spring Boot actuator information.
-For example, an application status page may include full health information instead of the typical "`running`" or "`stopped`" status.
+For example, an application status page can include full health information instead of the typical "`running`" or "`stopped`" status.
 
 NOTE: The `/cloudfoundryapplication` path is not directly accessible to regular users.
-In order to use the endpoint, a valid UAA token must be passed with the request.
+To use the endpoint, you must pass a valid UAA token with the request.
 
 
 
@@ -45,7 +45,7 @@ For example, if `server.servlet.context-path=/app`, Cloud Foundry endpoints will
 
 If you expect the Cloud Foundry endpoints to always be available at `/cloudfoundryapplication/*`, regardless of the server's context-path, you will need to explicitly configure that in your application.
 The configuration will differ depending on the web server in use.
-For Tomcat, the following configuration can be added:
+For Tomcat, you can add the following configuration:
 
 [source,java,indent=0,subs="verbatim"]
 ----

spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/endpoints.adoc

@@ -4,7 +4,7 @@ Actuator endpoints let you monitor and interact with your application.
 Spring Boot includes a number of built-in endpoints and lets you add your own.
 For example, the `health` endpoint provides basic application health information.
 
-Each individual endpoint can be <<actuator#actuator.endpoints.enabling, enabled or disabled>> and <<actuator#actuator.endpoints.exposing, exposed (made remotely accessible) over HTTP or JMX>>.
+You can <<actuator#actuator.endpoints.enabling, enable or disable>> each individual endpoint and <<actuator#actuator.endpoints.exposing, expose them (make them remotely accessible) over HTTP or JMX>>.
 An endpoint is considered to be available when it is both enabled and exposed.
 The built-in endpoints will only be auto-configured when they are available.
 Most applications choose exposure via HTTP, where the ID of the endpoint along with a prefix of `/actuator` is mapped to a URL.
@@ -150,7 +150,7 @@ If you want to change only the technologies over which an endpoint is exposed, u
 
 [[actuator.endpoints.exposing]]
 === Exposing Endpoints
-Since Endpoints may contain sensitive information, careful consideration should be given about when to expose them.
+Since Endpoints may contain sensitive information, you should carefully consider when to expose them.
 The following table shows the default exposure for the built-in endpoints:
 
 [cols="1,1,1"]
@@ -280,7 +280,7 @@ To change which endpoints are exposed, use the following technology-specific `in
 The `include` property lists the IDs of the endpoints that are exposed.
 The `exclude` property lists the IDs of the endpoints that should not be exposed.
 The `exclude` property takes precedence over the `include` property.
-Both `include` and `exclude` properties can be configured with a list of endpoint IDs.
+You can configure both the `include` and the `exclude` properties with a list of endpoint IDs.
 
 For example, to stop exposing all endpoints over JMX and only expose the `health` and `info` endpoints, use the following property:
 
@@ -317,7 +317,7 @@ TIP: If you want to implement your own strategy for when endpoints are exposed,
 [[actuator.endpoints.security]]
 === Security
 For security purposes, all actuators other than `/health` are disabled by default.
-The configprop:management.endpoints.web.exposure.include[] property can be used to enable the actuators.
+You can use the configprop:management.endpoints.web.exposure.include[] property to enable the actuators.
 
 NOTE: Before setting the `management.endpoints.web.exposure.include`, ensure that the exposed actuators do not contain sensitive information and/or are secured by placing them behind a firewall or by something like Spring Security.
 
@@ -366,7 +366,7 @@ This means that the actuator endpoints that require a `POST` (shutdown and logge
 
 NOTE: We recommend disabling CSRF protection completely only if you are creating a service that is used by non-browser clients.
 
-Additional information about CSRF protection can be found in the {spring-security-docs}#csrf[Spring Security Reference Guide].
+You can find additional information about CSRF protection in the {spring-security-docs}#csrf[Spring Security Reference Guide].
 
 
 
@@ -465,7 +465,7 @@ When exposed via JMX, the parameters are mapped to the parameters of the MBean's
 Parameters are required by default.
 They can be made optional by annotating them with either `@javax.annotation.Nullable` or `@org.springframework.lang.Nullable`.
 
-Each root property in the JSON request body can be mapped to a parameter of the endpoint.
+You can map each root property in the JSON request body to a parameter of the endpoint.
 Consider the following JSON request body:
 
 [source,json,indent=0,subs="verbatim"]
@@ -517,7 +517,7 @@ The path of the predicate is determined by the ID of the endpoint and the base p
 The default base path is `/actuator`.
 For example, an endpoint with the ID `sessions` will use `/actuator/sessions` as its path in the predicate.
 
-The path can be further customized by annotating one or more parameters of the operation method with `@Selector`.
+You can further customize the path by annotating one or more parameters of the operation method with `@Selector`.
 Such a parameter is added to the path predicate as a path variable.
 The variable's value is passed into the operation method when the endpoint operation is invoked.
 If you want to capture all remaining path elements, you can add `@Selector(Match=ALL_REMAINING)` to the last parameter and make it a type that is conversion compatible with a `String[]`.
@@ -579,7 +579,7 @@ If an operation is invoked without a required parameter, or with a parameter tha
 
 [[actuator.endpoints.implementing-custom.web.range-requests]]
 ===== Web Endpoint Range Requests
-An HTTP range request can be used to request part of an HTTP resource.
+You can use an HTTP range request to request part of an HTTP resource.
 When using Spring MVC or Spring Web Flux, operations that return a `org.springframework.core.io.Resource` automatically support range requests.
 
 NOTE: Range requests are not supported when using Jersey.
@@ -605,8 +605,8 @@ For new endpoints, the `@Endpoint` and `@WebEndpoint` annotations should be pref
 
 [[actuator.endpoints.implementing-custom.controller]]
 ==== Controller Endpoints
-`@ControllerEndpoint` and `@RestControllerEndpoint` can be used to implement an endpoint that is only exposed by Spring MVC or Spring WebFlux.
-Methods are mapped using the standard annotations for Spring MVC and Spring WebFlux such as `@RequestMapping` and `@GetMapping`, with the endpoint's ID being used as a prefix for the path.
+You can use `@ControllerEndpoint` and `@RestControllerEndpoint` to implement an endpoint that is exposed only by Spring MVC or Spring WebFlux.
+Methods are mapped by using the standard annotations for Spring MVC and Spring WebFlux, such as `@RequestMapping` and `@GetMapping`, with the endpoint's ID being used as a prefix for the path.
 Controller endpoints provide deeper integration with Spring's web frameworks but at the expense of portability.
 The `@Endpoint` and `@WebEndpoint` annotations should be preferred whenever possible.
 
@@ -652,7 +652,7 @@ By default, the final system health is derived by a `StatusAggregator` which sor
 The first status in the sorted list is used as the overall health status.
 If no `HealthIndicator` returns a status that is known to the `StatusAggregator`, an `UNKNOWN` status is used.
 
-TIP: The `HealthContributorRegistry` can be used to register and unregister health indicators at runtime.
+TIP: You can use the `HealthContributorRegistry` to register and unregister health indicators at runtime.
 
 
 
@@ -1154,7 +1154,7 @@ The following `InfoContributor` beans are auto-configured by Spring Boot, when a
 | Exposes build information if a `META-INF/build-info.properties` file is available.
 |===
 
-TIP: It is possible to disable them all by setting the configprop:management.info.defaults.enabled[] property.
+TIP: You can disable them all by setting the configprop:management.info.defaults.enabled[] property.
 
 
 

spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/jmx.adoc

@@ -1,7 +1,8 @@
 [[actuator.jmx]]
 == Monitoring and Management over JMX
 Java Management Extensions (JMX) provide a standard mechanism to monitor and manage applications.
-By default, this feature is not enabled and can be turned on by setting the configuration property configprop:spring.jmx.enabled[] to `true`.
+By default, this feature is not enabled.
+You can turn it on by setting the configprop:spring.jmx.enabled[] configuration property to `true`.
 Spring Boot exposes the most suitable `MBeanServer` as a bean with an ID of `mbeanServer`.
 Any of your beans that are annotated with Spring JMX annotations (`@ManagedResource`, `@ManagedAttribute`, or `@ManagedOperation`) are exposed to it.
 
@@ -68,7 +69,7 @@ For example, with Maven, you would add the following dependency:
 	</dependency>
 ----
 
-The Jolokia endpoint can then be exposed by adding `jolokia` or `*` to the configprop:management.endpoints.web.exposure.include[] property.
+You can then expose the Jolokia endpoint by adding `jolokia` or `*` to the configprop:management.endpoints.web.exposure.include[] property.
 You can then access it by using `/actuator/jolokia` on your management HTTP server.
 
 NOTE: The Jolokia endpoint exposes Jolokia's servlet as an actuator endpoint.

spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/metrics.adoc

@@ -105,7 +105,7 @@ To export metrics to SaaS {micrometer-registry-docs}/appOptics[AppOptics], your
 [[actuator.metrics.export.atlas]]
 ==== Atlas
 By default, metrics are exported to {micrometer-registry-docs}/atlas[Atlas] running on your local machine.
-The location of the https://github.com/Netflix/atlas[Atlas server] to use can be provided using:
+You can provide the location of the https://github.com/Netflix/atlas[Atlas server]:
 
 [source,yaml,indent=0,subs="verbatim",configprops,configblocks]
 ----
@@ -158,7 +158,7 @@ Otherwise, `v2` is assumed.
 
 [[actuator.metrics.export.dynatrace.v2-api]]
 ===== v2 API
-The v2 API can be used in two ways.
+You can use the v2 API in two ways.
 
 If a local OneAgent is running on the host, metrics will be automatically exported to the {dynatrace-help}/how-to-use-dynatrace/metrics/metric-ingestion/ingestion-methods/local-api/[local OneAgent ingest endpoint].
 The ingest endpoint forwards the metrics to the Dynatrace backend.
@@ -243,14 +243,14 @@ The following example sets the export interval to 30 seconds:
 	        step: "30s"
 ----
 
-More information on how to set up the Dynatrace exporter for Micrometer can be found in {micrometer-registry-docs}/dynatrace[the Micrometer documentation].
+You can find more information on how to set up the Dynatrace exporter for Micrometer in {micrometer-registry-docs}/dynatrace[the Micrometer documentation].
 
 
 
 [[actuator.metrics.export.elastic]]
 ==== Elastic
 By default, metrics are exported to {micrometer-registry-docs}/elastic[Elastic] running on your local machine.
-The location of the Elastic server to use can be provided using the following property:
+You can provide the location of the Elastic server to use by using the following property:
 
 [source,yaml,indent=0,subs="verbatim",configprops,configblocks]
 ----
@@ -341,7 +341,7 @@ You should also configure one or more tags to identify the data source to which
 ==== Influx
 By default, metrics are exported to an {micrometer-registry-docs}/influx[Influx] v1 instance running on your local machine with the default configuration.
 To export metrics to InfluxDB v2, configure the `org`, `bucket`, and authentication `token` for writing metrics.
-The location of the https://www.influxdata.com[Influx server] to use can be provided using:
+You can provide the location of the https://www.influxdata.com[Influx server] to use by using:
 
 [source,yaml,indent=0,subs="verbatim",configprops,configblocks]
 ----
@@ -358,7 +358,7 @@ The location of the https://www.influxdata.com[Influx server] to use can be prov
 ==== JMX
 Micrometer provides a hierarchical mapping to {micrometer-registry-docs}/jmx[JMX], primarily as a cheap and portable way to view metrics locally.
 By default, metrics are exported to the `metrics` JMX domain.
-The domain to use can be provided using:
+You can provide the domain to use by using:
 
 [source,yaml,indent=0,subs="verbatim",configprops,configblocks]
 ----
@@ -387,7 +387,7 @@ include::{docs-java}/actuator/metrics/export/jmx/MyJmxConfiguration.java[]
 [[actuator.metrics.export.kairos]]
 ==== KairosDB
 By default, metrics are exported to {micrometer-registry-docs}/kairos[KairosDB] running on your local machine.
-The location of the https://kairosdb.github.io/[KairosDB server] to use can be provided using:
+You can provide the location of the https://kairosdb.github.io/[KairosDB server] to use by using:
 
 [source,yaml,indent=0,subs="verbatim",configprops,configblocks]
 ----
@@ -473,7 +473,7 @@ To enable Prometheus Pushgateway support, add the following dependency to your p
 When the Prometheus Pushgateway dependency is present on the classpath and the configprop:management.metrics.export.prometheus.pushgateway.enabled[] property is set to `true`, a `PrometheusPushGatewayManager` bean is auto-configured.
 This manages the pushing of metrics to a Prometheus Pushgateway.
 
-The `PrometheusPushGatewayManager` can be tuned using properties under `management.metrics.export.prometheus.pushgateway`.
+You can tune the `PrometheusPushGatewayManager` by using properties under `management.metrics.export.prometheus.pushgateway`.
 For advanced configuration, you can also provide your own `PrometheusPushGatewayManager` bean.
 
 
@@ -555,7 +555,7 @@ You can also change the interval at which metrics are sent to Stackdriver:
 ==== StatsD
 The StatsD registry pushes metrics over UDP to a StatsD agent eagerly.
 By default, metrics are exported to a {micrometer-registry-docs}/statsD[StatsD] agent running on your local machine.
-The StatsD agent host, port, and protocol to use can be provided using:
+You can provide the StatsD agent host, port, and protocol to use by using:
 
 [source,yaml,indent=0,subs="verbatim",configprops,configblocks]
 ----
@@ -674,7 +674,7 @@ Metrics are tagged by the name of the executor that is derived from the bean nam
 ==== Spring MVC Metrics
 Auto-configuration enables the instrumentation of all requests handled by Spring MVC controllers and functional handlers.
 By default, metrics are generated with the name, `http.server.requests`.
-The name can be customized by setting the configprop:management.metrics.web.server.request.metric-name[] property.
+You can customized the name by setting the configprop:management.metrics.web.server.request.metric-name[] property.
 
 `@Timed` annotations are supported on `@Controller` classes and `@RequestMapping` methods (see <<actuator#actuator.metrics.supported.timed-annotation>> for details).
 If you don't want to record metrics for all Spring MVC requests, you can set configprop:management.metrics.web.server.request.autotime.enabled[] to `false` and exclusively use `@Timed` annotations instead.
@@ -713,7 +713,7 @@ Applications can opt-in and record exceptions by <<web#web.servlet.spring-mvc.er
 ==== Spring WebFlux Metrics
 Auto-configuration enables the instrumentation of all requests handled by Spring WebFlux controllers and functional handlers.
 By default, metrics are generated with the name, `http.server.requests`.
-The name can be customized by setting the configprop:management.metrics.web.server.request.metric-name[] property.
+You can customize the name by setting the configprop:management.metrics.web.server.request.metric-name[] property.
 
 `@Timed` annotations are supported on `@Controller` classes and `@RequestMapping` methods (see <<actuator#actuator.metrics.supported.timed-annotation>> for details).
 If you don't want to record metrics for all Spring WebFlux requests, you can set configprop:management.metrics.web.server.request.autotime.enabled[] to `false` and exclusively use `@Timed` annotations instead.
@@ -752,7 +752,7 @@ Applications can opt-in and record exceptions by <<web#web.reactive.webflux.erro
 ==== Jersey Server Metrics
 Auto-configuration enables the instrumentation of all requests handled by the Jersey JAX-RS implementation whenever Micrometer's `micrometer-jersey2` module is on the classpath.
 By default, metrics are generated with the name, `http.server.requests`.
-The name can be customized by setting the configprop:management.metrics.web.server.request.metric-name[] property.
+You can customize the name by setting the configprop:management.metrics.web.server.request.metric-name[] property.
 
 `@Timed` annotations are supported on request-handling classes and methods (see <<actuator#actuator.metrics.supported.timed-annotation>> for details).
 If you don't want to record metrics for all Jersey requests, you can set configprop:management.metrics.web.server.request.autotime.enabled[] to `false` and exclusively use `@Timed` annotations instead.
@@ -791,10 +791,10 @@ For that, you have to inject the auto-configured builder and use it to create in
 * `RestTemplateBuilder` for `RestTemplate`
 * `WebClient.Builder` for `WebClient`
 
-It is also possible to apply manually the customizers responsible for this instrumentation, namely `MetricsRestTemplateCustomizer` and `MetricsWebClientCustomizer`.
+You can also manually apply the customizers responsible for this instrumentation, namely `MetricsRestTemplateCustomizer` and `MetricsWebClientCustomizer`.
 
 By default, metrics are generated with the name, `http.client.requests`.
-The name can be customized by setting the configprop:management.metrics.web.client.request.metric-name[] property.
+You can customize the name by setting the configprop:management.metrics.web.client.request.metric-name[] property.
 
 By default, metrics generated by an instrumented client are tagged with the following information:
 
@@ -893,7 +893,7 @@ You can enable that on the auto-configured `EntityManagerFactory` as shown in th
 ==== Spring Data Repository Metrics
 Auto-configuration enables the instrumentation of all Spring Data `Repository` method invocations.
 By default, metrics are generated with the name, `spring.data.repository.invocations`.
-The name can be customized by setting the configprop:management.metrics.data.repository.metric-name[] property.
+You can customize the name by setting the configprop:management.metrics.data.repository.metric-name[] property.
 
 `@Timed` annotations are supported on `Repository` classes and methods (see <<actuator#actuator.metrics.supported.timed-annotation>> for details).
 If you don't want to record metrics for all `Repository` invocations, you can set configprop:management.metrics.data.repository.autotime.enabled[] to `false` and exclusively use `@Timed` annotations instead.
@@ -1039,8 +1039,8 @@ Metrics for Jetty's ``Connector``s are bound using Micrometer's `JettyConnection
 
 [[actuator.metrics.supported.timed-annotation]]
 ==== @Timed Annotation Support
-The `@Timed` annotation from the `io.micrometer.core.annotation` package can be used with several of the supported technologies listed above.
-If supported, the annotation can be used either at the class-level or the method-level.
+You can use the `@Timed` annotation from the `io.micrometer.core.annotation` package with several of the supported technologies described earlier.
+If supported, you can use the annotation at either the class level or the method level.
 
 For example, the following code shows how the annotation can be used to instrument all request mappings in a `@RestController`:
 
@@ -1131,8 +1131,8 @@ As the order of common tags cannot be guaranteed using this approach, Graphite u
 
 [[actuator.metrics.customizing.per-meter-properties]]
 ==== Per-meter Properties
-In addition to `MeterFilter` beans, it's also possible to apply a limited set of customization on a per-meter basis using properties.
-Per-meter customizations apply to any all meter IDs that start with the given name.
+In addition to `MeterFilter` beans, you can apply a limited set of customization on a per-meter basis by using properties.
+Per-meter customizations apply to any meter IDs that start with the given name.
 The following example disables any meters that have an ID starting with `example.remote`
 
 [source,yaml,indent=0,subs="verbatim",configprops,configblocks]

spring-boot-project/spring-boot-docs/src/docs/asciidoc/actuator/tracing.adoc

@@ -1,12 +1,12 @@
 [[actuator.tracing]]
 == HTTP Tracing
-HTTP Tracing can be enabled by providing a bean of type `HttpTraceRepository` in your application's configuration.
+You can enable HTTP Tracing by providing a bean of type `HttpTraceRepository` in your application's configuration.
 For convenience, Spring Boot offers an `InMemoryHttpTraceRepository` that stores traces for the last 100 request-response exchanges, by default.
 `InMemoryHttpTraceRepository` is limited compared to other tracing solutions and we recommend using it only for development environments.
 For production environments, use of a production-ready tracing or observability solution, such as Zipkin or Spring Cloud Sleuth, is recommended.
 Alternatively, create your own `HttpTraceRepository` that meets your needs.
 
-The `httptrace` endpoint can be used to obtain information about the request-response exchanges that are stored in the `HttpTraceRepository`.
+You can use the `httptrace` endpoint to obtain information about the request-response exchanges that are stored in the `HttpTraceRepository`.