1 為什么要使用Prometheus

1.1 背景

• 回收系統本質做的是服務平臺。對外交互多，例如與渠道商、回收商的接口交互。因此與回收商接口的交互情況需要記錄。
• 回收系統的內部是通過大量MQ異步驅動運行的，復雜性很高。某一個MQ執行異常很容易引起流程中斷。因此記錄MQ的消費情況也很重要。

1.2 當前系統存在的問題

• 主動發現問題的能力不足。歷史接入了一些企微通知，但數量不足，場景少，覆蓋面窄。針對一些發生率不是很高的場景，很容易漏掉。系統需要實時掌握運行狀態，減少問題響應時間。
• 單純使用企微通知報警，雖然也可以對關鍵場景進行提示，但維度單一，缺少圖形不直觀。報警之前不成體系，沒有聯系，不能直觀的展示業務的執行情況。并且報警數量稍微一多，容易引起消息轟炸，丟失關鍵信息。
• 排查問題時缺少輔助工具，耗時長。

2 Prometheus簡介

圖片

2.1 核心組成部分

2.1.1 Prometheus server

• 核心組件，負責抓取、存儲和查詢指標數據，提供API以供訪問。
• Prometheus Server本身就是一個時序數據庫，將采集到的監控數據按照時間序列的方式存儲在本地磁盤當中。
• 內置的UI界面，通過這個UI可以直接通過PromQL實現數據的查詢以及可視化。

2.1.2 Exporter

• Prometheus插件或獨立組件，負責抓取指定服務或系統的性能指標數據。
• Prometheus原理是通過 HTTP 協議周期性抓取被監控組件的狀態，輸出這些被監控的組件的 Http 接口為 Exporter。
• Exporter將監控數據采集的端點通過HTTP服務的形式暴露給Prometheus Server，將其公開為HTTP端點或指定的格式。
• Prometheus server通過輪詢或指定的抓取器從Exporter提供的Endpoint端點中提取數據。

2.1.3 Alertmanager

• 在Prometheus Server中支持基于PromQL創建告警規則，如果滿足PromQL定義的規則，就會產生一條告警。
• Prometheus告警管理器組件，負責管理告警規則、通知和報警策略的設置，提供第一類和第二類警報的分類管理服務PushGateway。
• Prometheus數據采集基于Pull模型進行設計，在網絡環境必須要讓Prometheus Server能夠直接與Exporter進行通信。
• 當這種網絡需求無法直接滿足時，就可以利用PushGateway來進行中轉。
• 通過PushGateway將內部網絡的監控數據主動Push到Gateway當中。
• Prometheus Server則可以采用同樣Pull的方式從PushGateway中獲取到監控數據

2.1.4 Service Discovery

• 服務發現功能，動態發現待監控的Target，完成監控配置的重要組件。

2.2 四種上報類型

2.2.1 Counter

遞增的整數型指標，用于表示累計數量。只能增加，不能減少，一般用于統計請求次數、錯誤次數等場景。

2.2.2 Gauge

是一個可變的數值指標，用于表示某個瞬時值。可變大變小，一般用于表示當前連接數、溫度等持續變化指標。

2.2.3 Histogram

可以將事件按照不同的桶進行分組，用來觀察指標在各個不同區間范圍的分布情況，一般用于分析請求延遲，操作響應時間。

2.2.4 Summary

與Histogram類似，區別在于Histogram存儲的是數據，Summary直接存儲的就是百分位，本質上并沒有什么區別，通過Histogram也可以計算出百分位。

3 Prometheus如何保障業務系統的穩定運行

3.1 監控核心業務數據保證系統穩定性

3.1.1 監控回收訂單的數量

圖片

通過統計監控某段時間的回收單的創建數量，可以做以下幾個方面的數據分析和預警：

