上面咱们所介绍的应用配置类端点所提供的信息报告在应用启动的时候都已经基本肯定了其返回内容,能够说是一个静态报告。而度量指标类端点提供的报告内容则是动态变化的,这些端点提供了应用程序在运行过程当中的一些快照信息,好比:内存使用状况、HTTP请求统计、外部资源指标等。这些端点对于咱们构建微服务架构中的监控系统很是有帮助,因为Spring Boot应用自身实现了这些端点,因此咱们能够很方便地利用它们来收集咱们想要的信息,以制定出各类自动化策略。下面,咱们就来分别看看这些强大的端点功能。html
/metrics:该端点用来返回当前应用的各种重要度量指标,好比:内存信息、线程信息、垃圾回收信息等。java
{ "mem": 541305, "mem.free": 317864, "processors": 8, "instance.uptime": 33376471, "uptime": 33385352, "systemload.average": -1, "heap.committed": 476672, "heap.init": 262144, "heap.used": 158807, "heap": 3701248, "nonheap.committed": 65856, "nonheap.init": 2496, "nonheap.used": 64633, "nonheap": 0, "threads.peak": 22, "threads.daemon": 20, "threads.totalStarted": 26, "threads": 22, "classes": 7669, "classes.loaded": 7669, "classes.unloaded": 0, "gc.ps_scavenge.count": 7, "gc.ps_scavenge.time": 118, "gc.ps_marksweep.count": 2, "gc.ps_marksweep.time": 234, "httpsessions.max": -1, "httpsessions.active": 0, "gauge.response.beans": 55, "gauge.response.env": 10, "gauge.response.hello": 5, "gauge.response.metrics": 4, "gauge.response.configprops": 153, "gauge.response.star-star": 5, "counter.status.200.beans": 1, "counter.status.200.metrics": 3, "counter.status.200.configprops": 1, "counter.status.404.star-star": 2, "counter.status.200.hello": 11, "counter.status.200.env": 1 }
从上面的示例中,咱们看到有这些重要的度量值:算法
processors
、运行时间uptime
和instance.uptime
、系统平均负载systemload.average
。mem.*
:内存概要信息,包括分配给应用的总内存数量以及当前空闲的内存数量。这些信息来自java.lang.Runtime
。对于gauge.*
和counter.*
的统计,这里有一个特殊的内容请求star-star
,它表明了对静态资源的访问。这两类度量指标很是有用,咱们不只可使用它默认的统计指标,还能够在程序中轻松的增长自定义统计值。只须要经过注入org.springframework.boot.actuate.metrics.CounterService
和org.springframework.boot.actuate.metrics.GaugeService
来实现自定义的统计指标信息。好比:咱们能够像下面这样自定义实现对hello
接口的访问次数统计。spring
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。 @RestController public class HelloController { @Autowired private CounterService counterService; @RequestMapping("/hello") public String greet() { counterService.increment("didispace.hello.count"); return ""; } }
/metrics
端点能够提供应用运行状态的完整度量指标报告,这项功能很是的实用,可是对于监控系统中的各项监控功能,它们的监控内容、数据收集频率都有所不一样,若是咱们每次都经过全量获取报告的方式来收集,略显粗暴。因此,咱们还能够经过/metrics/{name}
接口来更细粒度的获取度量信息,好比咱们能够经过访问/metrics/mem.free
来获取当前可用内存数量。json
/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 class RocketMQHealthIndicator implements HealthIndicator { @Override public Health health() { int errorCode = check(); if (errorCode != 0) { return Health.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字符串中,将会包含了以下信息:session
"rocketMQ": { "status": "UP" }
/dump:该端点用来暴露程序运行中的线程信息。它使用java.lang.management.ThreadMXBean
的dumpAllThreads
方法来返回全部含有同步信息的活动线程详情。架构
/trace:该端点用来返回基本的HTTP跟踪信息。默认状况下,跟踪信息的存储采用org.springframework.boot.actuate.trace.InMemoryTraceRepository
实现的内存方式,始终保留最近的100条请求记录。它记录的内容格式以下:app
[ { "timestamp": 1482570022463, "info": { "method": "GET", "path": "/metrics/mem", "headers": { "request": { "host": "localhost:8881", "connection": "keep-alive", "cache-control": "no-cache", "user-agent": "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36", "postman-token": "9817ea4d-ad9d-b2fc-7685-9dff1a1bc193", "accept": "*/*", "accept-encoding": "gzip, deflate, sdch", "accept-language": "zh-CN,zh;q=0.8" }, "response": { "X-Application-Context": "hello:dev:8881", "Content-Type": "application/json;charset=UTF-8", "Transfer-Encoding": "chunked", "Date": "Sat, 24 Dec 2016 09:00:22 GMT", "status": "200" } } } }, ... ]
仔细的读者可能会发现,咱们在“初识Actuator”时运行示例的控制台中输出的全部监控端点,已经在介绍应用配置类端点和度量指标类端点时都讲解完了。那么还有哪些是操做控制类端点呢?实际上,因为以前介绍的全部端点都是用来反映应用自身的属性或是运行中的状态,相对于操做控制类端点没有那么敏感,因此他们默认都是启用的。而操做控制类端点拥有更强大的控制能力,若是要使用它们的话,须要经过属性来配置开启。ide
在原生端点中,只提供了一个用来关闭应用的端点:/shutdown
。咱们能够经过以下配置开启它:
endpoints.shutdown.enabled=true
在配置了上述属性以后,只须要访问该应用的/shutdown
端点就能实现关闭该应用的远程操做。因为开放关闭应用的操做自己是一件很是危险的事,因此真正在线上使用的时候,咱们须要对其加入必定的保护机制,好比:定制Actuator的端点路径、整合Spring Security进行安全校验等。