<s id="xcxsa"></s><rp id="xcxsa"></rp>

  • <span id="xcxsa"><pre id="xcxsa"><rt id="xcxsa"></rt></pre></span>
    <dd id="xcxsa"></dd><tbody id="xcxsa"></tbody>
        首頁 運維干貨開源or自研?騰訊全鏈路日志監控實踐告訴你

        開源or自研?騰訊全鏈路日志監控實踐告訴你

        運維派隸屬馬哥教育旗下專業運維社區,是國內成立最早的IT運維技術社區,歡迎關注公眾號:yunweipai
        領取學習更多免費Linux云計算、Python、Docker、K8s教程關注公眾號:馬哥linux運維

        開源

        作者介紹

        吳樹生

        騰訊高級工程師,負責SNG大數據監控平臺建設。近十年監控系統開發經驗,具有構建基于大數據平臺的海量高可用分布式監控系統研發經驗。

        背景

        全鏈路日志監控在現在盛行的微服務和分布式環境下,能有效地提高問題定位分析效率,成為開發和運維利器。當前已有開源解決方案和成熟的廠商提供。

        比如Twitter的zipkin基于Google的Dapper論文設計開發了分布式跟蹤系統,用于采集各處理節點間的日志和耗時信息,幫助用戶排查請求鏈路的異常環節。

        在有統一RPC中間件框架的業務部門容易接入zipkin。但織云全鏈路日志監控平臺(后成全鏈路)面對的實際業務場景更為復雜,全鏈路日志監控實現遇到更多的挑戰,全鏈路技術選型經歷了從開源組件到自研的變化。

        當前織云全鏈路日志監控平臺已接入空間和視頻云業務日志數據。每日數據存儲量10TB,可做到1/10的壓縮比,峰值流量30GB/s。

        我們先分享一個案例場景:

        2017年8月31日 21:40~21:50 X業務模塊指標異常,成功率由99.988%降為97.325%。如下圖所示:

        日志

        收到成功率異常告警后,在多維監控系統上通過畫像下鉆發現是空間點播業務的iphone客戶端成功率下降,返回碼為-310110004。如下圖:

        監控

        通過大盤多維數據分析發現異常原因后,因涉及APP問題,還需要進一步分析用戶出現異常的上下文。因而需要查看出現異常的用戶在異常時間點的全鏈路日志數據。在全鏈路視圖上,可以展示查詢出來符合異常條件的用戶日志和操作過程。

        數據分析

        以上是從面到點的異常分析案例。

        使用場景

        歸納全鏈路日志監控的使用場景主要有三大類:

        • 一是個例分析,主要有處理用戶投訴和從面到點的異常分析;
        • 二是開發調試,主要用于開發過程中查看關聯模塊的日志和作為測試提單線索;
        • 三是監控告警,主要是從日志數據中提取維度,統計為多維數據用于異常檢測和原因分析。

        遇到的挑戰

        在構建織云全鏈路日志監控平臺時,織云監控模塊經歷了從傳統監控和質量統計大數據多維監控平臺的轉型。踩過大數據套件的坑,也遇到過業務場景的挑戰。

        • 業務多樣性挑戰

        QQ體系內有豐富多樣的業務,例如:手Q、空間、直播、點播、會員等。這些業務產生的不同樣式的日志格式,并且沒有一致的RPC中間件框架。這個背景決定系統需要支持靈活的日志格式和多種采集方式。

        • 海量數據挑戰

        同時在線超2億用戶上報的狀態數據,日存儲量超10T,帶寬超過30GB/s。需要穩定和高效的數據處理、高性能和低成本的數據存儲服務。在使用開源組件完成原型開發后,逐漸遇到性能瓶頸和穩定性挑戰,驅使我們通過自研逐漸替換開源組件。

        應對挑戰

        日志多樣化

        日志的價值除提供查詢檢索外,還可做統計分析和異常檢測告警。為此我們將日志數據規范化后分流到多維監控平臺。復用監控平臺已有的能力。

        基于前面積累的監控平臺開發經驗,在織云全鏈路日志監控平臺設計時取長補短。通過自研日志存儲平臺解決開源存儲組件遇到的成本、性能和穩定性瓶頸。

        織云全鏈路日志監控平臺提供了4種數據格式支持,分別是分隔符、正則解析、json格式和api上報:

        分隔符、正則解析和json格式用于非侵入式的數據采集,靈活性好。但是服務端的日志解析性能較低,分隔符的數據解析只能做到4W/s的處理性能。而api方式則能達到10W/s處理性能。對于內部業務,我們推薦采用統一的日志組件,并嵌入api上報數據。

        系統自動容災和擴縮容

        對于海量的日志監控系統設計,為做到,第一步是將模塊做無狀態化設計。比如系統的接入模塊、解析模塊和處理模塊,這類無需狀態同步的模塊,可單獨部署提供服務。

        但對這類無狀態業務模塊,需要增加剔除異常鏈路機制。也就是數據處理鏈路中如果中間一個節點異常,則該節點往后的其他節點提供的服務是無效的,需要中斷當前的鏈路。異常鏈路剔除機制有多種,如通過zk的心跳機制剔除。

        為避免依賴過多的組件,我們做了一個帶狀態的心跳機制。上游節點A定時向下游節點B發送心跳探測請求,時間間隔為6s。B回復心跳請求時帶上自身的服務可用狀態和鏈路狀態。上游節點A收到B心跳帶上的不可用狀態后,如果A下游無其他可用節點,則A的下游鏈路狀態也置為不可用狀態。心跳狀態依次傳遞,最終自動禁用整條鏈路。有狀態的服務通常是存儲類服務。這類服務通過主備機制做容災。如果同一時間只允許一個master提供服務則可采用zk的選舉機制實現主備切換。

        zookeeper

        做到系統自動容災和擴縮容的第二步是實現通過路由機制實現名字服務和負載均衡。使用開源組件zookeeper能快速實現名字服務功能。要求在服務端實現注冊邏輯,在客戶端實現路由重載邏輯。

        數據通道的容災

        我們采用兩種機制:雙寫方式和消息隊列。

        ●?對于數據質量要求高的監控數據,采用雙寫方式實現。這種方式要求后端有足夠的資源應對峰值請求。提供的能力是低延時和高效的數據處理能力。

        ●對于日志數據采用具備數據容災能力的消息隊列實現。使用過的選型方案有kafka和rabbitmq+mongodb。

        采用消息隊列能應對高吞吐量的日志數據,并帶有削峰作用。其副作用是在高峰期數據延時大,不能滿足實時監控告警需求。采用消息隊列還需要注意規避消息積壓導致隊列異常問題。

        例如使用kafka集群,如果消息量累積量超過磁盤容量,會造成整個隊列吞吐量下降,影響數據質量。

        我們后來采用rabbitmq+mongodb方案。數據在接入層按1萬條或累積30s形成一個數據塊。將數據庫隨機寫入由多個mongodb實例構成的集群。將mongodb的ip和key寫入rabbitmq中。后端處理集群從rabbitmq獲取待消費的信息后,從對應的mongodb節點讀取數據并刪除。通過定時統計rabbitmq和mongodb的消息積壓量,如何超過閾值則實施自動清理策略。

        日志

        查詢

        日志的存儲方案為應對高效和低成本查詢,我們采用自研的方式實現。全鏈路上報的數據按用戶ID或請求ID作為主key進行hash分片。分片后的數據在緩存模塊累積1min或1M大小,然后寫入文件服務器集群。文件寫入集群后,將hash值與文件路徑的映射關系寫入ElasticSearch。

        查詢數據提供兩類能力:

        第一類是按主key查詢。查詢方式是對待查詢key計算hash值,從ES中檢索出文件路徑后送入查詢模塊過濾查找;

        第二類查詢能力是非主key的關鍵字查找。根據業務場景,提供的查詢策略是查詢到含關鍵字的日志即可。該策略的出發點是平衡查詢性能,避免檢索全量文本。也就是第一次查詢1000個文件,如果有查詢結果則停止后續的查詢。如果無查詢結果返回,則遞增查找2000個文件,直到查詢10萬個文件終止。

        數據

        為滿足多樣的業務場景。我們在數據處理模塊抽象了ETL能力,做到插件化擴展和可配置實現。并提供統一的任務管理和集群管理能力。

        總結

        全鏈路日志監控的開發過程有以下經驗可借鑒:

        • 使用成熟的開源組件構建初級業務功能;
        • 在業務運行過程中,通過修改開源組件或自研提升系統處理能力和穩定性,降低運營成本和提升運維效率;
        • 采用無狀態化和路由負載均衡能力實現標準化;
        • 抽象提煉功能模型,建立平臺化能力,滿足多樣業務需求。

        本文鏈接:http://m.abandonstatusquo.com/23823.html

        網友評論comments

        發表評論

        您的電子郵箱地址不會被公開。

        1. php開發說道:

          關鍵的技術一點沒說。。。 怎么把不通服務之間的日志串聯起來的!

        Copyright ? 2012-2022 YUNWEIPAI.COM - 運維派 京ICP備16064699號-6
        掃二維碼
        掃二維碼
        返回頂部
        十分钟免费观看视频高清下载