知己知彼,百戰不殆。- 《孫子兵法》java
爲了可以及時瞭解服務線上運行時的狀態,同時可以在服務處於異常狀態時可以進行有效的通知報警,咱們一般須要對服務進行監控管理。隨着分佈式微服務架構的流行,服務監控已是現代web後端開發體系中,很是重要的組成部分。git
一般服務監控系統包括以下幾個部分:github
數據提供方web
產生數據的終端,好比某web後端服務。spring
數據採集器數據庫
主要用來採集數據,使用push或者pull的方式,從終端收集數據json
數據存儲後端
主要將採集過來的數據以某種方式(一般存儲到數據庫)存儲起來,供數據展現分析系統使用。服務器
數據展現分析系統restful
主要是對存儲中的監控數據進行分析處理,並提供報警等功能。
對於web後端開發人員,在開發服務時,就應考慮到服務監控的問題。咱們能夠採用比較流行的服務監控系統,幫助咱們快速搭建服務監控平臺。通常來講服務監控系統會集成了數據採集、數據存儲、數據展現分析等功能。然後端開發人員則主要集中於數據提供方如何產生數據這部分的功能。
推薦使用telegraf(數據採集) + influxdb(數據存儲) + grafana(數據展現)組合,其中:
推方式,即數據提供方(如上圖中的服務A),主動將自身運行狀態信息(如內存使用信息、線程信息、GC信息等)進行上報。
常見有兩種方式:
一種是數據提供方將數據push到數據採集器,通常數據採集器會提供socket通道,經過tcp/udp的方式來傳輸數據。
一種是數據提供方將數據push到消息中間件(如kafka、rabbitmq等),數據採集器經過監聽消息隊列獲取數據。
這種方式能夠經過消息中間件進行對數據提供方和數據採集器進行解耦,比較適合用於大型的系統中。
拉方式,即由數據採集器進行定時輪詢從數據提供方進行拉取,要求數據提供方提供相應的接口供數據採集器獲取數據。通常來講,數據提供方能夠提供基於HTTP Restful接口。
push方式和pull方式各有其優勢,使用何種方式應該集合具體業務場景、團隊狀況等方面綜合而定。
項目 | pull | push |
---|---|---|
實時性 | 通常,取決於定時週期 | 較好 |
數據提供方 | 被動上報數據,無需感知數據採集器的存在 | 主動上報數據,須要主動感知數據採集器或消息中間件 |
數據採集器 | 主動拉取數據,須要感知數據提供方的存在 | 被動接收數據,無需感知數據提供方的存在 |
一般實現 | 短鏈接,如:http接口 | 長鏈接,如:tcp |
該服務監控模塊,對外提供基於http restful接口,供數據採集器經過pull的方式收集數據。主要參考了java spring boot框架的actuaotr模塊,提供了以下接口:
HTTP方法 | 接口地址 | 描述 | 是否需受權 |
---|---|---|---|
GET | /health | 查看應用健康指標 | 否,如需查看詳細信息,則須要受權 |
GET | /info | 查看應用信息 | 否 |
GET | /metrics | 查看應用指標信息 | 是 |
GET | /metrics/{name} | 查看具體指標 | 是 |
POST | /shutdown | 關閉應用 | 是 |
該接口用於查看應用健康指標。
當未經過受權時,只能查看基本信息,例如:
{
"status": "up",
"statusCode": 1
}
複製代碼
當經過受權(http basic auth)時,能夠查看詳細信息,例如:
{
"details": {
"disk": {
"status": "up",
"details": {
"free": 930381459456,
"threshold": 0,
"total": 1127625711616
}
},
"mem": {
"status": "up",
"details": {
"free": 8645541888,
"total": 17035321344,
"used": 8389779456
}
},
....
},
"status": "up",
"statusCode": 1
}
複製代碼
本節主要介紹了後端開發中須要瞭解的服務監控相關的知識、數據採集方式以及uranus-service服務監控模塊的基本狀況。下一節咱們將重點關注health接口的實現中須要後端人員瞭解的http basic auth機制。
本文爲做者原創做品,屬於《從新學習web後端開發》專輯中的一篇,轉載時請備註做者信息及來源。本文原文地址:www.donnyzhang.com/2019/02/26/…