實用技巧:排查數據異常/數據波動問題,該如何下手?

来源:https://www.cnblogs.com/xl-xueling/p/18130609
-Advertisement-
Play Games

本文深入探討了Kubernetes Pod配置的實戰技巧和常見易錯點。 關註【TechLeadCloud】,分享互聯網架構、雲服務技術的全維度知識。作者擁有10+年互聯網服務架構、AI產品研發經驗、團隊管理經驗,同濟本復旦碩,復旦機器人智能實驗室成員,阿裡雲認證的資深架構師,項目管理專業人士,上億營 ...


前言

在我做開發的這些年,讓我很頭痛的一類問題,不是線上故障,而是數據異常,不知道有沒有程式員跟我感同身受。

大多數的服務故障都有較為直觀的異常日誌,再結合產品表象,相對排查起來還有跡可循,但數據異常的原因就太多了,很多時候連報錯日誌都沒有,排查起來簡直無從下手。

在一個微服務、分散式、前後端分離等概念熱火朝天的年代,雖然給身為程式員的我們帶來了很大便利,但也同時帶來了很多苦惱。分工更加明確,減少了很多工作量,我們大部分的時間和精力專註於自己所負責的模塊即可。

本來一切都很美好,但是在排查一些數據異常類問題時卻遇到了麻煩!

業務的底層邏輯錯綜複雜,一個介面的響應需要經過三四個微服務的協同處理這非常正常,甚至涉及七八個以上的微服務都不罕見。
不少服務是不同的人員,甚至是不同部門的人員在維護,這給排查帶來很多不便,那該如何快速定位問題呢?

行業目前的現狀

如果自身服務有異常日誌,一眼就能確認問題還好說,但如果自身服務一切正常,那排查起來可得費老大勁了。

這種數據異常問題,往往是突然發生,打你一個措手不及。很多時候我們本來就有正常的開發排期,時間也比較緊張,突然再穿插一個數據異常排查的事情進來,這就很讓我們氣憤。
當被產品經理或者部門主管找上門來,總不能跟他說:我的服務沒問題,哪裡的問題我也不知道!

這種問題雖然讓我們頭疼,但是得認真對待,因為以我的經驗來看,稍一疏忽說不定就落下一個業務不熟悉、定位問題能力差的名聲甚至還可能替人背鍋。

冷靜下來分析,既然是數據異常類的問題,不少朋友可能會說,還能咋辦,跑數唄!

跑數,說起來簡單做起來可不簡單,目前各個企業或業務團隊的現狀大概分為幾種情況:

  • 1、已經將相關日誌格式化後存儲到數據平臺,可以寫SQL查詢(困難指數:兩顆星);
  • 2、日誌沒有格式化,而是落到了磁碟、HDFS或者其他存儲引擎上,需要寫專門的Java、Python或MR或Spark等的任務去解析原始日誌然後再跑數,如果日誌量大一點、日誌格式再混亂一點,工作量可不小(困難指數:五顆星);
  • 3、可能連必要的日誌都忘了列印(困難指數:非人力所能及,跑路吧!);

說到這,有些小伙伴覺得:那明白了,知道怎麼辦了,把日誌格式化都寫到數據中台里,有問題就寫SQL查!!!

我想說的是:too young,too simple!

使用數據中台排查此類問題的弊端

使用數據中台寫SQL查詢格式化後的日誌,困難指數是兩顆星,但問題是,這有個前提:得先把日誌格式化後寫到中台里!關鍵問題是這步操作並不簡單。

企業自建或購買的第三方數據中臺大多是OLAP類的數倉/數據湖的解決方案,當然有些企業比較有錢,喜歡用ES來搞。

日誌是非結構化的數據,是比較混亂的一種數據結構。一般來說企業的日誌數據有兩種:一是前端(App/H5/PC)上報的埋點日誌,二是後端業務系統自己輸出的日誌。前端上報的埋點日誌還較好一點,起碼有用戶信息、設備信息、埋點類型等固定參數,此外再加上不同埋點類型對應的自定義參數。