• 分析需求的有效性與重要性。以接入 9906001 渠道為例，投入人力與時間資源多，訂單卻極少，未體現價值，若長期如此，該需求低效或無效。而 9902001 渠道訂單量很多，說明渠道很重要，進行相關業務開發時需確保升級可靠性。
• 進行數據對比，9902001 渠道持續擁有高訂單量，與訂單量極低的渠道形成鮮明對比，為業務和產品指明不同運營策略方向。
• 設立訂單突增或掉零預警機制。如在雙 11、618 大促時提前介入監控系統穩定性。但是對于渠道商回收業務，因外部活動或新機型發售不可預知，訂單突增時預警，技術介入查看系統狀態確保穩定；渠道長時間無訂單也預警排查系統問題。

3.1.2 監控回收訂單創建失敗

圖片

通過監控關鍵業務流程失敗：

1. 可快速發現線上問題并及時排查解決，避免影響用戶體驗與業務運行，不再像以往等業務反饋才行動。
2. 業務需求上線時觀察對核心業務的影響，若回收單創建大量失敗，可能上線有問題，需排查是否回滾。

3.2 提高故障響應和處理效率，保證系統穩定性

3.2.1 監控調用回收商接口異常

圖片

圖片

業務系統與外部系統交互的過程中，失敗的原因是多種多樣的。有可能是網絡問題，外部接口的問題或者業務系統代碼邏輯的問題。

監控回收商接口異常及其原因，可快速定位問題根源。若因外部系統所致，及時反饋給外部系統；若為業務系統代碼問題，可依據簡要問題信息在日志中搜索報錯，借助詳細日志定位解決問題。

注：在進行指標監控時，防止監控的指標的tag過多，轉轉這邊限制為500。

例如在監控調用回收商接口異常原因指標時，將異常進行歸類，從而保證了tag不會過多。

