在Logging這塊做了幾年，最近1年來越來越多的同學(xué)來咨詢?nèi)绾螢镵ubernetes構(gòu)建一個日志系統(tǒng)或者是來求助在這過程中遇到一系列問題如何解決，授人以魚不如授人以漁，于是想把我們這些年積累的經(jīng)驗以文章的形式發(fā)出來，讓看到這篇文章的同學(xué)能少走彎路。這個系列文章定位為長篇連載，內(nèi)容偏向落地實操以及經(jīng)驗分享，且內(nèi)容會隨著技術(shù)的迭代而不定期更新。

創(chuàng)新互聯(lián)主營海城網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,重慶App定制開發(fā),海城h5重慶小程序開發(fā)搭建,海城網(wǎng)站營銷推廣歡迎海城等地區(qū)企業(yè)咨詢

前言

第一次聽到Kubernetes的名字是在16年，那個時候Kubernetes還處于和Docker Swarm、Mesos方案的“三國鼎立時代”，Kubernetes由于一系列優(yōu)勢（可擴展、聲明式接口、云友好）在這一競爭中嶄露頭角，最終獲得統(tǒng)治地位。Kubernetes作為CNCF最核心的項目（沒有之一），是Cloud Native（云原生）落地的底座，目前阿里已經(jīng)全面基于Kubernetes在開展全站的云原生改造，在1-2年內(nèi)，阿里巴巴100%的業(yè)務(wù)都將跑在公有云上。

CloudNative在 CNCF的定義的核心是：在公有云、私有云、混合云等環(huán)境中，通過Containers、Service Meshes、 MicroServices、Immutable Infrastructure、Declarative APIs構(gòu)建和運行可彈性擴展的且具有高容錯性、易于管理、可觀察、松耦合的應(yīng)用系統(tǒng)?？捎^察性是應(yīng)用系統(tǒng)必不可少的一個部分，云原生的設(shè)計理念中就有一條：面向診斷性設(shè)計（Diagnosability），包括集群級別的日志、Metric和Trace。

為何我們需要日志系統(tǒng)

通常一個線上問題的定位流程是：通過Metric發(fā)現(xiàn)問題，根據(jù)Trace定位到問題模塊，根據(jù)模塊具體的日志定位問題原因。在日志中包括了錯誤、關(guān)鍵變量、代碼運行路徑等信息，這些是問題排查的核心，因此日志永遠是線上問題排查的必經(jīng)路徑。

在阿里的十多年中，日志系統(tǒng)伴隨著計算形態(tài)的發(fā)展在不斷演進，大致分為3個主要階段：

1. 在單機時代，幾乎所有的應(yīng)用都是單機部署，當(dāng)服務(wù)壓力增大時，只能切換更高規(guī)格的IBM小型機。日志作為應(yīng)用系統(tǒng)的一部分，主要用作程序Debug，通常結(jié)合grep等Linux常見的文本命令進行分析。
2. 隨著單機系統(tǒng)成為制約阿里業(yè)務(wù)發(fā)展的瓶頸，為了真正的Scale out，飛天項目啟動：2013年飛天5K項目正式上線。在這個階段各個業(yè)務(wù)開始了分布式改造，服務(wù)之間的調(diào)用也從本地變?yōu)榉植际?，為了更好的管理、調(diào)試、分析分布式應(yīng)用，我們開發(fā)了Trace（分布式鏈路追蹤）系統(tǒng)、各式各樣的監(jiān)控系統(tǒng)，這些系統(tǒng)的統(tǒng)一特點是將所有的日志（包括Metric等）進行集中化的存儲。
3. 為了支持更快的開發(fā)、迭代效率，近年來我們開始了容器化改造，并開始了擁抱Kubernetes生態(tài)、業(yè)務(wù)全量上云、Serverless等工作。在這階段，日志無論從規(guī)模、種類都呈現(xiàn)爆炸式的增長，對日志進行數(shù)字化、智能化分析的需求也越來越高，因此統(tǒng)一的日志平臺應(yīng)運而生。

可觀察性的終極解讀

在CNCF中，可觀察性的主要作用是問題的診斷，上升到公司整體層面，可觀察性（Observability）不僅僅包括DevOps領(lǐng)域，還包括業(yè)務(wù)、運營、BI、審計、安全等領(lǐng)域，可觀察性的最終的目標(biāo)是實現(xiàn)公司各個方面的數(shù)字化、智能化。

