1 actuator简介
在Spring Boot的众多StarterPOMs中有一个特殊的模块，它不同于其他模块那样大多用于开发业务功能或是连接一些其他外部资源。它完全是一个用于暴露自身信息的模块，所以很明显，它的主要作用是用于监控与管理，它就是：spring-boot-starter-actuator。
spring-boot-starter-actuator模块的实现对于实施微服务的中小团队来说，可以有效地减少监控系统在采集应用指标时的开发量。当然，它也并不是万能的，有时候我们也需要对其做一些简单的扩展来帮助我们实现自身系统个性化的监控需求。下面，我们将详细的介绍一些关于spring-boot-starter-actuator模块的内容，包括它的原生提供的端点以及一些常用的扩展和配置方式。
1.1 引入依赖
在mybatis-spring-boot项目的pom文件中引入actuator依赖：
<dependency>
<!--引入spring bootactuator监控 -->
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
启动项目，查看控制台效果：
上图显示了一批端点定义，这些端点并非我们自己在程序中创建，而是由spring-boot-starter-actuator模块根据应用依赖和配置自动创建出来的监控和管理端点。通过这些端点，我们可以实时的获取应用的各项监控指标，比如：访问/health端点，我们可以获得如下返回的应用健康信息：
1.2 actuator原生端点
列举一些主要的endpoints：
通过在快速入门示例中添加spring-boot-starter-actuator模块，我们已经对它有了一个初步的认识。接下来，我们详细介绍一下spring-boot-starter-actuator模块中已经实现的一些原生端点。如果根据端点的作用来说，我们可以原生端点分为三大类：
应用配置类：获取应用程序中加载的应用配置、环境变量、自动化配置报告等与Spring Boot应用密切相关的配置类信息。
度量指标类：获取应用程序运行过程中用于监控的度量指标，比如：内存信息、线程池信息、HTTP请求统计等。
操作控制类：提供了对应用的关闭等操作类功能。
下面我们来详细了解一下这三类端点都分别可以为我们提供怎么样的有用信息和强大功能，以及我们如何去扩展和配置它们。
1.2.1 应用配置类
由于Spring Boot为了改善传统Spring应用繁杂的配置内容，采用了包扫描和自动化配置的机制来加载原本集中于xml文件中的各项内容。虽然这样的做法，让我们的代码变得非常简洁，但是整个应用的实例创建和依赖关系等信息都被离散到了各个配置类的注解上，这使得我们分析整个应用中资源和实例的各种关系变得非常的困难。而这类端点就可以帮助我们轻松的获取一系列关于Spring 应用配置内容的详细报告，比如：自动化配置的报告、Bean创建的报告、环境属性的报告等。
1.2.1.1 /autoconfig
/autoconfig：该端点用来获取应用的自动化配置报告，其中包括所有自动化配置的候选项。同时还列出了每个候选项自动化配置的各个先决条件是否满足。所以，该端点可以帮助我们方便的找到一些自动化配置为什么没有生效的具体原因。该报告内容将自动化配置内容分为两部分：
positiveMatches中返回的是条件匹配成功的自动化配置
negativeMatches中返回的是条件匹配不成功的自动化配置
访问：
必须给予特定权限才能访问资源！解决方案：关闭安全认证！
management.security.enabled=false
从如上示例中我们可以看到，每个自动化配置候选项中都有一系列的条件，比如上面没有成功匹配的
HealthIndicatorAutoConfiguration.DataSourcesHealthIndicatorConfiguration配置，它的先决条件就是需要在工程中包含
org.springframework.jdbc.core.JdbcTemplate类，由于我们没有引入相关的依赖，它就不会执行自动化配置内容。所以，当我们发现有一些期望的配置没有生效时，就可以通过该端点来查看没有生效的具体原因。
1.2.1.2 /beans
/beans：该端点用来获取应用上下文中创建的所有Bean。
如上示例中，我们可以看到在每个bean中都包含了下面这几个信息：
bean：Bean的名称
scope：Bean的作用域
type：Bean的Java类型
reource：class文件的具体路径
dependencies：依赖的Bean名称
1.2.1.3 /configprops
/configprops：该端点用来获取应用中配置的属性信息报告。从下面该端点返回示例的片段中，我们看到返回了关于该短信的配置信息，prefix属性代表了属性的配置前缀，properties代表了各个属性的名称和值。所以，我们可以通过该报告来看到各个属性的配置路径，比如我们要关闭该端点，就可以通过使用endpoints.configprops.enabled=false来完成设置。
设置：endpoints.configprops.enabled=false
1.2.1.4 /env
/env：该端点与/configprops不同，它用来获取应用所有可用的环境属性报告。包括：环境变量、JVM属性、应用的配置配置、命令行中的参数。从下面该端点返回的示例片段中，我们可以看到它不仅返回了应用的配置属性，还返回了系统属性、环境变量等丰富的配置信息，其中也包括了应用还没有没有使用的配置。所以它可以帮助我们方便地看到当前应用可以加载的配置信息，并配合@ConfigurationProperties注解将它们引入到我们的应用程序中来进行使用。另外，为了配置属性的安全，对于一些类似密码等敏感信息，该端点都会进行隐私保护，但是我们需要让属性名中包含：password、secret、key这些关键词，这样该端点在返回它们的时候会使用*来替代实际的属性值。
1.2.1.5 /mappings
/mappings：该端点用来返回所有Spring MVC的控制器映射关系报告。从下面的示例片段中，我们可以看该报告的信息与我们在启用Spring MVC的Web应用时输出的日志信息类似，其中bean属性标识了该映射关系的请求处理器，method属性标识了该映射关系的具体处理类和处理函数。
1.2.1.6 /info
/info：该端点用来返回一些应用自定义的信息。默认情况下，该端点只会返回一个空的json内容。我们可以在application.properties配置文件中通过info前缀来设置一些属性，需要在配置文件设置：
application.yml配置：
info:
aaa:
name: xxx
email: xxx@qq.com
bbb:
age: 25
hobbies: running
build:
artifact: "@project.artifactId@"
name: "@project.name@"
version: "@project.version@"
application.properties配置：
# actuator中/info信息自定义配置
info.aaa.name=wyait
info.aaa.email=xxx@qq.com
info.bbb.age=27
info.bbb.hobbies=running
info.build.artifact="@project.artifactId@"
info.build.name="@project.name@"
info.build.version="@project.version@"
此时访问localhost:8080/info返回一下信息
如果使用maven，可以访问pom.xml文件的信息，用法如下:
// 获取pom.xml中project节点下artifactId属性
artifact: “@project.artifactId@”
1.2.2 度量指标类
上面我们所介绍的应用配置类端点所提供的信息报告在应用启动的时候都已经基本确定了其返回内容，可以说是一个静态报告。而度量指标类端点提供的报告内容则是动态变化的，这些端点提供了应用程序在运行过程中的一些快照信息，比如：内存使用情况、HTTP请求统计、外部资源指标等。这些端点对于我们构建微服务架构中的监控系统非常有帮助，由于Spring Boot应用自身实现了这些端点，所以我们可以很方便地利用它们来收集我们想要的信息，以制定出各种自动化策略。下面，我们就来分别看看这些强大的端点功能。
1.2.2.1 /metrics
· /metrics：该端点用来返回当前应用的各类重要度量指标，比如：内存信息、线程信息、垃圾回收信息等。
{
mem: 406912
mem.free: 265320
processors: 4
instance.uptime: 266897
uptime: 271256
systemload.average: -1
heap.committed: 366080
heap.init: 130221
heap.used: 100759
heap: 1853440
nonheap.committed: 41088
nonheap.init: 24000
nonheap.used: 40832
nonheap: 133120
threads.peak: 24
threads.daemon: 20
threads.totalStarted: 27
threads: 22
classes: 6639
classes.loaded: 6639
classes.unloaded: 0
gc.ps_scavenge.count: 8
gc.ps_scavenge.time: 77
gc.ps_marksweep.count: 0
gc.ps_marksweep.time: 0
httpsessions.max: -1
httpsessions.active: 0
counter.status.200.env: 1
counter.status.200.mappings: 1
gauge.response.env: 67
gauge.response.mappings: 5
}
从上面的示例中，我们看到有这些重要的度量值：
系统信息：包括处理器数量processors、运行时间uptime和instance.uptime、系统平均负载systemload.average。
mem.*：内存概要信息，包括分配给应用的总内存数量以及当前空闲的内存数量。这些信息来自java.lang.Runtime。
heap.*：堆内存使用情况。这些信息来自java.lang.management.MemoryMXBean接口中getHeapMemoryUsage方法获取的java.lang.management.MemoryUsage。
nonheap.*：非堆内存使用情况。这些信息来自java.lang.management.MemoryMXBean接口中getNonHeapMemoryUsage方法获取的java.lang.management.MemoryUsage。
threads.*：线程使用情况，包括线程数、守护线程数（daemon）、线程峰值（peak）等，这些数据均来自java.lang.management.ThreadMXBean。
classes.*：应用加载和卸载的类统计。这些数据均来自java.lang.management.ClassLoadingMXBean。
gc.*：垃圾收集器的详细信息，包括垃圾回收次数gc.ps_scavenge.count、垃圾回收消耗时间gc.ps_scavenge.time、标记-清除算法的次数gc.ps_marksweep.count、标记-清除算法的消耗时间gc.ps_marksweep.time。这些数据均来自java.lang.management.GarbageCollectorMXBean。
httpsessions.*：Tomcat容器的会话使用情况。包括最大会话数httpsessions.max和活跃会话数httpsessions.active。该度量指标信息仅在引入了嵌入式Tomcat作为应用容器的时候才会提供。
gauge.*：HTTP请求的性能指标之一，它主要用来反映一个绝对数值。比如上面示例中的gauge.response.hello: 5，它表示上一次hello请求的延迟时间为5毫秒。
counter.*：HTTP请求的性能指标之一，它主要作为计数器来使用，记录了增加量和减少量。如上示例中counter.status.200.hello: 11，它代表了hello请求返回200状态的次数为11。
另一种描述：此处我们可以看到基本的 memory ， heap ，class loading ， processor 和thread pool 信息，连同一些HTTP指标。在该实例
中，可以使用 /metrics/{name:.*} 访问单个属性。
系统内存总量（mem），单位:Kb
空闲内存数量（mem.free），单位:Kb
处理器数量（processors）
系统正常运行时间（uptime），单位:毫秒
应用上下文（就是一个应用实例）正常运行时间（instance.uptime），单位:毫秒
系统平均负载（systemload.average）
堆信息（heap，heap.committed，heap.init，heap.used），单位:Kb
线程信息（threads，thread.peak，thead.daemon）
类加载信息（classes，classes.loaded，classes.unloaded）
垃圾收集信息（gc.xxx.count, gc.xxx.time）
最大连接数（datasource.xxx.max）
最小连接数（datasource.xxx.min）
活动连接数（datasource.xxx.active）
连接池的使用情况（datasource.xxx.usage）
对于gauge.*和counter.*的统计，这里有一个特殊的内容请求star-star，它代表了对静态资源的访问。这两类度量指标非常有用，我们不仅可以使用它默认的统计指标，还可以在程序中轻松的增加自定义统计值。只需要通过注入org.springframework.boot.actuate.metrics.CounterService和org.springframework.boot.actuate.metrics.GaugeService来实现自定义的统计指标信息。
添加自定义metrics
需要将CounterService或者GaugeService注入到你的bean里面，CounterService提供了三个方法：
increment：将指定的计数器增加1。
decrement：将指定的计数器减1。
reset：复位指定的计数器。
就像这样子：
@Service
public class UserService {
@Autowired
UserMapper mapper;
@Autowired
CounterService counterService;
@Autowired
GaugeService gaugeService;
public Map<object, object>findById(String id) {
counterService.increment("services.system.userService.findById.invoked");
return mapper.findById(id);
}
}
然后在/metrics接口里面就可以看到自定义的信息了!
/metrics端点可以提供应用运行状态的完整度量指标报告，这项功能非常的实用，但是对于监控系统中的各项监控功能，它们的监控内容、数据收集频率都有所不同，如果我们每次都通过全量获取报告的方式来收集，略显粗暴。所以，我们还可以通过/metrics/{name}接口来更细粒度的获取度量信息，比如我们可以通过访问/metrics/mem.free来获取当前可用内存数量。
1.2.2.2 /health
/health：该端点在一开始的示例中我们已经使用过了，它用来获取应用的各类健康指标信息。在spring-boot-starter-actuator模块中自带实现了一些常用资源的健康指标检测器。
这些检测器都通过HealthIndicator接口实现，并且会根据依赖关系的引入实现自动化装配，比如用于检测磁盘的DiskSpaceHealthIndicator、检测DataSource连接是否可用的DataSourceHealthIndicator等。
有时候，我们可能还会用到一些Spring Boot的Starter POMs中还没有封装的产品来进行开发，
比如：当使用RocketMQ作为消息代理时，由于没有自动化配置的检测器，所以我们需要自己来实现一个用来采集健康信息的检测器。比如，我们可以在Spring Boot的应用中，为org.springframework.boot.actuate.health.HealthIndicator接口实现一个对RocketMQ的检测器类：
@Component
public classRocketMQHealthIndicator implements HealthIndicator {
@Override
public Health health() {
int errorCode = check();
if (errorCode != 0) {
returnHealth.down().withDetail("Error Code", errorCode).build();
}
return Health.up().build();
}
private int check() {
// 对监控对象的检测操作
}
}
通过重写health()函数来实现健康检查，返回的Heath对象中，共有两项内容，一个是状态信息，除了该示例中的UP与DOWN之外，还有UNKNOWN和OUT_OF_SERVICE，可以根据需要来实现返回；
还有一个详细信息，采用Map的方式存储，在这里通过withDetail函数，注入了一个Error Code信息，我们也可以填入一下其他信息，比如，检测对象的IP地址、端口等。重新启动应用，并访问/health接口，我们在返回的JSON字符串中，将会包含了如下信息：
"rocketMQ": {
"status": "UP"
}
自定义health
· 下面的HealthIndicators会被Spring Boot自动配置
名称 |
描述 |
CassandraHealthIndicator |
检查Cassandra是否可用 |
DiskSpaceHealthIndicator |
检查磁盘空间是否不足 |
DataSourceHealthIndicator |
检查能否从DataSource获取链接 |
ElasticsearchHealthIndicator |
检查Elasticsearch cluste是否可用 |
JmsHealthIndicator |
检查JMS broker是否可用 |
MailHealthIndicator |
检查mail server是否可用 |
MongoHealthIndicator |
检查Mongo database是否可用 |
RabbitHealthIndicator |
检查Rabbit server是否可用 |
RedisHealthIndicator |
检查Redis server是否可用 |
SolrHealthIndicator |
检查Solr server是否可用 |
我们可以通过实现
HealthIndicator接口，编写自己的/health方法逻辑。也可以增加自定义监控方法。
想自定义健康信息，可以注册实现了HealthIndicator接口的Spring beans。你需要提供一个health()方法的实现，并返回一个Health响应。Health响应需要包含一个status和可选的用于展示的详情。
importorg.springframework.boot.actuate.health.Health;
importorg.springframework.boot.actuate.health.HealthIndicator;
importorg.springframework.stereotype.Component;
@Component
public class MyHealthIndicatorimplements HealthIndicator {
@Override
public Health health() {
int errorCode = check(); // performsome specific health check
if (errorCode != 0) {
returnHealth.down().withDetail("Error Code", errorCode).build();
}
return Health.up().build();
}
}
1.2.2.3 /dump
/dump：该端点用来暴露程序运行中的线程信息。它使用java.lang.management.ThreadMXBean的dumpAllThreads方法来返回所有含有同步信息的活动线程详情。
1.2.2.4 /trace
/trace：该端点用来返回基本的HTTP跟踪信息。默认情况下，跟踪信息的存储采用org.springframework.boot.actuate.trace.InMemoryTraceRepository实现的内存方式，始终保留最近的100条请求记录。它记录的内容格式如下：
1.2.3 操作控制类
仔细的读者可能会发现，我们在“初识Actuator”时运行示例的控制台中输出的所有监控端点，已经在介绍应用配置类端点和度量指标类端点时都说明完了。那么还有哪些是操作控制类端点呢？实际上，由于之前介绍的所有端点都是用来反映应用自身的属性或是运行中的状态，相对于操作控制类端点没有那么敏感，所以他们默认都是启用的。而操作控制类端点拥有更强大的控制能力，如果要使用它们的话，需要通过属性来配置开启。
在原生端点中，只提供了一个用来关闭应用的端点：/shutdown。我们可以通过如下配置开启它：
endpoints.shutdown.enabled=true
在配置了上述属性之后，只需要访问该应用的/shutdown端点就能实现关闭该应用的远程操作。由于开放关闭应用的操作本身是一件非常危险的事，所以真正在线上使用的时候，我们需要对其加入一定的保护机制，比如：定制Actuator的端点路径、整合SpringSecurity进行安全校验等。
1.2.4 配置文件属性介绍
地址和端口的配置
management.port：指定访问这些监控方法的端口，与逻辑接口端口分离。如果不想将这些暴露在http中，可以设置management.port = -1management.address：指定地址，比如只能通过本机监控，可以设置 management.address = 127.0.0.1
敏感信息访问限制
根据上面表格，鉴权为false的，表示不敏感，可以随意访问，否则就是做了一些保护，不能随意访问。
endpoints.mappings.sensitive=false
解决方案：关闭spring security认证！
这样需要对每一个都设置，比较麻烦。敏感方法默认是需要用户拥有ACTUATOR角色，因此，也可以设置关闭安全限制：
management.security.enabled=false
或者配合Spring Security做细粒度控制。