//調用外部系統方法
public <T, R> R execute(String priceSource, String actionCode, T bodyParam, Class<R> respsonseDataClazz) {
        try {
            //.....讀取配置，組裝請求url等邏輯
            try {
              //......發起請求
            } catch (ResourceAccessException e) {
                //捕獲超時異常，拋出重試異常
                log.error("報價方接口請求超時或異常，將重試,exception:{}", ExceptionUtils.getStackTrace(e));
                throw new RetryException("報價方接口請求超時或異常", e);
            }

            if (HttpStatus.OK.value() != responseEntity.getStatusCode().value()) {
                log.info("priceSourceApi接口httpCode非200,httpCode:{}", responseEntity.getStatusCode().value());
                throw new RetryException("priceSourceApi調用失敗: " + responseEntity.getStatusCode().value());
            }

            BaseResp baseResp = responseEntity.getBody();
            if (Objects.isNull(baseResp)) {
                throw new PriceSourceApiException("priceSourceApi返回值為空");
            }
           //....
            String respCode = baseResp.getCode();
            //根據code判斷是否重試
            if (!priceSourceApiAction.getSuccessCode().equals(respCode)) {
                throw new RetryException("priceSourceApi調用失敗: " + baseResp.getMsg());
            }
            //.......
            return o;
        } catch (Exception e) {
            log.error("execute Api PriceSource fail for priceSource: {}, action: {}", priceSource, actionCode, 
            throw new HunterErrorException("調用回收商接口失敗",e);
        } finally {
            // 記錄全部請求數
            long usingTime = System.currentTimeMillis() - startTime;
            String metricsName = PrometheusMetricsEnum.OUTER_RECYCLER_HANDLE_INTER2_TOTAL.getName() + priceSource;
            MetricsMonitor.recordOne(metricsName, actionCode, usingTime);
        }
    }

3.3 不同監控指標，監控力度不同

當我們監控不同指標時，需要根據指標的重要性，設置不同的報警規則。

例如創建回收單失敗和調用回收商接口報錯的指標的重要性不同。對于創建回收單業務來說，影響的是外部渠道調用接口可靠性的，不能有過多報錯，且接口是否重試也是由外部渠道控制的，因此我們要保證接口的可靠性，有問題要及時處理解決。但是對于調用回收商的接口，業務系統有重試機制，調用失敗會自行重試，且對于外部渠道是無感知的，不影響外部渠道調用業務接口的可靠性。所以對于創建回收單失敗指標來說，我們報警監控配置是一分鐘內有一個失敗就會發送報警通知。但是對于調用回收商接口報錯的指標，我們報警配置是十分鐘內有五次錯誤才會發送報警通知。

3.4 監控遠程調用QPS和耗時保證系統穩定性

3.4.1 監控遠程調用耗時為技術方案提供依據

圖片

SCF框架是轉轉自己開發的遠程調用框架，類似于Dubbo。

設計需求實現時需調用不同業務系統接口，可串行或并行調用。比如在做創建回收單業務時，需要讀取用戶信息，讀取渠道信息，還有相關的配置信息。我們通過提前查看調用具體接口的大概耗時，預估到了串行調用這些接口會有超時的風險，因此在讀取這些配置信息時，我們采用異步調用，減少創建回收單業務接口的耗時，保證接口不會超時。

3.4.2 監控遠程調用QPS

圖片

在遠程調用中通常用限流防業務系統因過多調用崩潰。但是若都是正常流量，則應考慮增機、調整限流規則確保其他業務系統穩定。所以這時監控的作用就體現出來了，當QPS達到了限流的百分之八十，發送一個告警，及時通知技術去觀察判斷是不是有別的業務系統，因為業務突增，導致調用增加，進而及時調整限流規則，來滿足別的業務系統的調用。

3.5 監控其它基礎依賴指標保證系統的穩定性

3.5.1 監控FGC次數

圖片

通過監控FGC次數，如果頻繁發生FGC，說明系統現在處于不正常的狀態：1.有可能存在內存泄露。2.有可能JVM內存配置的過小，不滿足業務系統需要。通過這方面的監控及時排查FGC頻繁發生的原因，減少FGC發生的次數也可以提升系統的穩定性。

3.5.2 監控數據庫連接池

圖片

通過監控數據庫連接池相關的指標：

• 通過觀察事務提交耗時指標，可以清晰的觀察到是否存在大量打大事務，影響數據庫連接池的連接和釋放。
• 通過觀察事務回滾次數指標，可以判斷系統中是否存在大量的業務異常，導致事務回滾。
• 通過觀察事務提交次數，可以為連接池配置連接數量提供一定的依賴數據。

3.5.3 監控容器指標

圖片

通過監控容器相關指標可以防止業務系統因為基礎系統原因導致不穩定。

例如監控宿主機磁盤容量指標可以防止因磁盤不足，導致業務系統無法讀寫磁盤，比如日志無法寫入等問題。

4 總結

圖片

轉轉除了上面的一些舉例還有很多方向的監控：虛擬機指標監控、線程池監控、MQ監控、Codis連接池監控等等。

因為業務系統最終穩定性就是靠異常監控與及時預警來保證的，所以建立完善的監控系統和及時預警是非常重要的。

提前預知和識別問題

• 監控和告警系統可以幫助我們實時獲取系統的運行數據和指標。
• 通過對關鍵指標的監控和分析，可以提前預知系統可能出現的問題，如性能下降、異常錯誤、服務不可用等。
• 通過告警及時發現問題，可以提高問題識別的速度和準確性，便于及時采取相應的措施來修復問題。

提高故障響應和處理效率

• 及時發現和處理故障可以減少系統的停機時間，避免影響用戶體驗和業務運行。
• 配置監控和告警系統可以幫助運維團隊更快速地響應和解決問題，減少故障的恢復時間，減少業務損失。

優化系統性能和資源利用

• 監控和告警系統可以實時監測系統的性能和資源利用情況，如CPU、內存、磁盤、網絡等。
• 通過對系統的性能指標進行監控和分析，可以幫助我們了解系統的負載情況和瓶頸。
• 及時進行性能優化和資源擴展，以提高系統的穩定性和可擴展性。

安全風險的監測和應對

• 監控和告警系統還可以對系統的安全風險進行實時監測和預警。通過對異常訪問、漏洞攻擊、異常登錄等進行監控和分析
• 可以幫助及時發現和應對潛在的安全風險，并保護系統和數據的安全。

關于作者

黃敬乾   俠客匯JAVA開發工程師