6 個 K8s 日誌系統建設中的典型問題,你遇到過幾個?

大濤學長發表於2019-09-20


6 個 K8s 日誌系統建設中的典型問題,你遇到過幾個?
導讀:隨著 K8s 不斷更新迭代,使用 K8s 日誌系統建設的開發者,逐漸遇到了各種複雜的問題和挑戰。本篇文章中,作者結合自己多年經驗,分析 K8s 日誌系統建設難點,期待為讀者提供有益參考。
在 Logging 這塊做了幾年,最近 1 年來越來越多的同學來諮詢如何為 Kubernetes 構建一個日誌系統,或者是來求助在這過程中遇到一系列問題如何解決,授人以魚不如授人以漁,於是想把我們這些年積累的經驗以文章的形式發出來,讓看到這篇文章的同學能少走彎路。這個系列文章定位為長篇連載,內容偏向落地實操以及經驗分享,且內容會隨著技術的迭代而不定期更新。

前言

第一次聽到 Kubernetes 的名字是在 2016 年,那個時候 Kubernetes 還處於和 Docker Swarm、Mesos 方案的“三國鼎立時代”,Kubernetes 由於一系列優勢(可擴充套件、宣告式介面、雲友好)在這一競爭中嶄露頭角,最終獲得統治地位。 Kubernetes 作為 CNCF 最核心的專案(沒有之一),是 Cloud Native(雲原生)落地的底座,目前阿里已經全面基於 Kubernetes 在開展全站的雲原生改造,在 1-2 年內,阿里巴巴 100% 的業務都將跑在公有云上。 CloudNative 在 CNCF 的定義的核心是:在公有云、私有云、混合雲等環境中,透過 Containers、Service Meshes、 MicroServices、Immutable Infrastructure、Declarative APIs 構建和執行可彈性擴充套件的且具有高容錯性、易於管理、可觀察、松耦合的應用系統。可觀察性是應用系統必不可少的一個部分,雲原生的設計理念中就有一條:面向診斷性設計(Diagnosability),包括叢集級別的日誌、Metric 和 Trace。

為何我們需要日誌系統

通常一個線上問題的定位流程是:透過 Metric 發現問題,根據 Trace 定位到問題模組,根據模組具體的日誌定位問題原因。在日誌中包括了錯誤、關鍵變數、程式碼執行路徑等資訊,這些是問題排查的核心,因此日誌永遠是線上問題排查的必經路徑。

6 個 K8s 日誌系統建設中的典型問題,你遇到過幾個?

在阿里的十多年中,日誌系統伴隨著計算形態的發展在不斷演進,大致分為 3 個主要階段:
  1. 在單機時代,幾乎所有的應用都是單機部署,當服務壓力增大時,只能切換更高規格的 IBM 小型機。日誌作為應用系統的一部分,主要用作程式 Debug,通常結合 grep 等 Linux 常見的文字命令進行分析;
  2. 隨著單機系統成為制約阿里業務發展的瓶頸,為了真正的 Scale out,飛天專案啟動:2013 年飛天 5K 專案正式上線。在這個階段各個業務開始了分散式改造,服務之間的呼叫也從本地變為分散式,為了更好的管理、除錯、分析分散式應用,我們開發了 Trace(分散式鏈路追蹤)系統、各式各樣的監控系統,這些系統的統一特點是將所有的日誌(包括 Metric 等)進行集中化的儲存;
  3. 為了支援更快的開發、迭代效率,近年來我們開始了容器化改造,並開始了擁抱 Kubernetes 生態、業務全量上雲、Serverless 等工作。在這階段,日誌無論從規模、種類都呈現爆炸式的增長,對日誌進行數字化、智慧化分析的需求也越來越高,因此統一的日誌平臺應運而生。

可觀察性的終極解讀

在 CNCF 中,可觀察性的主要作用是問題的診斷,上升到公司整體層面,可觀察性(Observability)不僅僅包括 DevOps 領域,還包括業務、運營、BI、審計、安全等領域,可觀察性的最終的目標是實現公司各個方面的數字化、智慧化。

6 個 K8s 日誌系統建設中的典型問題,你遇到過幾個?

在阿里,幾乎所有的業務角色都會涉及到各式各樣的日誌資料,為了支撐各類應用場景,我們開發了非常多的工具和功能:日誌實時分析、鏈路追蹤、監控、資料加工、流計算、離線計算、BI 系統、審計系統等等。日誌系統主要專注於資料的實時採集、清洗、智慧分析與監控以及對接各類各樣的流計算、離線系統。

Kubernetes 日誌系統建設難點


6 個 K8s 日誌系統建設中的典型問題,你遇到過幾個?

單純日誌系統的解決方案非常多,相對也比較成熟,這裡就不再去贅述,我們此次只針對 Kubernetes 上的日誌系統建設而論。Kubernetes 上的日誌方案相比我們之前基於物理機、虛擬機器場景的日誌方案有很大不同,例如:
  1. 日誌的形式變得更加複雜,不僅有物理機/虛擬機器上的日誌,還有容器的標準輸出、容器內的檔案、容器事件、Kubernetes 事件等等資訊需要採集;
  2. 環境的動態性變強,在 Kubernetes 中,機器的當機、下線、上線、Pod銷燬、擴容/縮容等都是常態,這種情況下日誌的存在是瞬時的(例如如果 Pod 銷燬後該 Pod 日誌就不可見了),所以日誌資料必須實時採集到服務端。同時還需要保證日誌的採集能夠適應這種動態性極強的場景;
  3. 日誌的種類變多,上圖是一個典型的 Kubernetes 架構,一個請求從客戶端需要經過 CDN、Ingress、Service Mesh、Pod 等多個元件,涉及多種基礎設施,其中的日誌種類增加了很多,例如 K8s 各種系統元件日誌、審計日誌、ServiceMesh 日誌、Ingress 等;
  4. 業務架構變化,現在越來越多的公司開始在 Kubernetes 上落地微服務架構,在微服務體系中,服務的開發更加複雜,服務之間的依賴以及服務底層產品的依賴越來越多,這時的問題排查將更加複雜,如果關聯各個維度的日誌將是一個困難的問題;
  5. 日誌方案整合困難,通常我們都會在 Kubernetes 上搭建一套 CICD 系統,這套 CICD 系統需要儘可能的自動化的完成業務的整合和部署,其中日誌的採集、儲存、清洗等也需要整合到這套系統中,並和 K8s 的宣告式部署方式儘可能一致。而現有的日誌系統通常都是較獨立的系統,整合到 CICD 中代價極大;
  6. 日誌規模問題,通常在系統初期的時候我們會選擇自建開源的日誌系統,這種方式在測試驗證階段或公司發展初期是沒有什麼問題的,但當業務逐漸增長,日誌量增長到一定規模時,自建的開源系統很多時候都會遇到各種各樣的問題,例如租戶隔離、查詢延遲、資料可靠性、系統可用性等。日誌系統雖不是 IT 中最核心的路徑,但一旦關鍵時刻出現這些問題都將是非常可怕的影響,例如大促的時候出現緊急問題,排查時多個工程師併發查詢把日誌系統打爆,導致故障恢復時間變長,大促收到影響。
相信在搞 K8s 日誌系統建設的同學看到上面的難點分析都會深有感觸,後面我們會從落地角度出發,詳細介紹在阿里我們如何去搭建 K8s 的日誌系統,敬請關注。
本文作者: 元乙  阿里雲日誌服務資料採集客戶端負責人
本文為雲棲社群原創內容,未經允許不得轉載。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69947441/viewspace-2657709/,如需轉載,請註明出處,否則將追究法律責任。

相關文章