您好,登錄后才能下訂單哦!
這期內容當中小編將會給大家帶來有關SpringBoot健康檢查怎樣與容器配合,文章內容豐富且以專業的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
監控的重要性就不必多說了吧,不要再花功夫開會討論它的必要性了,當你線上遇到問題,就不會再懷疑監控是浪費開發成本的建設。監控讓人告別了靠“猜”來維持的救火現狀,它能夠留下證據,來支撐我們后續的分析。
作為監控的首要目標,服務的存活性,也就是它的健康狀況,成為了重中之重。SpringBoot可以通過簡單的參數,來開啟健康檢查,并能夠和主流的監控系統集成起來。
1. 監控開啟
在Spring中,是使用actuator組件,來做監控等相關操作。可以在pom中加入下面的starter:
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
對于gradle來說,加入下面這個。
dependencies { compile("org.springframework.boot:spring-boot-starter-actuator") }
訪問/actuator/health,即可獲取項目的健康狀況。
{"status":"UP"}
在application.yml文件里,加入如下的內容:
management: endpoint: health: show-details: always
再次訪問這個接口,將輸出詳細的內容。包括DB的狀態、磁盤狀態等。可以看到,最外層的status,其實是內部各個組件狀態的集合。
{ "status":"UP", "components":{ "db":{ "status":"UP", "details":{ "database":"H2", "validationQuery":"isValid()" } }, "diskSpace":{ "status":"UP", "details":{ "total":250685575168, "free":31373905920, "threshold":10485760, "exists":true } }, "ping":{ "status":"UP" } } }
2. 自定義Indicator
這些功能,是由Indicators來實現的(HealthIndicator)。比如下面這些:
DataSourceHealthIndicator
DiskSpaceHealthIndicator
CouchbaseHealthIndicator
MongoHealthIndicator
RedisHealthIndicator
CassandraHealthIndicator
如果你是用的是組件提供的starter,這些Indicator就會在/health接口進行聚合,如果你不想要監控某個組件,可以在配置中把它關閉。
management: health: mongo: enabled: false
明白了這個道理,在做一些組件的時候時候,就可以通過這種方式,來提供組件自帶的健康檢查:只需要實現HealthIndicator接口就可以了。代碼樣例如下:
@Component @Slf4j public class X implements HealthIndicator { @Override public Health health() { try { //檢查組件狀態異常信息 } catch (Exception e) { log.warn("Failed to connect to: {}", URL); return Health.down() .withDetail("error", e.getMessage()) .build(); } return Health.up().build(); } }
3. 接入監控系統
更多情況,我們是希望把業務監控的數據,使用專業的監控組件收集起來。這個在SpringBoot中,可以使用micrometer來實現。
以最流行的prometheus為例,在pom里增加下面的內容。
<dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-prometheus</artifactId> </dependency>
當然,我們也要在yaml里配置一些內容。它現在看起來長這個樣子:
management: endpoints: web: exposure: include: health,info,prometheus endpoint: health: show-details: always
這時候,訪問/actuator/prometheus,即可獲取prometheus格式的監控數據。
類似于下面這種:
jvm_memory_used_bytes{area="heap",id="PS Survivor Space",} 0.0 jvm_memory_used_bytes{area="heap",id="PS Old Gen",} 2.9444904E7 jvm_memory_used_bytes{area="heap",id="PS Eden Space",} 6.829E7 jvm_memory_used_bytes{area="nonheap",id="Metaspace",} 5.917196E7 jvm_memory_used_bytes{area="nonheap",id="Code Cache",} 1.0929088E7 jvm_memory_used_bytes{area="nonheap",id="Compressed Class Space",} 8420512.0
在prometheus的target頁面,可以看到下面的信息:
最終在Grafana里,長的更加妖艷一些。
那它都能監控一些什么東西呢?我們來看一下:
服務節點基本信息,包括內存CPU網絡IO等
JVM堆棧信息
JVM GC信息,STW信息
默認HikariCP的連接池信息
HTTP請求接口信息(最大耗時,QPS最高)
Tomcat容器監控
Logback日志打印監控(各級別條數)
...其他
可以看到,只需要暴露這么一個接口,就可以對項目中的組件,進行比較全面的掌控。
4. 與容器配合
最后一點,由于SpringBoot服務,經常會發布到一些容器中,比如docker。這個時候,就要用到probes配置(kube有相同的概念)。probes是探測的意思,用來區分Liveness和Readiness兩種狀態。
最終的配置如下:
management: health: probes: enabled: true endpoints: web: exposure: include: health,info,prometheus endpoint: health: show-details: always
這時候,我們將在瀏覽器的接口中獲取兩個分組,展示如下:
http://localhost:8080/actuator/health/liveness
http://localhost:8080/actuator/health/readiness
這兩個鏈接,前者用于判斷容器是否應該重啟;后者判斷服務是否可用,如果可用,將開始接受外部的請求。
End
對于規模比較小的SpringBoot應用來說,使用SpringBootAdmin一類的監控,就已經足夠了。但如果你的企業是集中式部署,節點多且變化頻繁,一個統一的監控建設平臺是非常必要的。
除了Prometheus,SpringBoot的Metrics還支持以下組件:
AppOptics
Atlas
Datadog
Dynatrace
Elastic
Ganglia
Graphite
Humio
Influx
JMX
KairosDB
New Relic
Prometheus
SignalFx
Simple (in-memory)
Stackdriver
StatsD
Wavefront
上述就是小編為大家分享的SpringBoot健康檢查怎樣與容器配合了,如果剛好有類似的疑惑,不妨參照上述分析進行理解。如果想知道更多相關知識,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。