資訊專欄INFORMATION COLUMN
距離上次解決flink計算業(yè)務(wù)鏈相關(guān)指標(biāo)延遲問題已經(jīng)過去2個多月，當(dāng)時根據(jù)解決問題的過程編寫了<<開源組件Flink性能優(yōu)化之實時計算延遲填坑記>> 。
自從上次解決flink內(nèi)存泄漏的問題后，2個多月時間內(nèi)，在flink組件上的所有任務(wù)一直平穩(wěn)運行，但最近監(jiān)控日志采集入庫延遲的告警短信頻頻響起，表明問題來了。
最初以為是更新flink運行包的原因，于是比對版本和代碼，發(fā)現(xiàn)flink日志采集任務(wù)部分的程序沒有做任何的更改，flink環(huán)境也沒有變化，對于程序來說，如果輸出發(fā)生變化，程序和環(huán)境沒有變化，那唯一的解釋就是輸入發(fā)生了變化，日志采集數(shù)據(jù)量上升導(dǎo)致了日志延時。那就統(tǒng)計每天的日志采集數(shù)據(jù)量，但采集客戶端及服務(wù)端沒有這個處理的數(shù)據(jù)量，kafka也沒法統(tǒng)計每天的寫入量，而flink也是只能看到處理的總數(shù)據(jù)量。
統(tǒng)計不到?jīng)]關(guān)系，我們把數(shù)據(jù)量降下來不就可以看到，停一部分采集再看日志入庫還會不會延時，問題不就確定了嗎？但是經(jīng)過和應(yīng)用開發(fā)商溝通，每個日志都不能下線或停止采集。
怎么辦，優(yōu)化唄，問題是優(yōu)化哪里？首先需要先找到數(shù)據(jù)的增長對哪個環(huán)節(jié)影響最大，這時候我們就應(yīng)用到奧卡姆剃刀原則，奧卡姆剃刀原則又名簡約之法則，這是一個解決問題的法則，剔除多余的不必要的環(huán)節(jié)，直到簡單到不能再簡單，此時暴露出來的地方就是問題關(guān)鍵。
flink日志采集任務(wù)經(jīng)過采集客戶端，采集服務(wù)端，kafka，flink,es。經(jīng)過消費中間過程的kafka，發(fā)現(xiàn)kafka中的日志是最新的，沒有延時，排除前面采集過程導(dǎo)致的延時，所以問題出在flink消費kafka數(shù)據(jù)寫入es這個環(huán)節(jié)，在這個過程中有三個步驟，flink解碼，flink分詞，flink入庫，下面我們將一個個去掉，測試哪個環(huán)節(jié)影響日志任務(wù)延時。
第一步，由于客戶在使用的過程中，并沒有用到flink的分詞去查詢，去掉flink分詞過程后經(jīng)過觀察依然出現(xiàn)延時，說明可能是解碼和入庫過程發(fā)生了延時。
第二步，再去掉解碼，僅保留flink入庫過程，此時依然出現(xiàn)延時，可以確定flink入庫是延時的一個環(huán)節(jié)。既然確定flink入庫是延時的一個原因，首先我們優(yōu)化flink入庫，提高寫入es的數(shù)據(jù)量，由于es的參數(shù)設(shè)置早已經(jīng)經(jīng)過優(yōu)化設(shè)置，沒有太多回旋的余地，只能選擇關(guān)閉es副本，提高es寫入數(shù)據(jù)量。
第三步，關(guān)閉副本后，加上上面兩步關(guān)閉的解碼和分詞，在去掉解碼，分詞和關(guān)閉副本后，程序正常沒有延時，此時可以作為正常的基點。
第四步，再次開啟副本后，在解碼，分詞是關(guān)閉狀態(tài)下出現(xiàn)了延時，驗證了之前的開啟副本產(chǎn)生延時。
第五步，關(guān)閉副本，關(guān)閉分詞，僅開啟解碼，此時沒有出現(xiàn)延時，說明解碼對延時不產(chǎn)生影響。
第六步,關(guān)閉副本狀態(tài)下，開啟解碼和分詞，此時立刻出現(xiàn)延時，說明分詞過程也是日志采集入庫延時的一個原因。
綜上步驟測試，驗證了在數(shù)據(jù)量上升的過程中，分詞過程和開啟es副本對日志采集入庫延時的影響最大。解碼幾乎不受數(shù)據(jù)量增長的影響。
既然找到了問題是flink分詞過程和es副本，所以需要優(yōu)化的地方就是這兩個：
優(yōu)化es副本：
將副本開啟時間改為凌晨，凌晨將昨天寫入的數(shù)據(jù)在凌晨的空閑時間再生成副本，避免寫入的時候產(chǎn)生es副本；
優(yōu)化flink分詞過程：
由于已經(jīng)定位是flink的分詞影響，所以針對分詞處理過程和分詞處理結(jié)果入庫環(huán)節(jié)效率進一步優(yōu)化。
在解決問題的過程中，發(fā)現(xiàn)有些地方做的不足，比如未統(tǒng)計每天及每小時采集數(shù)據(jù)量做基線，在出現(xiàn)問題時，無統(tǒng)計數(shù)據(jù)歷史基線對比，無法說服用戶是日志數(shù)據(jù)增長導(dǎo)致的延時。目前我們已經(jīng)部署了腳本監(jiān)控每天和每小時寫入es的數(shù)據(jù)量，確保下次出現(xiàn)問題時有據(jù)可查。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/130119.html
摘要：在開發(fā)設(shè)計中有一些常用原則或者潛規(guī)則，根據(jù)筆者的經(jīng)驗，這里稍微總結(jié)一下最最常用的，以饗讀者。是處理復(fù)雜性的一個原則。參考六大設(shè)計原則里氏替換原則奧卡姆剃刀如有問題可以通過郵件微信聯(lián)系我。 在開發(fā)設(shè)計中有一些常用原則或者潛規(guī)則，根據(jù)筆者的經(jīng)驗，這里稍微總結(jié)一下最最常用的，以饗讀者。 DRY 這里的DRY是Do Not Repeat Yourself的縮寫。具體解釋參見 ,嚴(yán)謹(jǐn)?shù)亩x是 E...
摘要：彼得原理每個組織都是由各種不同的職位等級或階層的排列所組成，每個人都隸屬于其中的某個等級。對一個組織而言，一旦相當(dāng)部分人員被推到其不稱職的級別，就會造成組織的人浮于事，效率低下，導(dǎo)致平庸者出人頭地，發(fā)展停滯。 1、蘑菇管理 蘑菇管理是許多組織對待初出茅廬者的一種管理方法，初學(xué)者被置于陰暗的角落(不受重視的部門，或打雜跑腿的工作)，澆上一頭大糞(無端的批評、指責(zé)、代人受過)，任其...
摘要：在移動端，愛奇藝月度總有效時長億小時，穩(wěn)居中國榜第三名。愛奇藝的峰值事件數(shù)達到萬秒，在正確性容錯性能延遲吞吐量擴展性等方面均遇到不小的挑戰(zhàn)。從到愛奇藝主要使用的是和來進行流式計算。作者：陳越晨 整理：劉河 本文將為大家介紹Apache Flink在愛奇藝的生產(chǎn)與實踐過程。你可以借此了解到愛奇藝引入Apache Flink的背景與挑戰(zhàn)，以及平臺構(gòu)建化流程。主要內(nèi)容如下： 愛奇藝在實時計算方...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
