有时，为管理节点定制前缀是有用的。例如，你的应用程序可能已经使用 /actuator 另一个目的。可以使用 management.endpoints.web.base-path 属性更改管理节点的前缀，如下面的示例所示：

management.endpoints.web.base-path=/manage

前面的 application.properties 示例将节点 /actuator/{id} 更改为 /manage/{id} (例如，/manage/info)。

	Note
	除非管理端口被配置为通过使用不同的 HTTP 端口暴露节点，否则 management.endpoints.web.base-path 相对于 server.servlet.context-path。如果配置了 management.server.port，则 management.endpoints.web.base-path 相对于 management.server.servlet.context-path。

使用默认 HTTP 端口暴露管理节点是基于云部署的明智选择。但是，如果你的应用程序运行在自己的数据中心内，那么你可能更喜欢使用不同的 HTTP 端口来暴露节点。

你可以设置 management.server.port 属性来更改 HTTP 端口，如下面的示例所示：

management.server.port=8081

当配置为使用自定义端口时，管理服务器也可以通过使用各种 management.server.ssl.* 属性来配置自己的SSL。例如，这样做可以让管理服务器在 HTTP 上可用，而主应用程序使用 HTTPS，如下面的属性设置所示：

server.port=8443
server.ssl.enabled=true
server.ssl.key-store=classpath:store.jks
server.ssl.key-password=secret
management.server.port=8080
management.server.ssl.enabled=false

或者，主服务器和管理服务器都可以使用 SSL，但具有不同的密钥存储，如下：

server.port=8443
server.ssl.enabled=true
server.ssl.key-store=classpath:main.jks
server.ssl.key-password=secret
management.server.port=8080
management.server.ssl.enabled=true
management.server.ssl.key-store=classpath:management.jks
management.server.ssl.key-password=secret

可以通过设置 management.server.address 属性自定义管理节点可用的地址。如果只想在内部或面向操作系统的网络上监听，或者只监听来自 localhost 的连接，那么这样做很有用。

	Note
	只有当端口不同于主服务器端口时，才能监听不同的地址。

下面的示例 application.properties 不允许远程管理连接：

management.server.port=8081
management.server.address=127.0.0.1

如果不想通过 HTTP 暴露节点，可以将管理端口设置为 -1，如下面的示例所示：

management.server.port=-1

MBean 的名称通常是由节点 id 生成的。例如，health 节点被暴露为 org.springframework.boot:type=Endpoint,name=Health。

如果你的应用程序包含不止一个 Spring ApplicationContext，你可能会发现名称冲突。为了解决这个问题，可以将 management.endpoints.jmx.unique-names 属性设置为 true，以便 MBean 名称总是唯一的。

还可以自定义节点被暴露的 JMX 域。下面的设置展示了在 application.properties 中这样做的一个示例：

management.endpoints.jmx.domain=com.example.myapp
management.endpoints.jmx.unique-names=true

如果不想通过 JMX 暴露节点，可以将 management.endpoints.jmx.exposure.exclude 属性设置为 *，如下面的示例所示：

management.endpoints.jmx.exposure.exclude=*

Jolokia 是一个 JMX-HTTP 桥，它提供了一种访问 JMX bean 的替代方法。为了使用 Jolokia，请包含 org.jolokia:jolokia-core 的依赖。例如，使用 Maven，你将添加以下依赖项：

<dependency>
	<groupId>org.jolokia</groupId>
	<artifactId>jolokia-core</artifactId>
	</dependency>

然后可以通过向 management.endpoints.web.exposure.include 属性添加 jolokia 或 * 来暴露 Jolokia 节点。然后，可以在管理 HTTP 服务器上使用 /actuator/jolokia 访问它。

management.endpoint.jolokia.config.debug=true

management.endpoint.jolokia.enabled=false

若要配置给定的记录器，请将部分实体 POST 到资源的 URI 上，如以下示例所示：

{
	"configuredLevel": "DEBUG"
}

	Tip
	若要重置日志程序的特定级别（而是使用默认配置），可以将 null 值作为 configuredLevel 传递。

Spring Boot 自动配置综合的 MeterRegistry，并为它在类路径上找到的每个支持的实现综合的添加注册表。在运行时类路径中有一个 micrometer-registry-{system} 的依赖就足以让 Spring Boot 配置注册表。

大多数注册表有共同的特点。例如，即使 Micrometer 注册表实现在类路径上，也可以禁用特定的注册表。例如，禁用 Datadog：

management.metrics.export.datadog.enabled=false

Spring Boot 还将向 Metrics 类上的全局静态综合注册表添加任何