在阿里，幾乎所有的業(yè)務(wù)角色都會涉及到各式各樣的日志數(shù)據(jù)，為了支撐各類應(yīng)用場景，我們開發(fā)了非常多的工具和功能：日志實時分析、鏈路追蹤、監(jiān)控、數(shù)據(jù)加工、流計算、離線計算、BI系統(tǒng)、審計系統(tǒng)等等。日志系統(tǒng)主要專注于數(shù)據(jù)的實時采集、清洗、智能分析與監(jiān)控以及對接各類各樣的流計算、離線系統(tǒng)。

Kubernetes日志系統(tǒng)建設(shè)難點

單純?nèi)罩鞠到y(tǒng)的解決方案非常多，相對也比較成熟，這里就不再去贅述，我們此次只針對Kubernetes上的日志系統(tǒng)建設(shè)而論。Kubernetes上的日志方案相比我們之前基于物理機、虛擬機場景的日志方案有很大不同，例如：

1. 日志的形式變的更加復(fù)雜，不僅有物理機/虛擬機上的日志，還有容器的標(biāo)準(zhǔn)輸出、容器內(nèi)的文件、容器事件、Kubernetes事件等等信息需要采集。
2. 環(huán)境的動態(tài)性變強，在Kubernetes中，機器的宕機、下線、上線、Pod銷毀、擴容/縮容等都是常態(tài)，這種情況下日志的存在是瞬時的（例如如果Pod銷毀后該Pod日志就不可見了），所以日志數(shù)據(jù)必須實時采集到服務(wù)端。同時還需要保證日志的采集能夠適應(yīng)這種動態(tài)性極強的場景。
3. 日志的種類變多，上圖是一個典型的Kubernetes架構(gòu)，一個請求從客戶端需要經(jīng)過CDN、Ingress、Service Mesh、Pod等多個組件，涉及多種基礎(chǔ)設(shè)施，其中的日志種類增加了很多，例如K8s各種系統(tǒng)組件日志、審計日志、ServiceMesh日志、Ingress等。
4. 業(yè)務(wù)架構(gòu)變化，現(xiàn)在越來越多的公司開始在Kubernetes上落地微服務(wù)架構(gòu)，在微服務(wù)體系中，服務(wù)的開發(fā)更加復(fù)雜，服務(wù)之間的依賴以及服務(wù)底層產(chǎn)品的依賴越來越多，這時的問題排查將更加復(fù)雜，如果關(guān)聯(lián)各個維度的日志將是一個困難的問題。
5. 日志方案集成困難，通常我們都會在Kubernetes上搭建一套CICD系統(tǒng)，這套CICD系統(tǒng)需要盡可能的自動化的完成業(yè)務(wù)的集成和部署，其中日志的采集、存儲、清洗等也需要集成到這套系統(tǒng)中，并和K8s的聲明式部署方式盡可能一致。而現(xiàn)有的日志系統(tǒng)通常都是較獨立的系統(tǒng)，集成到CICD中代價極大。
6. 日志規(guī)模問題，通常在系統(tǒng)初期的時候我們會選擇自建開源的日志系統(tǒng)，這種方式在測試驗證階段或公司發(fā)展初期是沒有什么問題的，但當(dāng)業(yè)務(wù)逐漸增長，日志量增長到一定規(guī)模時，自建的開源系統(tǒng)很多時候都會遇到各種各樣的問題，例如租戶隔離、查詢延遲、數(shù)據(jù)可靠性、系統(tǒng)可用性等。日志系統(tǒng)雖不是IT中最核心的路徑，但一旦關(guān)鍵時刻出現(xiàn)這些問題都將是非常可怕的影響，例如大促的時候出現(xiàn)緊急問題，排查時多個工程師并發(fā)查詢把日志系統(tǒng)打爆，導(dǎo)致故障恢復(fù)時間變長，大促收到影響。
   

總結(jié)

相信在搞K8s日志系統(tǒng)建設(shè)的同學(xué)看到上面的難點分析都會深有感觸，后面我們會從落地角度出發(fā)，詳細介紹在阿里我們?nèi)绾稳ゴ罱↘8s的日志系統(tǒng)，敬請關(guān)注。

本文作者：元乙
名稱欄目：系列文章：云原生Kubernetes日志落地方案-創(chuàng)新互聯(lián)
當(dāng)前鏈接：http://weahome.cn/article/hopco.html