本文是Choerodon 的微服務系列推文第五篇,上一篇《Choerodon 的微服務之路(四):深刻理解微服務配置中心》介紹了配置中心在微服務架構中的做用,本篇將介紹微服務監控的重要性和必要性。java
▌文章的主要內容包括:git
在前面的幾期的文章裏,介紹了在 Choerodon 的微服務架構中,系統被拆分紅多個有着獨立部署能力的業務服務,每一個服務可使用不一樣的編程語言,不一樣的存儲介質,來保持最低限度的集中式管理。github
這樣的架構決定了功能模塊的部署是分佈式的,不一樣的業務服務單獨部署運行的,運行在獨立的容器進程中,彼此之間經過網絡進行服務調用交互。一次完整的業務流程會通過不少個微服務的處理和傳遞。編程
在這種狀況下,如何監控服務的錯誤和異常,如何快速地定位和處理問題,以及如何在複雜的容器拓撲中篩選出用戶所須要的指標,是 Choerodon 在監控中面臨的首要問題。本文將會分享 Choerodon 在微服務下的監控思考,以及結合社區流行的 Spring Cloud、Kubernetes、Prometheus 等開源技術,打造的 Choerodon 的監控方案。緩存
在談到 Choerodon 的監控以前,你們須要清楚爲何須要微服務下的監控。安全
傳統的單體應用中,因爲應用部署在具體的服務器上,開發者通常會從不一樣的層級對應用進行監控。好比豬齒魚團隊經常使用的方式是將監控分紅基礎設施、系統、應用、業務和用戶端這幾層,並對每一層分別進行監控。以下圖所示。bash
而在微服務系統中,開發者對於監控的關心點是同樣的,可是視角卻發生了改變,從分層 + 機器的視角轉化爲以服務爲中心的視角。在 Choerodon 中,傳統的分層已經不太適用。服務是部署在 k8s 的 pod 中,而不是直接部署在服務器上。團隊除了對服務器的監控以外,還須要考慮到 k8s 中容器的監控。一樣,因爲一個業務流程多是經過一系列的業務服務而實現的,如何追蹤業務流的處理也一樣相當重要。服務器
因此在微服務中,你們一樣離不開監控,有效的監控可以幫開發者快速的定位故障,保護系統健康的運行。微信
在 Choerodon 中,將系統的使用人員分爲應用的管理人員,開發人員,運維人員。而不一樣的人員在平臺中所關心的問題則分別不一樣。網絡
除了這些之外,還須要監控到以下的一些信息:
簡而概之,對於 Choerodon 而言,開發者將監控聚焦在指標監控,調用監控和日誌監控。
在開源社區中,有不少對監控的解決方案,好比指標監控有 Prometheus,鏈路監控有 zipkin、pinpoint,skywalking,日誌則有 elk。
Choerodon 具備多集羣多環境管理能力,Choerodon 爲須要監控的集羣配置監控組件,並與Choerodon 所在集羣的監控組件互通以及過濾多餘數據,能夠最大限度地減小多集羣非同一局域網的外網帶寬需求。在多集羣環境中仍然能夠感知所管理應用的運行狀態和配置預警信息。
Spring Boot 的執行器包含一系列的度量指標(Metrics)接口。當你請求 metrics
端點,你可能會看到相似如下的響應:
{
"counter.status.200.root": 20,
"counter.status.200.metrics": 3,
"counter.status.200.star-star": 5,
"counter.status.401.root": 4,
"gauge.response.star-star": 6,
"gauge.response.root": 2,
"gauge.response.metrics": 3,
"classes": 5808,
"classes.loaded": 5808,
"classes.unloaded": 0,
"heap": 3728384,
"heap.committed": 986624,
"heap.init": 262144,
"heap.used": 52765,
"nonheap": 0,
"nonheap.committed": 77568,
"nonheap.init": 2496,
"nonheap.used": 75826,
"mem": 986624,
"mem.free": 933858,
"processors": 8,
"threads": 15,
"threads.daemon": 11,
"threads.peak": 15,
"threads.totalStarted": 42,
"uptime": 494836,
"instance.uptime": 489782,
"datasource.primary.active": 5,
"datasource.primary.usage": 0.25
}
複製代碼
這些系統指標具體含義以下:
有了這些指標,咱們只須要作簡單的修改,就可使這些指標被 Prometheus 所監測到。Prometheus 是一套開源的系統監控報警框架。默認狀況下 Prometheus 暴露的metrics endpoint爲/prometheus。
在項目的pom.xml文件中添加依賴,該依賴包含了 micrometer 和 prometheus 的依賴,並對監控的指標作了擴充。
<dependency>
<groupId>io.choerodon</groupId>
<artifactId>choerodon-starter-hitoa</artifactId>
<version>${choerodon.starters.version}</version>
</dependency>
複製代碼
Prometheus提供了4中不一樣的Metrics
類型:Counter
,Gauge
,Histogram
,Summary
。經過Gauge,Choerodon對程序的線程指標進行了擴充,添加了 NEW
, RUNNABLE
,BLOCKED
,WAITING
,TIMED_WAITING
,TERMINATED
這幾種類型,具體代碼以下。
@Override
public void bindTo(MeterRegistry registry) {
Gauge.builder("jvm.thread.NEW.sum", threadStateBean, ThreadStateBean::getThreadStatusNEWCount)
.tags(tags)
.description("thread state NEW count")
.register(registry);
Gauge.builder("jvm.thread.RUNNABLE.sum", threadStateBean, ThreadStateBean::getThreadStatusRUNNABLECount)
.tags(tags)
.description("thread state RUNNABLE count")
.register(registry);
Gauge.builder("jvm.thread.BLOCKED.sum", threadStateBean, ThreadStateBean::getThreadStatusBLOCKEDCount)
.tags(tags)
.description("thread state BLOCKED count")
.register(registry);
Gauge.builder("jvm.thread.WAITING.sum", threadStateBean, ThreadStateBean::getThreadStatusWAITINGCount)
.tags(tags)
.description("thread state WAITING count")
.register(registry);
Gauge.builder("jvm.thread.TIMEDWAITING.sum", threadStateBean, ThreadStateBean::getThreadStatusTIMEDWAITINGCount)
.tags(tags)
.description("thread state TIMED_WAITING count")
.register(registry);
Gauge.builder("jvm.thread.TERMINATED.sum", threadStateBean, ThreadStateBean::getThreadStatusTERMINATEDCount)
.tags(tags)
.description("thread state TERMINATED count")
.register(registry);
}
複製代碼
在微服務架構中,一個請求可能會涉及到多個服務,請求的路徑則可能構成一個網狀的調用鏈。而若是其中的某一個節點發生異常,則整個鏈條均可能受到影響。
針對這種狀況,團隊須要有一款調用鏈監控的工具,來支撐系統監控分佈式的請求追蹤。目前開源社區中有一些工具:Zipkin、Pinpoint、SkyWalking。Choerodon 使用的是 SkyWalking,它是一款國產的 APM 工具,包括了分佈式追蹤、性能指標分析、應用和服務依賴分析等。
Skywalking 包含 Agent
和 Collecter,具體的部署和原理在這裏不在作具體的介紹,Choerodon 的服務在每一個服務的 DockerFile
中,添加了對 Skywalking Agent
的支持。具體以下:
FROM registry.cn-hangzhou.aliyuncs.com/choerodon-tools/javabase:0.7.1
COPY app.jar /iam-service.jar
ENTRYPOINT exec java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap $JAVA_OPTS $SKYWALKING_OPTS -jar /iam-service.jar
複製代碼
部署時經過配置容器的環境變量 SKYWALKING_OPTS 來實現客戶端的配置。
日誌是程序在運行中產生的遵循必定格式(一般包含時間戳)的文本數據,一般由Choerodon的服務生成,輸出到不一樣的文件中,通常會有系統日誌、應用日誌、安全日誌等等。這些日誌分散地存儲在不一樣的容器、機器中。當開發者在排查故障的時候,日誌會幫助他們快速地定位到故障的緣由。
Choerodon 採用了業界通用的日誌數據管理解決方案,主要包括elasticsearch
、fluent-bit
、fluentd
和 Kibana
。對於日誌的採集分爲以下幾個步驟。
經過端對端可視化的日誌集中管理,給開發團隊帶來以下的一些好處:
回顧一下這篇文章,介紹了微服務監控的重要性和必要性,以及 Choerodon 是如何應對指標監控,調用監控和日誌監控這三種監控的。微服務架構下的服務規模大,系統相對複雜,也使得衆多開發者成爲了微服務的受害者。如何作好微服務下的監控,保障系統健康地運行,咱們仍有許多須要繼續努力的。
更多關於微服務系列的文章,點擊藍字便可閱讀 ▼
Choerodon豬齒魚做爲開源多雲應用平臺,是基於Kubernetes的容器編排和管理能力,整合DevOps工具鏈、微服務和移動應用框架,來幫助企業實現敏捷化的應用交付和自動化的運營管理,同時提供IoT、支付、數據、智能洞察、企業應用市場等業務組件,致力幫助企業聚焦於業務,加速數字化轉型。
你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性,以及參與社區貢獻:
歡迎加入Choerodon豬齒魚社區,共同爲企業數字化服務打造一個開放的生態平臺。