> For the complete documentation index, see [llms.txt](https://potoyang.gitbook.io/spring-in-action-v5/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://potoyang.gitbook.io/spring-in-action-v5/di-16-zhang-shi-yong-springboot-actuator/16.2-xiao-fei-actuator-duan-dian/16.2.2-cha-kan-pei-zhi-xiang-xi-xin-xi.md). # 16.2.2 查看配置详细信息 除了获取有关应用程序的一般信息之外，了解应用程序的配置信息也很有用。应用程序上下文中有哪些 bean？哪些自动配置条件通过或失败？应用程序可以使用哪些环境属性？HTTP 请求如何映射到控制器？一个或多个包或类设置为怎样的日志级别？ 这些问题由 Actuator 的 `/beans`、`/conditions`、`/env`、`/configprops`、`/mappings` 和 `/loggers` 端点回答。 在某些情况下，例如 `/env` 和 `/loggers`，您甚至可以动态调整正在运行的应用程序的配置。从 `/beans` 端点开始，我们将查看每一个端点，以深入了解正在运行的应用程序的配置。 **获取 Bean Wiring 报告** 探索 Spring 应用程序上下文最重要的端点是 `/beans` 端点。此端点返回一个 JSON 文档，描述应用程序上下文中的每个 bean、它的 Java 类型以及它注入的任何其他 bean。 对 `/beans` 的 GET 请求所得到的完整响应信息非常多，可以轻松地填满本章。作为完整响应的替代，让我们考虑以下片段，它专注于单个 bean 条目： ``` { "contexts": { "application-1": { "beans": { ... "ingredientsController": { "aliases": [], "scope": "singleton", "type": "tacos.ingredients.IngredientsController", "resource": "file [/Users/habuma/Documents/Workspaces/ TacoCloud/ingredient-service/target/classes/tacos/ingredients/ IngredientsController.class]", "dependencies": [ "ingredientRepository" ] }, ... }, "parentId": null } } } ``` 响应的根是 contexts 元素，它包含应用程序中每个 Spring 应用程序上下文的一个子元素。在每个应用程序上下文中都有一个 beans 元素，其中包含应用程序上下文中所有 bean 的详细信息。 在前面的示例中，显示的 bean 是名称为 `ingredientsController` 的 bean。您可以看到它没有别名，范围为单例，并且类型为 `tacos.ingredients.IngredientsController`。此外，资源属性给出了定义 bean 的类文件的路径。并且 dependencies 属性列出了注入给定 bean 的所有其他 bean。 在这种情况下，`ingredientsController` bean 被注入了一个名称为 `ingredientRepository` 的 bean。 **解释自动配置** 如您所见，自动配置是 Spring Boot 提供的最强大的功能之一。但是，有时您可能想知道为什么会自动配置某些内容。或者您可能期望某些东西被自动配置，想知道它为什么没有被自动配置。在这种情况下，您可以向 `/conditions` 发出 GET 请求，以了解自动配置的情况。 `/conditions` 返回的自动配置报告分为三部分：positiveMatches（条件配置通过）、negativeMatches（条件配置失败）和 unconditionalClasses（无条件类）。以下是 `/conditions` 请求的响应的片段，示例显示了每个部分： ``` { "contexts": { "application-1": { "positiveMatches": { ... "MongoDataAutoConfiguration#mongoTemplate": [ { "condition": "OnBeanCondition", "message": "@ConditionalOnMissingBean (types :org.springframework.data.mongodb.core.MongoTemplate; SearchStrategy: all) did not find any beans" } ], ... }, "negativeMatches": { ... "DispatcherServletAutoConfiguration": { "notMatched": [ { "condition": "OnClassCondition", "message": "@ConditionalOnClass did not find required class 'org.springframework.web.servlet. DispatcherServlet'" } ], "matched": [] }, ... }, "unconditionalClasses": [ ... "org.springframework.boot.autoconfigure.context. ConfigurationPropertiesAutoConfiguration", ... ] } } } ``` 在 positiveMatches 部分，您会看到 MongoTemplate bean 是由自动配置配置的，且因为它不存在。导致这种情况的自动配置是因为有 `@ConditionalOnMissingBean` 注释，如果尚未显式配置要配置的 bean，则它会传递要配置的 bean。在这种情况下，由于没有找到 MongoTemplate 类型的 bean，因此自动配置介入并配置了一个。 在 negativeMatches 下，Spring Boot 自动配置考虑配置一个 DispatcherServlet。但是 @ConditionalOnClass 条件注解失败了，因为找不到 DispatcherServlet。 最后，如 unconditionalClasses 部分所示，配置了 ConfigurationPropertiesAutoConfiguration bean。配置属性是 Spring Boot 运行的基础，因此任何与配置属性相关的配置，都应该在没有任何条件的情况下自动配置。 **检查环境和配置属性** 除了了解您的应用程序 bean 如何连接在一起之外，您可能还对了解哪些环境属性可用，以及哪些配置属性注入了 bean 中感兴趣。 当您向 `/env` 端点发出 GET 请求时，您将收到一个相当长的，来自 Spring 应用程序正在运行的，所有属性来源的属性列表。这包括来自环境变量的属性、JVM 系统属性、`application.properties` 和 `application.yml` 文件，甚至 Spring Cloud Config Server（如果应用程序是 Config Server 的客户端）。 下面的清单显示了，您可能从 `/env` 端点获得的响应数据的一个大大简化的示例，让您对它提供的信息有所了解。 {% code title="清单 16.1 来自 /env 端点的数据" %} ```bash $ curl localhost:8081/actuator/env { "activeProfiles": [ "development" ], "propertySources": [ ... { "name": "systemEnvironment", "properties": { "PATH": { "value": "/usr/bin:/bin:/usr/sbin:/sbin", "origin": "System Environment Property \"PATH\"" }, ... "HOME": { "value": "/Users/habuma", "origin": "System Environment Property \"HOME\"" } } }, { "name": "applicationConfig: [classpath:/application.yml]", "properties": { "spring.application.name": { "value": "ingredient-service", "origin": "class path resource [application.yml]:3:11" }, "server.port": { "value": 8081, "origin": "class path resource [application.yml]:9:9" }, ... } }, ... ] } ``` {% endcode %} 尽管 `/env` 的完整响应提供了更多信息，但清单 16.1 中包含了那些需要关注的元素。首先，请注意响应顶部是一个名为 activeProfiles 的字段。现在的配置表明 development 配置文件处于活动状态。 如果任何其他配置文件处于活动状态，也将列出这些配置文件。 接下来，propertySources 字段是一个数组，其中包含 Spring 应用程序环境中每个属性源的条目。在清单 16.1 中，只显示了 systemEnvironment 和引用 application.yml 文件的 applicationConfig 属性源。 在每个属性源中，列出了该源提供的所有属性，并与其值配对。在 application.yml 属性源的情况下，每个属性的 origin 字段准确说明属性设置的位置，包括在 application.yml 中的行和列。 当该属性的名称作为路径的第二个元素给出时，`/env` 端点还可用于获取特定属性。例如，要检查 server.port 属性，请提交对 `/env/server.port` 的 GET 请求，如下所示： ```bash $ curl localhost:8081/actuator/env/server.port { "property": { "source": "systemEnvironment", "value": "8081" }, "activeProfiles": [ "development" ], "propertySources": [ { "name": "server.ports" }, { "name": "mongo.ports" }, { "name": "systemProperties" }, { "name": "systemEnvironment", "property": { "value": "8081", "origin": "System Environment Property \"SERVER_PORT\"" } }, { "name": "random" }, { "name": "applicationConfig: [classpath:/application.yml]", "property": { "value": 0, "origin": "class path resource [application.yml]:9:9" } }, { "name": "springCloudClientHostInfo" }, { "name": "refresh" }, { "name": "defaultProperties" }, { "name": "Management Server" } ] } ``` 如您所见，所有属性源仍被表示，但只有那些设置了指定属性的源才会包含附加信息。在这种情况下，系统环境属性源和 application.yml 属性源都具有 `server.port` 属性的值。因为 systemEnvironment 属性源优先于它下面列出的任何属性源，所以它的值 8081 胜出。获胜值反映在属性字段下方的顶部附近。 `/env` 端点不仅可以用于读取属性值。通过向 /env 端点提交 POST 请求以及带有名称和值字段的 JSON 数据，您还可以在正在运行的应用程序中设置属性。例如，要将名为 `tacocloud.discount.code` 的属性设置为 TACOS1234，您可以使用 curl 在命令行提交 POST 请求，如下所示： ```bash $ curl localhost:8081/actuator/env \ -d'{"name":"tacocloud.discount.code","value":"TACOS1234"}' \ -H "Content-type: application/json" {"tacocloud.discount.code":"TACOS1234"} ``` 提交属性后，新设置的属性及其值将在响应中返回。稍后，如果您决定不再需要该属性，您可以向 `/env` 端点提交 DELETE 请求，以删除通过该端点创建的所有属性： ```bash $ curl localhost:8081/actuator/env -X DELETE {"tacocloud.discount.code":"TACOS1234"} ``` 与通过 Actuator 的 API 设置属性一样重要，要注意，使用 `/env` 端点的 POST 请求设置的任何属性，仅适用于接收请求的应用程序实例，是临时的，并且会在应用程序重新启动时丢失. **浏览 HTTP 请求映射** 尽管 Spring MVC（和 Spring WebFlux 的）编程模型，通过简单地使用请求映射注释，对方法进行注释来轻松处理 HTTP 请求，但有时很难全面了解，应用程序可以处理的所有类型的 HTTP 请求，以及处理这些请求的组件类型。 Actuator 的 `/mappings` 端点提供了应用程序中每个 HTTP 请求处理程序的一站式视图，无论是来自 Spring MVC 控制器还是 Actuator 自己的端点之一。要获取 Spring Boot 应用程序中所有端点的完整列表，请向 `/mappings` 端点发出 GET 请求，您可能会收到类似于下面显示的简化响应的内容。 {% code title="清单 16.2 如 /mappings 端点所示的 HTTP 请求映射" %} ```bash $ curl localhost:8081/actuator/mappings | jq { "contexts": { "application-1": { "mappings": { "dispatcherHandlers": { "webHandler": [ ... { "predicate": "{[/ingredients],methods=[GET]}", "handler": "public reactor.core.publisher.Flux tacos.ingredients.IngredientsController.allIngredients()", "details": { "handlerMethod": { "className": "tacos.ingredients.IngredientsController", "name": "allIngredients", "descriptor": "()Lreactor/core/publisher/Flux;" }, "handlerFunction": null, "requestMappingConditions": { "consumes": [], "headers": [], "methods": [ "GET" ], "params": [], "patterns": [ "/ingredients" ], "produces": [] } } }, ... ] } }, "parentId": "application-1" }, "bootstrap": { "mappings": { "dispatcherHandlers": {} }, "parentId": null } } } ``` {% endcode %} 为简洁起见，此响应已被删节以仅显示单个请求处理程序。具体来说，它表明对 `/ingredients` 的 GET 请求将由 IngredientsController 的 allIngredients() 方法处理。 **管理日志级别** 日志记录对任何应用程序来说都是非常重要的功能。日志记录可以提供一种审计手段，以及一种粗略的调试手段。 设置日志记录级别是需要进行反复权衡的行为。如果日志级别设置得低，日志中可能会出现过多的噪音，可能很难找到有用的信息。另一方面，如果您将日志记录级别设置得太高，则日志对于了解应用程序正在执行的操作可能没有多大价值。 日志级别通常应用在包级别上。如果您想知道正在运行的 Spring Boot 应用程序中设置了哪些日志记录级别，您可以向 `/loggers` 端点发出 GET 请求。以下 JSON 显示了对 `/loggers` 的响应的摘录： ```bash { "levels": [ "OFF", "ERROR", "WARN", "INFO", "DEBUG", "TRACE" ], "loggers": { "ROOT": { "configuredLevel": "INFO", "effectiveLevel": "INFO" }, ... "org.springframework.web": { "configuredLevel": null, "effectiveLevel": "INFO" }, ... "tacos": { "configuredLevel": null, "effectiveLevel": "INFO" }, "tacos.ingredients": { "configuredLevel": null, "effectiveLevel": "INFO" }, "tacos.ingredients.IngredientServiceApplication": { "configuredLevel": null, "effectiveLevel": "INFO" } } } ``` 响应数据以所有有效日志记录级别的列表开始。之后，loggers 元素会列出应用程序中每个包的日志记录级别的详细信息。 configureLevel 属性显示已显式配置的日志记录级别（如果尚未显式配置，则为 null）。 EffectiveLevel 属性给出了有效的日志级别，它可能是从父包或根记录器继承的。 此示例仅显示了根记录器和四个包的日志记录级别，完整的响应会包括应用程序中每个包的日志记录级别条目，包含所有使用到的库中的包。如果您希望查看特定包，您可以将包名称指定为请求路径中的一部分。 例如，如果您只想知道为 tacocloud.ingredients 设置了哪些日志记录级别。您可以向 `/loggers/tacos.ingredients` 发出请求： ```bash { "configuredLevel": null, "effectiveLevel": "INFO" } ``` 除了返回应用程序包的日志级别外，`/loggers` 端点还允许您通过发出 POST 请求来更改配置的日志级别。例如，假设您要将 `tacocloud.ingredients` 包的日志记录级别设置为 DEBUG。用以下 curl 命令将实现这一点： ```bash $ curl localhost:8081/actuator/loggers/tacos/ingredients \ -d'{"configuredLevel":"DEBUG"}' \ -H"Content-type: application/json" ``` 现在日志级别已更改，您可以向 `/loggers/tacos/ingredients` 发出 GET 请求以查看更改： ```bash { "configuredLevel": "DEBUG", "effectiveLevel": "DEBUG" } ``` 请注意，configuredLevel 以前为 null，现在是 DEBUG。这种变化也传递到了 effectiveLevel。但最重要的是，如果该包中的任何代码在调试级别记录任何内容，日志文件将包含该调试级别信息。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://potoyang.gitbook.io/spring-in-action-v5/di-16-zhang-shi-yong-springboot-actuator/16.2-xiao-fei-actuator-duan-dian/16.2.2-cha-kan-pei-zhi-xiang-xi-xin-xi.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.