上一篇：spring boot 1.5.4 整合 druid（十三）

Spring Boot監控Actuator

項目：mybatis-spring-boot爲例，源碼地址：

spring-boot相關項目源碼，

碼雲地址：https://git.oschina.net/wyait/springboot1.5.4.git

github地址：https://github.com/wyait/spring-boot-1.5.4.git

1 actuator簡介

在Spring Boot的衆多StarterPOMs中有一個特殊的模塊，它不同於其他模塊那樣大多用於開發業務功能或是連接一些其他外部資源。它完全是一個用於暴露自身信息的模塊，所以很明顯，它的主要作用是用於監控與管理，它就是：spring-boot-starter-actuator。

spring-boot-starter-actuator模塊的實現對於實施微服務的中小團隊來說，可以有效地減少監控系統在採集應用指標時的開發量。當然，它也並不是萬能的，有時候我們也需要對其做一些簡單的擴展來幫助我們實現自身系統個性化的監控需求。下面，我們將詳細的介紹一些關於spring-boot-starter-actuator模塊的內容，包括它的原生提供的端點以及一些常用的擴展和配置方式。

1.1 引入依賴

在mybatis-spring-boot項目的pom文件中引入actuator依賴：

<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: [email protected]

bbb:

age: 25

hobbies: running

build:

artifact: "@project.artifactId@"

name: "@project.name@"

version: "@project.version@"

application.properties配置：

# actuator中/info信息自定義配置

info.aaa.name=wyait

[email protected]

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 cla***ocketMQHealthIndicator 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 = -1
management.address：指定地址，比如只能通過本機監控，可以設置 management.address = 127.0.0.1

敏感信息訪問限制

根據上面表格，鑑權爲false的，表示不敏感，可以隨意訪問，否則就是做了一些保護，不能隨意訪問。

endpoints.mappings.sensitive=false

解決方案：關閉spring security認證！

這樣需要對每一個都設置，比較麻煩。敏感方法默認是需要用戶擁有ACTUATOR角色，因此，也可以設置關閉安全限制：

management.security.enabled=false

或者配合Spring Security做細粒度控制。

spring-boot相關項目源碼，

碼雲地址：https://git.oschina.net/wyait/springboot1.5.4.git

github地址：https://github.com/wyait/spring-boot-1.5.4.git

spring boot系列文章：

spring boot 1.5.4 概述（一）