如果數據異常問題只涉及前端埋點日誌,企業也已經搭建好較為完善的埋點日誌存儲和查詢平臺、並且每種埋點類型的日誌都已將關鍵欄位提取後格式化存儲了,那這種情況比較理想基本只要寫SQL就行了,寫SQL看數雖然不夠清晰直觀,但還是可以湊合用的。不過如果企業的數據中台搭建不夠完善或者埋點定義比較混亂的話,那就得寫代碼處理了。

但前端埋點只涉及用戶行為側數據,而很多業務邏輯處理細節的日誌數據就不包含了,這時候就需要基於後端日誌來實現。大家都知道通過後端日誌排查一些異常信息、鏈路追蹤等問題相對容易,
但是後端日誌沒有任何規範可言,後端日誌類型遠遠超過前端日誌,而且會隨時添加、隨時刪除、隨時變更格式。如果想基於後端日誌進行統計分析絕對是一段讓人痛苦不堪、叫苦連天的經歷,如果想把混亂的後端日誌寫入數據平臺再進行統計分析難度超乎尋常的大。

再者來說,從我過往的經驗和教訓來看,很多時候一份數據並不可靠,關鍵數據是需要交叉驗證的!

我列舉兩個小例子,你就明白了:

1、服務A調用服務B的介面,數據監控應該加在服務A側還是服務B側?
或者服務A與服務B通過消息中間件通信,A將數據寫入消息服務,B從消息中間件中讀取數據,統計監控應該加在服務A側還是服務B側?
準確來說,如果業務比較重要的話,應該兩端都加,否則即使對方拿出錯誤的統計數據來質疑你的時候,你可能都難以辯解!

2、App端有個重要的表單提交功能,如果要統計用戶表單提交量,應該用前端埋點的上報量還是後端介面的請求量還是DB的寫入量?
有些朋友可能會覺得:這還用說嗎,業務數據肯定是以DB寫入為準啊。沒錯,不過如果從服務監控和排查問題的角度來看,如果業務較為重要,三個階段的數據監控應該都加,也就是表單埋點上報階段、後端介面被請求時以及後端將表單數據寫入DB時!

完善的服務監控體系,在於數據指標之間的互相印證!

說到這裡,數據中台的弊端就已經較為明顯,我們可以總結一下大概有幾點:

  • 數據中台接入困難;
  • 為了應對查詢,數據中台內部需要維護龐大量級的日誌數據(前端日誌 + 後端日誌),給企業帶來很大的伺服器費用和維護費用;
  • 使用數據中台需要隨時應對日誌的格式、參數變化可能會導致數據中台內欄位的變化;
  • 日誌的結構和參數發生變化後,數據中台內部往往會同時存在相同日誌類型,但格式不同的多種數據,這很可能導致統計分析的錯誤;
  • 數據中台很難實現對指定日誌類型快速的上下線;
  • 使用數據數據中台查詢統計數據,需要寫大量的SQL,很浪費時間而且數據展示不夠直觀;

數據中台臃腫笨拙,即便是一線大廠擁有充足的資金和人力也沒有可能使用數據中台建立起較為全面的服務監控體系。

所以,不管是寫程式還是用數據中台排查此類問題並不能算是一個十分高明的方案,或者說僅僅只是一個還湊合的方案!

我所推薦的方案

現在的產品邏輯、業務邏輯越來越複雜,而數據異常很多時候會涉及企業安身立命的根本,畢竟數據異常很可能會帶來直接或間接的經濟損失和用戶流失!

那還有沒有其他更便捷、更清晰、更立體、更周全的解決方案了呢?

有,當然有,這就是我接下來要鄭重向大家推薦的:開源通用型流式大數據統計系統XL-LightHouse。

絕大多數朋友應該還沒有聽說過它,甚至連通用型流式數據統計都沒有聽說過,那它相比業內目前使用的方案究竟有什麼優勢呢?

我一直偏執的認為:解決此類問題通用型流式數據統計是唯一接近完美的解決方案!

用一句話評價它在排查數據異常類問題的使用體驗,那就是:簡單、簡單、你未曾體驗過的簡單!

XL-LightHouse與眾不同的特點

  • 1、輕量級

XL-LightHouse以通用型流式數據統計為切入點,雖然它是一款大數據類系統,但從使用層面上來說,其實是一個非常輕量級,幾乎沒有任何使用門檻的系統。你可以一鍵就將它部署到伺服器上,至於如何使用,那就更簡單了。

