<object id="3iwlw"><noframes id="3iwlw"></noframes></object>

      <th id="3iwlw"></th>

    1. <rp id="3iwlw"></rp>
      <rp id="3iwlw"></rp>

    2. <button id="3iwlw"></button>
      云計算·大數據 頻道

      云原生環境下的日志采集、存儲、分析實踐

      談到日志系統,首先要從日志說起,日志在 IT 系統里無處不在,也是 IT系統大數據的關鍵來源。日志的種類和樣式非常多,以在線教育系統為例,日志包括客戶端日志、服務端日志。服務端日志又包括業務的運行/運維日志以及業務使用的云產品產生的日志。要管理諸多類型的日志,就需要一套統一的日志系統,對日志進行采集、加工、存儲、查詢、分析、可視化、告警以及消費投遞,將日志的生命周期進行閉環。

      Kubernetes 下日志采集的開源自建方案

      開源自建

      火山引擎早期為了快速上線業務,各團隊基于開源項目搭建了自己的日志系統,以滿足基本的日志查詢需求,例如使用典型的開源日志平臺 Filebeat+Logstash+ES+Kibana 的方案。但是在使用過程中,我們發現了開源日志系統的不足:

      各業務模塊自己搭建日志系統,造成重復建設。

      以 ES 為中心的日志架構可以利用 ES 查詢便利的優勢,但是資源開銷大、成本高。而且 ES 與 Kibana 在界面上強綁定,不利于功能擴展。

      開源方案一般采用單機 yaml 做采集配置,當節點數很多的時候,配置非常繁瑣。

      開源系統的采集配置難以管理,數據源也比較單一。

      Kubernetes 下的日志采集

      Kubernetes 下如何采集日志呢?官方推薦了四種日志采集方案:

      DaemonSet:在每臺宿主機上搭建一個 DaemonSet 容器來部署 Agent。業務容器將容器標準輸出存儲到宿主機上的文件,Agent 采集對應宿主機上的文件。

      Streaming Sidecar:有一些業務系統的日志不是標準輸出,而是文件輸出。Streaming Sidecar 的方式可以把這些文件輸出通過 Sidecar 容器轉換成容器的標準輸出,然后采集。

      Sidecar Logging Agent:業務 Pod 內單獨部署 Agent 的 Sidecar 容器。這種方式的資源隔離性強。

      API/SDK:直接在容器內使用 API 或 SDK 接口將日志采集到后端。

      以上前三種采集方案都只支持采集容器的標準輸出,第四種方案需要改造業務代碼,這幾種方式對采集容器文件都不友好。但用戶對于日志文件有分類的需求,標準輸出將所有日志混在一起,不利于用戶進行分類。如果用戶要把所有日志都轉到標準輸出上,還需要開發或者配置,難以推廣。因此 Kubernetes 官方推薦的方案無法完全滿足用戶需求,給我們的實際使用帶來了很多不便。

      自建日志采集系統的困境與挑戰

      云原生場景下日志種類多、數量多、動態非永久,開源系統在采集云原生日志時面臨諸多困難,主要包括以下問題:

      一、采集難

      配置復雜:系統規模越來越大,節點數越來越多,每個節點的配置都不一樣,手工配置很容易出錯,系統的變更變得非常困難。

      需求不滿足:開源系統無法完全滿足實際場景的用戶需求,例如不具備多行日志采集、完整正則匹配、過濾、時間解析等功能,容器文件的采集也比較困難。

      運維難度高:大規模場景下大量 Agent 的升級是個挑戰,系統無法實時監控 Agent 的狀態,當Agent 狀態異常時也沒有故障告警。

      二、產品化能力不足

      可用性低:因為缺少流控,突發的業務容易使后端系統過載,業務之間容易相互影響。

      資源使用效率低:如果配置的資源是固定的,在突發場景下容易造成性能不足的問題;但如果配置的資源過多,普通場景下資源利用率就會很低;不同的組件配置不均衡還會導致性能瓶頸浪費資源。ES 的原始數據和索引使用相同的資源配置,也會導致高成本。

      功能不足:比如 ES 的投遞和消費能力弱、分析能力固化、沒有告警能力、可視化能力有限。

      火山引擎統一日志平臺 TLS

      在遇到這些問題以后,我們研發了一套統一的日志管理平臺——火山引擎日志服務(Tinder Log Service,簡稱為 TLS)。TLS 的整體架構如下:

      面對各種日志源,TLS 通過自研的 LogCollector/SDK/API,可支持專有協議、 OpenTelemetry 和 Kafka 協議上傳日志。支持多種類型的終端、多種開發語言以及開源生態標準協議。

      采集到的日志首先會存入高速緩沖集群,削峰填谷,隨后日志會勻速流入存儲集群,根據用戶配置再流轉到數據加工集群進行日志加工,或者到索引集群建立索引。建立索引后用戶可以進行實時查詢和分析。TLS 提供標準的 Lucene 查詢語法、SQL 92 分析語法、可視化儀表盤以及豐富的監控告警能力。

      當日志存儲達到一定周期,不再需要實時分析之后,用戶可以把日志投遞到成本更低的火山引擎對象存儲服務中,或者通過 Kafka 協議投遞到其他云產品。如果用戶有更高階的分析需求,TLS 也支持把日志消費到實時計算、流式計算或離線計算進行更深入的分析。

      TLS 的系統設計遵循高可用、高性能、分層設計的原則。

      高可用:通過存算分離,所有服務都是無狀態的,故障快速恢復。

      高性能:所有集群都可橫向擴展,沒有熱點。

      分層設計:各模塊之間低耦合,模塊之間定義標準接口,組件可替換。

      以上就是火山引擎自研的日志存儲平臺 TLS 的系統架構,下面將詳細介紹 TLS 相較于開源系統做的優化。

      系統優化

      中心化白屏化的配置管理

      當日志系統中采集 Agent 數量較多時,不再適合在每臺機器上手工配置,因此我們開發了中心化、白屏化的配置管理功能,支持動態下發采集配置,并支持查看 Agent 運行狀態監控、支持客戶端自動升級。

      中心化配置的實現流程如下:

      客戶端主動向服務端發起心跳,攜帶自身版本信息。

      服務端收到心跳,檢查版本。

      服務端判斷是否需要下發配置信息給客戶端。

      客戶端收到配置信息,熱加載到本地配置,以新的配置進行采集。

      中心化配置管理的優勢在于:

      可靠:中心化管理,配置不丟失,白屏化配置不容易出錯。

      高效:各種環境下所有的配置都是統一處理,無論 LogCollector 部署在移動端、容器還是物理機上,用戶都可以在服務端相同的界面上配置,配置以機器組為單位批量下發,快速高效。

      輕松運維:用戶可以在服務端查看客戶端的運行狀態,對客戶端的異常發出告警。通過中心化配置,TLS 可以向客戶端推送最新版本,自動升級。

      CRD 云原生配置方式

      中心化、白屏化的配置方式是適合運維人員的配置方式。在開發測試自動化的場景下,最優的方式是 CRD。傳統的方式通過 API 接口去做采集配置,用戶通常需要寫數千行代碼來實現。TLS 提供了云原生 CRD 的方式來進行配置,用戶只需要在 yaml 文件里配置要采集的容器、容器內的日志路徑以及采集規則即可完成采集配置。因為不再需要編寫代碼,CRD 方式大幅提高了日志接入效率。

      CRD 的配置流程如下:

      使用 Kubectl 命令創建 TLS LogConfig CRD;

      TLS Controller 監聽到 CRD 配置更新;

      TLS Controller 根據 CRD 配置向 TLS Server 發送命令,創建 topic、創建機器組,創建日志采集配置;

      LogCollector 定期請求 TLS Server,獲取新的采集配置并進行熱加載;

      LogCollector 根據采集配置采集各個容器上的標準輸出或文本日志;

      LogCollector 將采集到的日志發送給 TLS Server。

      適合大規模、多租戶場景的客戶端

      開源日志采集客戶端一般只支持一個 Output,多個 Input 采用相同的 Pipeline,相互影響。為了適應大規模、多租戶場景,火山引擎自研了日志采集的客戶端 LogCollector。LogCollector 對不同的 Input 采用不同的 Pipeline 做資源隔離,減少多租戶之間的相互影響。一個 LogCollector 支持多個 Output,可以根據不同的 Output 單獨做租戶鑒權。同時我們還在 LogCollector 內實現了自適應反壓機制,如果服務端忙碌,LogCollector 會自動延遲退避,服務端空閑時再發送,減少算力負擔。

      產品優化

      可用性提升

      在可用性方面,TLS 支持多級全局流控,能杜絕因業務突發導致的故障擴散問題。

      在日志采集到高速緩沖集群時,按照用戶的 Shard 數控制寫入高速緩沖區的流量。

      當數據從高速緩沖區流向存儲集群時,按存儲集群控制單個存儲集群的流量。

      從存儲集群到索引集群,按索引集群控制單個索引集群的寫入流控以及查詢分析并發數。

      效率提升

      索引和原始數據分離

      ES 的索引和數據存在一起,我們在設計過程發現索引和原始數據分離會更優,主要表現在:

      提升數據流動性:存儲集群支持批量消費接口,消費數據不經過索引集群。相對于從索引集群先查詢后消費的模式,直接從存儲集群消費性能更高,有效提升數據流動性。

      降低成本:索引和存儲可以采用不同成本的存儲,整體的存儲成本就會降低。用戶可以隨時按需創建索引,進一步降低索引成本。

      提升可用性:索引可以異步創建,流量突發時創建索引慢不會影響存儲寫入速率。

      索引管理和調度

      索引的流量是不可預測的,因此我們在效率方面的另一個優化是支持索引的管理和調度,實現彈性伸縮,從而提升可用性,解決規模問題。我們的解決方案是在多個索引集群之間做數據流動,基于負載、資源、容量自動遷移索引,支持動態跨集群在線遷移索引,平衡索引集群負載。

      功能優化

      消費投遞:在消費投遞方面我們支持了豐富的消費投遞接口,包括:

      消費者

      消費組

      Kafka 協議:通過 Kafka 協議進行標準協議的消費;

      S3 協議:支持通過 S3 對象存儲的協議把日志投遞到對象存儲。

      查詢分析:支持先查詢過濾后分析,減少分析數據量提高性能。分析支持標準的 SQL 92,分析結果支持圖表可視化。

      日志告警:通過實時監控日志,基于用戶配置的監控規則組合以及告警觸發條件,滿足條件就可以通過短信、郵件、飛書等方式發送告警給用戶或用戶組。

      可視化儀表盤:TLS 提供多種可視化儀表盤,實現實時監測,且儀表盤可以關聯告警。

      TLS 實踐案例

      接下來為大家介紹兩個 TLS 的典型案例。

      火山引擎內部業務及運維日志采集

      TLS 目前支撐了火山引擎全國多個 Region 運維日志的采集分析。日志類型包括業務的文件日志、容器標準輸出。業務分別部署在內網、外網以及混合云,日志都通過 TLS 平臺統一做采集和分析。

      相較于前期各業務模塊自己搭建日志系統,采用 TLS 獲得了如下收益:

      經濟高效:資源利用率由之前的 20% 提升到現在的 80%,大幅降低資源成本;

      可用性較高:多級流控加緩存,抗突發能力強,即使在索引系統故障的時候也不會影響原始數據的流量;

      輕松運維:TLS 的統一運維提升了運維人員的能力,少量運維人員即可完成整個系統的運維。

      快速接入:TLS 可以在一小時內完成一個新業務的采集、查詢、分析、消費的快速接入。

      某教育行業頭部客戶日志采集

      該客戶的系統業務主要采集的日志包括:

      文件日志

      App 日志

      Kubernetes 集群后端業務的日志

      用戶行為日志

      TLS 把這幾個平臺的日志統一采集到云端,進行實時查詢分析以及進行告警??蛻糇越ㄓ写髷祿治銎脚_,TLS 可將日志數據通過消費的方式流轉到該平臺進行在線、離線等更高階的大數據分析。對于時間長的歷史數據,則投遞到對象存儲進行歸檔,從而降低整個系統的成本。

      用戶的管理員可在 TLS 上統一查看所有平臺的各種日志,整個系統的建設和運維成本也降低了。TLS 使用標準接口,可以兼容云上自建的分析平臺,用戶在快速上線的同時也能保證系統的高度兼容。

      展望未來

      未來,TLS 平臺會不斷進行更深層次的優化:

      云產品的一鍵日志采集

      搜索引擎的深度優化

      數據清洗和加工的函數式接口

      集成更多第三方平臺,火山引擎云產品深度融合

      0
      相關文章
        漂亮的苏酥全文阅读