management.metrics.use-global-registry=false

你可以注册任意数量的 MeterRegistryCustomizer bean 以进一步配置注册表，例如在向注册表注册任何表之前，应用公共标记：

@Bean
MeterRegistryCustomizer<MeterRegistry> metricsCommonTags() {
	return registry -> registry.config().commonTags("region", "us-east-1");
}

你可以通过更具体地了解泛型类型来将定制应用到特定的注册表实现：

@Bean
MeterRegistryCustomizer<GraphiteMeterRegistry> graphiteMetricsNamingConvention() {
	return registry -> registry.config().namingConvention(MY_CUSTOM_CONVENTION);
}

通过该设置，你可以将 MeterRegistry 注入组件并注册度量：

@Component
public class SampleBean {

	private final Counter counter;

	public SampleBean(MeterRegistry registry) {
		this.counter = registry.counter("received.messages");
	}

	public void handleMessage(String message) {
		this.counter.increment();
		// handle message implementation
	}

}

Spring Boot 还配置内置工具（即 MeterBinder 实现），你可以通过配置或专用注解标记来控制这些工具。

Spring Boot 在适用时注册以下核心度量：

@RestController
@Timed 
public class MyController {

	@GetMapping("/api/people")
	@Timed(extraTags = { "region", "us-east-1" }) 
	@Timed(value = "all.people", longTask = true) 
	public List<Person> listPeople() { ... }

}

55.3.4 缓存度量

自动配置允许在启动时使用以 cache 为前缀的度量对所有可用 Cache 进行插装。对于基本的度量集合，缓存工具是标准化的。另外，缓存特定的度量也是可用的。

支持以下缓存库：

• Caffeine
• EhCache 2
• Hazelcast
• 任何符合 JCache (JSR-107) 的实现

度量由缓存的名称和由 bean 名称派生的 CacheManager 的名称来标记。

	Note
	只有启动时可用的缓存绑定到注册表。对于在启动阶段或以编程方式创建的缓存，需要进行显式注册。一个 CacheMetricsRegistrar bean 可用于使该过程更容易。

55.3.5 数据源度量

自动配置允许使用一个称为 jdbc 的度量来检测所有可用的 DataSource 对象。数据源插装的结果是表示池中当前活动的、允许的最大连接和最小允许的连接的标准。这些标准中的每一个都有一个 jdbc 前缀的名称。

度量也由基于 bean 名称计算的 DataSource 的名称标记。

	Tip
	默认情况下，Spring Boot 为所有支持的数据源提供元数据；如果你喜欢的数据源不受支持，则可以添加额外的 DataSourcePoolMetadataProvider bean。有关示例，请参阅 DataSourcePoolMetadataProvidersConfiguration。

此外，Hikari 特定的度量使用 hikaricp 前缀来暴露。每个度量都由池的名称来标记（可以用 spring.datasource.name 来控制）。

spring.jpa.properties.hibernate.generate_statistics=true

若要注册自定义度量，请将 MeterRegistry 注入到组件中，如以下示例所示：

class Dictionary {

	private final List<String> words = new CopyOnWriteArrayList<>();

	Dictionary(MeterRegistry registry) {
		registry.gaugeCollectionSize("dictionary.size", Tags.empty(), this.words);
	}

	// …

}

如果你发现在组件或应用程序之间重复地工具化一组度量，则可以将该套件封装到 MeterBinder 实现中。默认情况下，来自所有 MeterBinder bean 的度量将自动绑定到 Spring 管理的 MeterRegistry。

如果需要将自定义度量应用到特定的 Meter 实例，可以使用 io.micrometer.core.instrument.config.MeterFilter 接口。默认情况下，所有 MeterFilter bean 都会自动应用到 micrometerMeterRegistry.Config。

例如，如果希望将 mytag.region 标记重命名为 mytag.area，用于以 com.example 开头的所有仪表 ID，则可以执行以下操作：

@Bean
public MeterFilter renameRegionTagMeterFilter() {
	return MeterFilter.renameTag("com.example", "mytag.region", "mytag.area");
}

55.5.1 通用标签

通用标签通常用于对操作环境（如主机、实例、区域、堆栈等）进行维度向下钻取。通用标签应用于所有仪表，并且可以按照以下示例进行配置：

management.metrics.tags.region=us-east-1
management.metrics.tags.stack=prod

上面的示例将 region 和 stack 标签添加到具有 us-east-1 和 prod 值的所有仪表中。

	Note
	如果使用 Graphite，普通标签的顺序是很重要的。由于使用此方法不能保证通用标签的顺序，因此建议 Graphite 用户定义定制的 MeterFilter。