只要在Web頁面配置相應的元數據結構、創建統計項,再調用它的API將欄位數據上報上來,然後就可以在Web端查看統計結果了。

它的整個使用流程簡單到幾乎不用看文檔就可以完成,相比OLAP那一套笨拙、複雜的接入流程,它簡直像張白紙一目瞭然。如果你部署完成後5分鐘還沒有弄明白該如何使用,都會讓我覺得這個項目還有極大的優化空間!

相比於OLAP類系統它不支持原始數據明細查詢、不支持多維度欄位隨意組合的即席查詢。
這與它自身定位有關,XL-LightHouse是流式大數據統計系統,它不希望被任何可有可無的功能影響了它的輕便性和它在流式統計方面彪悍的計算性能,它不希望像OLAP那類系統一樣,追求功能的完善,卻把自己搞的笨重不堪,用戶使用起來也感覺非常不便。
XL-LightHouse竭盡所能期望為用戶打造信手拈來的愉悅感和輕鬆駕馭的暢快感。

  • 2、功能強大

XL-Lighthouse在流式統計、數據監控等方面的功能可謂十分強大。

  • XL-LightHouse目前已涵蓋了各種流式數據統計場景,包括count、sum、max、min、avg、distinct、topN/lastN等多種運算,支持多維度計算,支持分鐘級、小時級、天級多個時間粒度的統計,支持自定義統計周期的配置。
  • XL-LightHouse內置豐富的轉化類函數、支持表達式解析,可以滿足各種複雜的條件篩選和邏輯判斷。
  • XL-LightHouse提供了完善的可視化查詢功能,對外提供API查詢介面,此外還包括數據指標管理、許可權管理、統計限流等多種功能。
  • XL-LightHouse支持時序性數據的存儲和查詢。

元數據欄位可以根據需要隨意指定,一份元數據下有多少統計項可以隨意指定,統計任務上線或下線可以隨意指定,
它的架構設計更加貼合流式統計的運算特點,並對每一種運算單元都進行了很多層面的性能優化,支持超大數據量和超高併發,在它的功能範圍內你幾乎可以隨心所欲的添加和管理你所需要的統計指標。

如何使用XL-LightHouse排查數據異常類問題?

歸根到底是一句話:在任何你有需要的地方加上流式統計。

比如:

  • 可以用它統計一個if/else的分支,每分鐘各被執行多少次;
  • 可以用它統計一個訂單介面,每5分鐘有多少人下單和下單總金額;
  • 微服務A同時調用微服務B、C、D,可以用它統計每天每個微服務各個介面調用量、異常量和耗時情況,甚至每種錯誤碼的返回次數;
  • 可以用它統計,前端上報的數據中某個參數為空的請求占比;
  • 可以用它統計一個Feed推薦介面,每小時召回帖子的數量、每種召回模型、ABTest策略、不同的地區、不同的內容分類召回帖子的數量;
    — 可以用它監控一個KV存儲服務,每天數據寫入量和每天數據查詢量,甚至每個key首碼的寫入量和查詢量;
    — 可以用它監控APP的啟動耗時,彈窗廣告的彈出次數;
  • 可以用它統計APP內某個廣告的下發量、點擊量、點擊UV和點擊率;
  • 可以用它監控一個新聞資訊類APP的內容池每小時各個渠道的新增帖子量;
  • 可以用它統計一個社交類APP每天聊天消息、聊天表情、紅包的發送量;
  • 可以用它統計每天銷售額top100的商戶列表;
  • 可以用它統計任意細粒度、任意維度的數據;
  • ......

總之,在它的功能範圍之內,你可以根據自己的實際需求隨心所欲的創建統計指標!

  • 示例1:依賴服務介面調用量監控

假設場景:微服務A中要調用其他的服務,我們需要監控各依賴服務的介面調用量、異常量和耗時情況數據。
(有些朋友可能會覺得公司的RPC服務針對各介面的互相調用情況監控數據都已經具備了,為啥還要再監控,我這裡只是舉個例子,其實本質不一樣,公司RPC服務所提供的數據都是定死的一些監控指標,而用XL-LightHouse具有非常強大的靈活性,可以根據自身需求定製!)
XL-LightHouse

  • 示例2:各終端訂單量數據監控

