上面咱們所介紹的應用配置類端點所提供的信息報告在應用啓動的時候都已經基本肯定了其返回內容,能夠說是一個靜態報告。而度量指標類端點提供的報告內容則是動態變化的,這些端點提供了應用程序在運行過程當中的一些快照信息,好比:內存使用狀況、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進行安全校驗等。