management.metrics.enable.example.remote=false

Spring Boot 提供了一个 metrics 节点，可以用来诊断性地检查应用程序收集的度量。默认情况下，节点不可用，必须暴露，请参阅暴露端点以获取更多细节。

导航到 /actuator/metrics 显示可用仪表名的列表。你可以通过提供特定仪表的名称作为选择器（例如 /actuator/metrics/jvm.memory.max）向下钻取以查看关于该特定仪表的信息。

	Tip
	在这里使用的名称应该与代码中使用的名称相匹配，而不是在它被传输到的监控系统已被命名规范化之后的名称。换句话说，如果 jvm.memory.max 由于它的 snake 情况命名约定而出现在 Prometheus 中的 jvm_memory_max，那么在检查 metrics 节点中的仪表时，仍然应该使用 jvm.memory.max 作为选择器。

你还可以向 URL 的末尾添加任意数量的 tag=KEY:VALUE 查询参数，以便在维度上向下钻取仪表，例如 /actuator/metrics/jvm.memory.max?tag=area:nonheap。

	Tip
	报告的测量值是匹配仪表名称和已应用的任何标记的所有仪表的统计值的总和。因此，在上面的示例中，返回的 "Value" 统计信息是堆的 "Code Cache"、"Compressed Class Space" 和 "Metaspace" 区域的最大内存占用的总和。如果只想看到 "Metaspace" 的最大大小，可以添加一个附加 tag=id:Metaspace，即 /actuator/metrics/jvm.memory.max?tag=area:nonheap&tag=id:Metaspace。

若要自定义包含在每个追踪中的项，请使用 management.trace.http.include 配置属性。

默认情况下，使用存储最后100个请求响应交换的追踪的 InMemoryHttpTraceRepository。如果需要扩展容量，可以定义自己的 InMemoryHttpTraceRepository bean 的实例。你还可以创建自己的替代 HttpTraceRepository 实现。

在 META-INF/spring.factories 文件中，可以激活编写 PID 文件的监听器，如下面的示例所示：

org.springframework.context.ApplicationListener=\
org.springframework.boot.context.ApplicationPidFileWriter,\
org.springframework.boot.web.context.WebServerPortFileWriter

还可以通过调用 SpringApplication.addListeners(…​) 方法并传递适当的 Writer 对象来激活监听器。此方法还可以自定义 Writer 构造函数中的文件名和路径。

如果希望完全禁用 /cloudfoundryapplication 节点，可以将以下设置添加到 application.properties 文件中：

application.properties. 

management.cloudfoundry.enabled=false

默认情况下，/cloudfoundryapplication 节点的安全验证对各种 Cloud Foundry 服务进行 SSL 调用。如果你的 Cloud Foundry UAA 或 Cloud 控制器服务使用自签名证书，则需要设置以下属性：

application.properties. 

management.cloudfoundry.skip-ssl-validation=true

如果服务器的上下文路径已经配置为 /，则 Cloud Foundry 节点在应用程序的根目录下将不可用。例如，如果 server.servlet.context-path=/app，那么 Cloud Foundry 节点将在 /app/cloudfoundryapplication/* 处可用。

如果你期望 Cloud Foundry 节点总是在 /cloudfoundryapplication/* 处可用，而不管服务器的上下文路径如何，你将需要在应用程序中显式地配置它。根据使用中的 web 服务器，配置将有所不同。对于 Tomcat，可以添加以下配置：

@Bean
public TomcatServletWebServerFactory servletWebServerFactory() {
	return new TomcatServletWebServerFactory() {

		@Override
		protected void prepareContext(Host host,
				ServletContextInitializer[] initializers) {
			super.prepareContext(host, initializers);
			StandardContext child = new StandardContext();
			child.addLifecycleListener(new Tomcat.FixContextListener());
			child.setPath("/cloudfoundryapplication");
			ServletContainerInitializer initializer = getServletContextInitializer(
					getContextPath());
			child.addServletContainerInitializer(initializer, Collections.emptySet());
			child.setCrossContext(true);
			host.addChild(child);
		}

	};
}

private ServletContainerInitializer getServletContextInitializer(String contextPath) {
	return (c, context) -> {
		Servlet servlet = new GenericServlet() {

			@Override
			public void service(ServletRequest req, ServletResponse res)
					throws ServletException, IOException {
				ServletContext context = req.getServletContext()
						.getContext(contextPath);
				context.getRequestDispatcher("/cloudfoundryapplication").forward(req,
						res);
			}

		};
		context.addServlet("cloudfoundry", servlet).addMapping("/*");
	};
}