假設場景:交易服務需要監控不同來源下單量的數據。
XL-LightHouse

  • 模擬數據接入
public class Testing {

    static {
        try{
            //配置RPC服務地址
            LightHouse.init("10.206.6.39:4061,10.206.6.21:4061");
        }catch (Exception ex){
            ex.printStackTrace();
        }
    }

    @Test
    public void testStat() throws Exception {
        long t = System.currentTimeMillis();
        for(int i = 0;i<10000;i++){
            //修改統計組參數值、Token和秘鑰
            Map<String,Object> map = new HashMap<>();
            map.put("source", ThreadLocalRandom.current().nextInt(3));
            map.put("order_id",RandomID.id(3));
            double price = ThreadLocalRandom.current().nextDouble(1,9999);
            map.put("price",String.format("%.2f", price));
            LightHouse.stat("Gjd:trade_source_stat","g2BjBuC0g4euWcMzqQXAAlKFcIBPbexQNLovqK9z",map,t);
        }
        System.out.println("send ok!");
        Thread.sleep(30000);
    }
}
  • 查看結果

XL-LightHouse

擔心代碼侵入怎麼辦?

XL-LightHouse對外提供JavaSDK,如果是Java類系統可以在自己的服務中直接調用API。

有些企業的服務並不是基於Java語言開發或者本身不想在使用時有太多的代碼侵入該怎麼辦?

很簡單,只要再額外部署一套Kafka或者其他的消息組件,自身服務將相關參數數據寫入到消息組件中,然後在消費消息數據時調用xl-lighthouse的sdk就可以了,這套消息服務和消費邏輯可以企業內部共用。

結束語

線上服務監控體系可以根據實際需求陸續創建,等你將監控體系建立完備,這將使你對線上服務的駕馭能力得到空前的提升,五分鐘內定位數據異常問題絕非信口開河,每次線上數據異常都是展示你能力的絕佳機會,升職加薪在向你招手~

本文可以隨意轉載!


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 大家好,我是白夜,今天給大家聊聊面向對象的三大特征——封裝 一、包(package) 1.1、包的引入 先來看看我們之前寫的代碼結構 以上代碼存在的問題 所有類寫在一個目錄下麵,非常難管理,因為以後項目不可能只有這麼幾個類,當類數量很大的時候,就不容易管理了。 不能寫同名但是不同需求的類。 為瞭解決 ...
  • 隨著B端業務快速發展,系統愈趨複雜。我們發起了B端架構升級專項,基於B端業務的特點,從研發規範建設、B端架構基建、系統架構升級和落地保障等多方面提升了B端的架構水平 ...
  • 問題背景 訪問某個 HTTP 功能變數名稱介面,偶發性超時,原因可能多種多樣,比如 DNS 解析問題、網路質量問題、對端服務負載問題等,在客戶端沒有良好埋點的情況下,排查起來比較費勁,只能挨個方向嘗試,這裡送大家一個小工具,可以快速採樣 DNS 解析延遲,快速確認是否是 DNS 解析問題。 使用演示 運行工 ...
  • 前端 https://blog.csdn.net/m0_37613503/article/details/128961447 資料庫 1.用戶表 CREATE TABLE `x_user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varc ...
  • 1.VS上安裝Qt擴展 點擊菜單欄【擴展】->【管理擴展】,在搜索框搜索“Qt”, 點擊下載Qt Visual Studio Tools, 以2022版為例,需要關閉所有視窗才能執行安裝 關閉VS後,彈出安裝視窗,等待其安裝完成 2. 新建QT工程測試 等待安裝完成後,添加一個Qt Vertion後 ...
  • 隨著互聯網的迅猛發展,越來越多的應用場景需要進行用戶實名認證,其中手機號機主姓名核驗就是其中必不可少的一環。在電商、游戲、直播、金融等領域,用戶實名認證成為了一個重要的手段,以提高安全性和信任度。 近年來,隨著手機號的普及和使用頻率的增加,手機號的歸屬地信息也逐漸成為人們關註的焦點。手機號機主姓名核 ...
  • decltype關鍵字是C++11新標準引入的關鍵字,它和關鍵字auto的功能類似,也可以自動推導出給定表達式的類型,但它和auto的語法有些不同,這篇文章講解了decltype的使用場景以及和auto不同的地方,同時也講解了和auto結合使用的用法。 ...
  • 為了增加查詢的性能,MyBatis 提供了二級緩存架構,分為一級緩存和二級緩存。 這兩級緩存最大的區別就是:一級緩存是會話級別的,只要出了這個 SqlSession,緩存就沒用了。而二級緩存可以跨會話,多個會話可以使用相同的緩存! 一級緩存使用簡單,預設就開啟。二級緩存需要手動開啟,相對複雜,而且要 ...
