1 為什么要使用Prometheus

1.1 背景

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

1.2 當前系統(tǒng)存在的問題

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

2 Prometheus簡介

圖片

2.1 核心組成部分

2.1.1 Prometheus server

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

2.1.2 Exporter

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

2.1.3 Alertmanager

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

2.1.4 Service Discovery

• 服務發(fā)現功能，動態(tài)發(fā)現待監(jiān)控的Target，完成監(jiān)控配置的重要組件。

2.2 四種上報類型

2.2.1 Counter

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

2.2.2 Gauge

是一個可變的數值指標，用于表示某個瞬時值?？勺兇笞冃。话阌糜诒硎井斍斑B接數、溫度等持續(xù)變化指標。

2.2.3 Histogram

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

2.2.4 Summary

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

3 Prometheus如何保障業(yè)務系統(tǒng)的穩(wěn)定運行

3.1 監(jiān)控核心業(yè)務數據保證系統(tǒng)穩(wěn)定性

3.1.1 監(jiān)控回收訂單的數量

圖片

通過統(tǒng)計監(jiān)控某段時間的回收單的創(chuàng)建數量，可以做以下幾個方面的數據分析和預警：

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

3.1.2 監(jiān)控回收訂單創(chuàng)建失敗

圖片

通過監(jiān)控關鍵業(yè)務流程失敗：

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

3.2 提高故障響應和處理效率，保證系統(tǒng)穩(wěn)定性

3.2.1 監(jiān)控調用回收商接口異常

圖片

圖片

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

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

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

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

//調用外部系統(tǒng)方法
public <T, R> R execute(String priceSource, String actionCode, T bodyParam, Class<R> respsonseDataClazz) {
        try {
            //.....讀取配置，組裝請求url等邏輯
            try {
              //......發(fā)起請求
            } 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 不同監(jiān)控指標，監(jiān)控力度不同

當我們監(jiān)控不同指標時，需要根據指標的重要性，設置不同的報警規(guī)則。

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

3.4 監(jiān)控遠程調用QPS和耗時保證系統(tǒng)穩(wěn)定性

3.4.1 監(jiān)控遠程調用耗時為技術方案提供依據

圖片

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

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

3.4.2 監(jiān)控遠程調用QPS

圖片

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

3.5 監(jiān)控其它基礎依賴指標保證系統(tǒng)的穩(wěn)定性

3.5.1 監(jiān)控FGC次數

圖片

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

3.5.2 監(jiān)控數據庫連接池

圖片

通過監(jiān)控數據庫連接池相關的指標：

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

3.5.3 監(jiān)控容器指標

圖片

通過監(jiān)控容器相關指標可以防止業(yè)務系統(tǒng)因為基礎系統(tǒng)原因導致不穩(wěn)定。

例如監(jiān)控宿主機磁盤容量指標可以防止因磁盤不足，導致業(yè)務系統(tǒng)無法讀寫磁盤，比如日志無法寫入等問題。

4 總結

圖片

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

因為業(yè)務系統(tǒng)最終穩(wěn)定性就是靠異常監(jiān)控與及時預警來保證的，所以建立完善的監(jiān)控系統(tǒng)和及時預警是非常重要的。

提前預知和識別問題

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

提高故障響應和處理效率

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

優(yōu)化系統(tǒng)性能和資源利用

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

安全風險的監(jiān)測和應對

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

關于作者

黃敬乾   俠客匯JAVA開發(fā)工程師