一周排行
    -Advertisement-
    Play Games
  • 下麵是一個標準的IDistributedCache用例: public class SomeService(IDistributedCache cache) { public async Task<SomeInformation> GetSomeInformationAsync (string na ...
  • 這個庫提供了在啟動期間實例化已註冊的單例,而不是在首次使用它時實例化。 單例通常在首次使用時創建,這可能會導致響應傳入請求的延遲高於平時。在註冊時創建實例有助於防止第一次Request請求的SLA 以往我們要在註冊的時候實例單例可能會這樣寫: //註冊: services.AddSingleton< ...
  • 最近公司的很多項目都要改單點登錄了,不過大部分都還沒敲定,目前立刻要做的就只有一個比較老的項目 先改一個試試手,主要目標就是最短最快實現功能 首先因為要保留原登錄方式,所以頁面上的改動就是在原來登錄頁面下加一個SSO登錄入口 用超鏈接寫的入口,頁面改造後如下圖: 其中超鏈接的 href="Staff ...
  • Like運算符很好用,特別是它所提供的其中*、?這兩種通配符,在Windows文件系統和各類項目中運用非常廣泛。 但Like運算符僅在VB中支持,在C#中,如何實現呢? 以下是關於LikeString的四種實現方式,其中第四種為Regex正則表達式實現,且在.NET Standard 2.0及以上平... ...
  • 一:背景 1. 講故事 前些天有位朋友找到我,說他們的程式記憶體會偶發性暴漲,自己分析了下是非托管記憶體問題,讓我幫忙看下怎麼回事?哈哈,看到這個dump我還是非常有興趣的,居然還有這種游戲幣自助機類型的程式,下次去大玩家看看他們出幣的機器後端是不是C#寫的?由於dump是linux上的程式,剛好win ...
  • 前言 大家好,我是老馬。很高興遇到你。 我們為 java 開發者實現了 java 版本的 nginx https://github.com/houbb/nginx4j 如果你想知道 servlet 如何處理的,可以參考我的另一個項目: 手寫從零實現簡易版 tomcat minicat 手寫 ngin ...
  • 上一次的介紹,主要圍繞如何統一去捕獲異常,以及為每一種異常添加自己的Mapper實現,並且我們知道,當在ExceptionMapper中返回非200的Response,不支持application/json的響應類型,而是寫死的text/plain類型。 Filter為二方包異常手動捕獲 參考:ht ...
  • 大家好,我是R哥。 今天分享一個爽飛了的面試輔導 case: 這個杭州兄弟空窗期 1 個月+,面試了 6 家公司 0 Offer,不知道問題出在哪,難道是杭州的 IT 崩盤了麽? 報名面試輔導後,經過一個多月的輔導打磨,現在成功入職某上市公司,漲薪 30%+,955 工作制,不咋加班,還不捲。 其他 ...
  • 引入依賴 <!--Freemarker wls--> <dependency> <groupId>org.freemarker</groupId> <artifactId>freemarker</artifactId> <version>2.3.30</version> </dependency> ...
  • 你應如何運行程式 互動式命令模式 開始一個互動式會話 一般是在操作系統命令行下輸入python,且不帶任何參數 系統路徑 如果沒有設置系統的PATH環境變數來包括Python的安裝路徑,可能需要機器上Python可執行文件的完整路徑來代替python 運行的位置:代碼位置 不要輸入的內容:提示符和註 ...